Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-1-
MULTIFUNCTIONAL MOBILE BANKING SYSTEM
Field of the Invention
This invention relates to the field of cross-platform integrated transaction
management systems for multifunctional mobile banking systems.
Background of the Invention
There is an increasing demand for versatile, mobile, and user-friendly
solutions to traditional transactional and information delivery systems. In no
industry
is the demand greater than the banking, financial services, and electronic
transaction
industry. Internet communications; high speed, high volume data processing;
exponentially growing technological advancement and added consumer initiative
for
adopting new technologies are increasing the speed with which service
industries must
offer enhanced services. Banking, financial services, and electronic
transaction
companies whose businesses are increasingly dominated by the aggregation,
archiving, protection, and transfer of electronic f nancial data are
particularly
susceptible to these increased consumer demands.
At present, a number of overlapping systems are being utilized to provide
access to banking, financial services, and electronic transactions. For
example, banks
and other financial institutions seeking to securely transfer funds among
themselves
using specific communications and security protocols, may use electronic
fluids
transfer (EFT) protocols and encrypt the communications and Personal
Identification
Numbers (PINs) utilizing the Data Encryption Standard (DES) and may transmit
such
communications over dedicated data lines or through telephone connections to
proprietary servers or switches. Credit and debit card companies may use a
variety of
communications protocols, encryption standards, and data transfer protocols to
communicate transactional details between retailers and financial
institutions, and still
other protocols for retailer to consumer transactions (such as various point-
of sale
(POS) systems) or consumer to financial institution transactions. Individual
banks
and other financial service providers have developed their own solutions for
providing
various financial services to consumers and businesses over the Internet,
through dial-
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-2-
up transaction systems and automatic teller machines (ATMs). Internet
electronic
commerce businesses, Internet banks, and the companies providing the
underlying
electronic transactions capabilities have also developed their own particular
protocols
for sharing data using standard Internet protocols and business-to-business
(B2B)
solutions. All of these systems overlap and interact with each other.
The use of isolated or proprietary communications systems and industry-
specific or proprietary encryption and data transfer protocols provides an
added
measure of security for the institutions using such systems and protocols.
However, in
doing so, some institutions have compromised their ability to easily integrate
these
systems with more ubiquitous protocols, such as those used on the Internet.
Furthermore, many of these solutions are antiquated and difficult to modify
for
advances in technology and additional service demands: Moreover, a variety of
hardware and software providers serve the financial services industry and
promote
proprietary and incompatible solutions which may be difficult to upgrade for
further
advancements in communication and data processing systems and increased
consumer
demands.
The advent of modular programming, hardware independent programming
platforms (e.g., Enterprise Java Beans and Java Beans Enterprise Application
Servers), server/thin-client applications, and an unparalleled global data
transfer
network (the Internet) have provided the building blocks for implementing a
multifunctional transaction management system for banking and other financial
services. However, no single system has yet integrated all of these tools to
provide a
flexible, expandable, easy to operate, and dependable system.
These and other drawbacks of prior art systems are overcome by the various
embodiments of the invention.
Summary of the Invention
It is therefore an object of the invention to overcome the above-mentioned
drawbacks of prior systems.
It is an additional object of the invention to provide a system and method for
enhanced banking services through a wide variety of service end points.
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-3-
Additional objects and advantages of the invention will be set forth in part
in
the description which follows and in part will be obvious from the
description, or may
be learned by practice of the invention.
These and other objects of the preferred embodiments are particularly achieved
by an integrated transaction management system incorporating one or more
interface
servers, a financial data gateway, and a plurality of modular financial
service
applications. The interface servers provide interfaces for a variety of
wireless and
Internet devices. For example, the interface servers support Web-based
Automated
Teller Machines (ATMs), Point of Sale (POS) devices, Electronic Funds
Transsfer
(EFT) gateway interfaces, Internet and telephone banking, wireless short
messaging
services (SMS) and wireless application protocol (WAP) interfaces, and other
thin-
client interfaces. The financial data gateway provides for communications and
transactions with a variety of financial data networks utilizing a variety of
communications protocols. The modular financial service applications may be
hardware platform independent and readily customizable and expandable. Some
examples of such modular financial service applications include the provision
of
account access, account maintenance and management, automated transaction
management, event messaging and account-based and card-based transactions for
goods and services. Communication with a universal registry of card and
account data
facilitates additional transaction security and enhanced consumer services
through the
integrated transaction management system.
The accompanying drawings, which are incorporated in and constitute a part of
this specification, illustrate an embodiment of the invention and, together
with the
description, serve to explain the principles of the invention.
Brief Descriution of the Drawings
Figure 1 is a schematic view of an integrated transaction management system
for providing banking services according to an embodiment of the invention.
Figure 2 is a schematic view of a modular system for processing user service
requests according to an embodiment of the invention.
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-4-
Figure 3 is a schematic view of an integrated transaction management system
for conducting a variety of banking service transactions through a variety of
service
end points according to an embodiment of the invention.
Figure 4 is a flow chart showing a method of providing an event messaging
application through an integrated transaction management system.
Detailed Descriution of the Preferred Embodiments
Reference will now be made in detail to the present preferred embodiments of
the invention, examples of which are illustrated in the accompanying drawings
in
which like reference characters refer to corresponding elements.
With reference to the drawing figures generally, and particularly to Figure 1,
an integrated transaction management system 100 for provision of financial and
other
services is shown. The integrated transaction management system 100 includes a
Communication Gateway I10 and an Application Server 120 which each act as an
I S intermediary between a plurality of financial institutions, such as banks
141 and 142,
and a plurality of interface servers 130, such as Web Server 131, SMS Server
132,
WAP Server 133, and ATM Server 134. Each type of interface server 130 allows a
user to access a plurality of banking services through a variety of service
end points,
such as personal digital assistants (PDAs), cellular or mobile phones,
personal
computers, portable computers, telephones, facsimile machines, ATMs, POS
systems
and other devices. Each of the example interface servers 130 shown supports a
different communications protocol and interface standard for enabling one or
more
types of service end points or terminal devices to communicate with the
plurality of
financial institutions. The Application Server 120, in communication with the
interface servers 130, includes a variety of modular applications for
providing a
plurality of banking services, such as a savings account, a checking account,
a credit
card, a debit card, a brokerage account access and management service, an
automatic
transaction management service, an event messaging service, a goods and
services
transaction service, and other similar banking services. In one embodiment,
the
Application Server 120 may be connected to a Cryptography System 121 to
provide
enhanced security for communications. The Application Server 120 may direct
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-S-
communications relating to the user's banking services, such as account
balance
inquiries, electronic fund transfers, and other transactions with outside
financial
institutions, through Communication Gateway 110. Communication Gateway 110
acts to properly direct or route the communications to one or more financial
institutions, such as banks 141 and 142, across one or more communications
networks. An external data repository, such as data repository 150, contains
personalized account information for a number of users, thereby enabling
additional
banking services to be provided to such number of users. A plurality of
proprietary
terminal devices, such as ATMs 161 and 163 and a POS system 162 may also be
included in the integrated transaction management system 100.
In order to route communications, as referenced above, the Communication
Gateway 110 includes switching and monitoring hardware and software for
directing
communications relating to the user's banking services (such as electronic
financial
data) to a predetermined destination (financial institution) according to the
communications protocols appropriate to that financial institution.
Communication
Gateway 110 further includes a hub for directing traffic in electronic
financial data
among a variety of otherwise incompatible communications networks and
financial
data systems. Communication Gateway 110 may also include a number of
communication channels and network connections for communicating the
electronic
financial data using electronic funds transfer (EFT) standards, Internet-based
standards, proprietary standards, and other standards for secure data
transfer. For
example, communication channels 141 a and 142a may each be a standard EFT
pipeline for transferring data to and from any financial institution, such as
banks 141
and 142, connected to an international EFT network. Or, alternatively,
Communication Gateway I 10 may provide other types of communication channels
to
the financial institutions thereby enabling wider bandwidth, or greater
versatility or
efficiency of data exchange. For example, communication channel 141b may be
configured as a B2B connection using Internet protocols (i. e., TCP/IP), or a
dedicated
line or connection to a proprietary bank server.
Communication Gateway 110 also serves to facilitate communication with a
plurality of data resources containing aggregate data from a variety of banks
and
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-6-
financial institutions. As shown in Figure 1, Communication Gateway 110 may be
connected to data repository 150 via communication channel 150a. Communication
Gateway 110 also supports a plurality of communication protocols for sending
data to
and receiving data from a wide variety of data storage and processing
resources
interconnected by a wide area network, such as the Internet. The communication
channels of Communication Gateway 110 also serve to interconnect a variety of
specialized financial service end points. For example, communication channel
161 a
connects Communication Gateway IIO to ATM 161 and communication channel
162a connects Communication Gateway 110 to POS system 162.
Communication Gateway 110 may also communicate via TCP/IP protocols
with one or more financial service application systems each of which provides
a user
with a plurality of financial services and/or financial service monitoring,
reporting,
and analysis for financial institutions. One example of such a financial
service
application system is Application Server 120.
In order to perform the above-described functions, Communication Gateway
110 preferably includes an AS1400 platform with an OS/400 operating system and
ITM 2.2 software for account access and associated settlement.
Application Server 120 includes one or more servers for hosting a plurality of
financial service applications. Such financial service applications may
include any
service relating to personalized banking, finance, money management, payment
transactions or investments. Application Server 120 further includes a
platform for
running applications for providing consumer financial services. Application
Server
120 utilizes a modular application design supporting standard interface
objects to
provide a flexible, readily expandable, and largely hardware-independent
system for
providing financial service applications. For example, Application Server 120
may be
an enterprise application server running a plurality of applications composed
of
interchangeable application modules (e.g., Enterprise JavaBeans). One such
interchangeable application module may be used to enable Application Server
120 to
offer financial services through and respond to service inquiries from
interface servers
130. Another may enable Application Server 120 to initiate transactions (e.g.,
transfers and queries) with external financial data providers, such as banks
141 and
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
142 or data repository 150. In one embodiment, the Application Server 120 may
include a Microsoft NT 4.0 server having a minimum of a 500 mhz CPU system
with
at least 1-2 gigabytes of memory and running WebLogic software. In an
alternate
embodiment, the Application Server 120 may include a Microsoft NT 4.0 server
having a 500 mhz CPU system with at least 0.5 to 1 gigabytes of memory and
running
Microsoft's SQL 7.0 or higher software and having a plurality of SCSI disks
with a
RAID controller. Additionally, it is preferable to include a plurality of
ethernet cards
and a network capable of 100 megabits per second for communication with other
portions of the system.
Application Server 120 is connected to, and communicates with, Cryptography
System 121 in order to provide encryption and decryption services that are
compatible
with a plurality of varying security standards used by financial service
providers. For
example, the Cryptography System 121 may be comprised of a hardware
cryptography
system which enables conversion between secure socket layer (SSL) or RSA
encrypted account numbers and PINs on the one hand or DES-encrypted PIN blocks
on the other hand. A hardware cryptography system allows data encrypted in one
standard to be decrypted from a first encryption standard (e.g., SSL, WSL, or
SET)
into a hardware form and then encrypted into a second encryption standard
(e.g., DES)
from the hardware form. In this way, decrypted data is never available in an
electronic or visible form which could be vulnerable to accidental or
intentional
disclosure during the encryption conversion process. Such a stringent data
security
protocol may be necessary to comply with the data security requirements of one
or
more secure data networks enabling one or more applications through the
Application
Server 120, such as an international EFT network. Cryptography System 121 may
allow Application Server 120 to be enabled for offering financial service
applications
through wireless and other communication devices not equipped with an
encryption
standard compliant with specific secure data networks.
. Interface servers 130, connected to the Application Server 120, provide user
interfaces for accessing one or more financial service applications hosted on
the
Application Server 120. For example, Web Server 131 provides a number of
dynamically-generated hypertext markup language (HTML) documents to
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
_$_
interactively exchange information with a user. Web Server 131 may be accessed
by
the user via any Web-enabled device, such as a PC, a WebTV, a Personal Digital
Assistant (PDA) or other Internet appliance. The HTML documents generated by
the
Web Server 131 may be populated with content provided by one or more
applications
from the Application Server 120.
A short messaging service (SMS) Server 132 provides one or more short text
messages for interactively exchanging information with the user. The SMS
Server
132 may be accessed by the user using any SMS-enabled device, such as a
cellular
phone, an alphanumeric pager, or another wireless device with limited display
capabilities. At least a portion of the content provided by the SMS Server 132
may be
provided by one or more applications from the Application Server 120. A
wireless
access protocol (WAP) Server 133 may provide one or more interface pages, such
as
pages written in Wireless Markup Language (WML, an extensible markup language
(XML) application), for interactively exchanging information with the user.
The WAP Server 133 is accessible to the user using any device supporting
WAP, such as a mobile phone, a pager, a two-way radio, a smart phone, a
communicator, and another handheld wireless device. At least a portion of the
content available through the WAP Server 133 may be provided by one or more
applications from the Application Server 120.
An ATM Server 134 provides one or more interface screens for interactively
exchanging information with the user through an automated teller machine
(ATM).
The ATM Server 134 may host a plurality of HTML pages accessible by thin-
client
ATMs using client software (e.g., browser software) and Internet communication
protocols (e.g., TCP/IP) similar to those used in connection with Web pages on
the
World Wide Web. At least a portion of the content available through the ATM
Server
134 may be provided by one or more applications from the Application Server
120.
The ATM Server 134 also provides interfaces to the ATMs that require the
proprietary
message formats.
Banks 141 and 142 and communication channels 141a, 141b, and 142a may
include any number of financial institutions and financial data networks.
Banks 141
and 142 may be comprised of a plurality of any one or more traditional brick
and
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
_g_
mortar banks, Internet ("virtual") banks, savings and loan companies, credit
unions,
brokerage houses, credit card companies, retail companies which extend credit,
mortgage companies, loan servicing companies, billing companies, and other
businesses and institutions that maintain secure financial accounts and other
data.
Communication channels 141a, 141b, and 142a may each be comprised of any form
of network connection, including a telephone network, a dedicated hard line, a
dial-up
network, a LAN, a WAN (e.g., the Internet), a wireless communication network
and
another similar network connection.
A data repository 150 may include any number of data repositories containing
financial data or related information. The data repository 150 may be a
localized data
resource, such as a database or a group of databases, or it may be a
distributed
resource, such as a batch of locatable files distributed across a network.
Communication channels 150a and 150b may include any type of network or path
for
communicating data between two or more users. In one embodiment, data
repository
150 includes a repository of financial account information and associated
account
access information, such as bank card or credit card magnetic strip
information, fox
one or more users. Information related to a number of accounts provided by a
variety
of financial institutions but belonging to the same user may be linked or
localized for
more efficient access.
System 100 may include integrated service end points or terminal devices,
such as a plurality of ATMs 161 and 163 and a POS system 162. ATM 161 may be a
standalone ATM which includes its own application and interface software and
which
is capable of exchanging data with one or more financial data networks through
Communication Gateway 110. POS system 162 may be a POS system integrated with
a retail business, including its own application and interface software and
being
capable of exchanging data with one or more financial networks through
Communication Gateway 110. ATM 163 may be a thin-client ATM which utilizes, at
least in part, the application software of Application Server 120 and the
interface
software of ATM Server 134. Other specialized thin-client devices, such as a
thin-
client POS system, are also possible in conjunction with a compatible
interface server.
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-10-
In Figure 2, a modular system 200 for processing a plurality of user service
requests according to an embodiment of the invention is shown. Modular system
200
may be used by an application server, such as the Application Server 120 in
Figure 1,
to process the plurality of user service requests placed through the user
interfaces 130.
Modular system 200 includes a number of application objects 210, such as
Application Objects 211 and 212. Application Objects 211 and 212 are used as
standard entry paths for user service requests, such as from Users 201 and
202.
Application Objects 211 and 212 create a transaction 220, such as Transactions
221
and 222, that describe the actions to be performed. Router 230 evaluates
Transactions
221 and 222 and directs them to an appropriate provider 240, such as Providers
241,
242, and 243. Providers 241, 242, and 243 include the operations for
completing
Transactions 221 and 222. In some cases, a provider, such as Provider 243, may
issue
a Service Request 250 to access an external resource, such as financial data
maintained by a financial institution. Providers 241, 242, and 243 may either
direct
the transaction to a further service provider or may return a response 260,
such as
Responses 261 and 262, to Application Objects 211 and 212.
Application Objects 210 provide standard entry paths for user Service
Requests 250 and initiate transactions 220 within modular system 200.
Application
Objects 210 represent individual actions that the modular system 200 may be
called
on to perform. Some example Application Objects 210 might include a logon
object,
an account balance inquiry object, an account history inquiry object, a
balance transfer
object, an account detail inquiry object, a customer service request object,
and other
objects for providing a variety of financial, administrative, bill paying, and
other
services. In one embodiment, each application object 210 is a stateless
Enterprise
JavaBean (EJB) and is accessible to a user via a Java Naming and Directory
Interface
(JNDI) (not shown). Each Application Object 210 creates a transaction 220 that
describes the action to be performed and contains the user information
necessary to
initiate the action. For example, a logon object would be used to create a
logon
transaction containing basic information such as a user identifier (e.g., a
user name, a
credit card number, an ATM card number, etc.) and a personal identification
number
(PIN). An account balance inquiry transaction could be used to create an
account
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-11-
balance inquiry transaction including the account number of the account of
interest
(and possibly a username and a PIN for security purposes). Each application
object
210 may also call Router 230 in order to determine a destination provider 240
to
process transaction 220. In one embodiment, Application Object 210 passes
transaction 220 to Router 230 where Router 230 evaluates transaction 220 and
passes
it to a selected provider 240. Alternatively, Router 2f0 may evaluate
transaction 220,
but Application Object 210 actually passes transaction 220 to the selected
provider
240 identified by Router 230. Each Application Object 210 may also receive a
response 260 from providers 240 and pass the response 260 back to a user, such
as
users 201 and 202. Each Application Object 210 may also be able to call a
provider
240 to undo, retry, or alter a transaction 220 in response to response 260,
new input
from the user, or other system conditions.
A Transaction 220, such as Transactions 221 and 222, may include the data
required by providers 240 to fulfill the function of Application Object 210.
Transaction 220 may include basic transaction information, such as a unique
identifier, a time stamp, a status marker, an originator, and a destination
(or a list of
providers 240 for completing the transaction). Any amount of additional
transaction-
specific information may be added to a transaction 220 as a data item. In one
embodiment, the data item includes one or more key/value pairs providing a
description of the data, such as an account number or a P1N, and the data
itself, for
example, Account # 012345, PIN 9876. The data item may include a wide variety
of
data and file types and formats, such as a plurality of numbers, flags,
strings, data
files, etc. Some example data objects might include a graphic file of a
canceled
check, a sound file of a voice recognition sample, or a spreadsheet of recent
transactions in an account. The data may further include a token including
data
returned in a response from a previous transaction. In one embodiment, each
transaction 220 is stored as an XML document for access, evaluation, and
modification by Router 230 and providers 240. In another embodiment, each
transaction 220 contains a complete record of the history of the transaction.
Each
transaction 220 may be automatically stored in a database and may be archived
for
later retrieval.
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-12-
Router 230 determines a Provider 240 to handle transaction 220. Router 230
uses a combination of transaction details and/or system information to
determine the
optimal destination Provider 240. For example, Router 230 may route the
transaction
data according to an account number, a transaction amount, or a user name.
Multiple
Routers 230 may be employed by modular system 200 to perform such routing. A
single transaction 220 may be routed several times over the course of its
processing
and Router 230 may be used by Providers 240 as well as Application Objects
210.
Router 230 includes a routing table in the format of an extensible markup
language
(XML) document that lists the conditions and/or rules under which transactions
220
should be routed to a particular provider, such as one of Providers 241, 242
or 243.
Providers 241, 242 and 243 utilize modules that include a logic set for
completing at least a portion of the functions performed by one or more
Application
Objects 210. Such Providers 240 use the data stored within the transaction 220
to
perform each such function. Providers 240 may return a response to the
Application
Object 210 which created the transaction 220 or may pass the transaction 220
to
another Provider 240, with or without consulting Router 230. Provider 240
performs
its functions) locally using transaction data and local resources and system
information and returns a response 261 to the Application Object 210. Some
Providers 240, such as Provider 242, may also perform their functions) locally
using
the transaction data and local resources and system information, however,
their
functions) may be only a portion of the total functions) required by the
Application
Object 210. The transaction 220 may be modified to include data generated by
Provider 242 and may then be routed to another Provider 240, such as Provider
243.
Some Providers 240, such as Provider 243, may route all or a portion of the
data
contained in the transaction 220 to a Service 250 and may then receive
responsive data
from the Service 250 to formulate a Response 262 to the Application Object
210. In
one embodiment, a number of such Providers 240 may simultaneously work on the
same transaction 220. In another embodiment, the Providers 240 may pursue the
same goal through different channels. For example, multiple Providers 240 may
perform multiple Services 250 to get the most rapid xesponse where response
times
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-13-
vary (e.g., one Service 250 may be faster than another Service 250 for any
given
request depending on server availability and other factors).
A Service 250, such as a data courier service or a communication protocol
service may be used to exchange data with an external resource, such as a
financial
data network, a bank, a cryptography system, or a data repository. Each
Service 250
may be customized for the communications protocols and data requirements of a
specific external resource. Service 250 may both send and receive data and the
received data may then be delivered to the service Provider 240 which
initiated the
Service 250, added to the transaction 220 and/or returned to the Application
IO Object 210 in a Response 260.
Responses 261 and 262 may each contain an answer or a resolution to the
transaction 220 created by the Application Object 210. Responses 26I and 262
may
each include information requested by Application Obj ect 210 or may include
an
explanation of why the request set forth in Application Object 210 could not
be
fulfilled. In one embodiment, a Response 260 may include a value to indicate
whether
or not the transaction was successful; a message that explains why the
transaction was
not successful; if necessary, a token, such as a reference to the present
transaction, that
can be used as part of a subsequent transaction; and a plurality of additional
data items
(as described above with respect to the transaction 220). The information
returned in
Responses 260 may be returned in whole or in part to the user who initiated
use of
Application Objects 220 and/or may be the basis of further transaction 220
initiated
through the same or another Application Object 210.
Figure 3 illustrates an integrated transaction management system 300 for
providing a plurality of financial consumer and information services through a
variety
of service end points 310 using a plurality of financial data, content, and
transactional
functions furnished by a variety of remote service Providers 320. As shown in
Figuxe
3, integrated transaction management system 300 includes a variety of consumer-
oriented financial and information services. These financial and information
services
may be provided to a variety of service end points 310 from a number of
interfaces
supporting one or more interface standards and communication protocols. Some
example service end points 310 may include a PDA 311, a cellular phone 312, a
PC
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-14-
313, a portable computer 314, a telephone 315, a facsimile machine 316, an ATM
317, or a POS system 318. Integrated transaction management system 300
communicates with service end points 310 using any communication network such
as
the Internet, a telephone network, a wireless network, a radio network, and
other
communication networks and one or more corresponding data transfer protocols
as
applicable including SMS, WAP, and TCP/IP. The services performed by the
integrated transaction management system 300 may make use of information
gathered
from and/or exchanged with any one or more of a plurality of remote service
providers
320. Some illustrative remote service providers 320 may include a Bank 321, a
Credit
Card Company 322, a GSM Operator 323, a Biller 324, a Content Provider 325,
among other providers of financial and related services. The integrated
transaction
management system 300 can communicate with the remote service providers 320 by
using any secure communication or financial data network.
The integrated transaction management system 300 may further include a
variety of functional modules for providing a plurality of financial and other
information services according to an embodiment of the invention. The
functional
modules may each contain a combination of software and/or hardware for
performing
a task or a set of tasks. For example, a data processor, a memory, and an
instruction
set (i. e., computer programming code) may be all that are needed for such a
functional
module to carry out the tasks necessary for a given embodiment of each
functional
module. More commonly, however, multiple input and output devices, a plurality
of
short term and long term memory systems, a plurality of layers of computer
code (i. e.,
operating system, application software, etc.), a plurality of communication
devices,
and multiple processors may be used for each such functional module.
Additionally,
multiple ones of such functional modules may share the same hardware and
portions
of a software library. In some cases, a functional module may contain one or
more
other such functional modules. As will be understood by those of ordinary
skill in the
art, the functional modules described herein may be embodied in a large number
of
equivalent combinations of code objects and hardware. The combinations
represented
by the functional modules described herein are conceptual and should not be
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-15-
construed as a limiting structure for the multiple hardware and software
combinations
capable of executing the functional modules' tasks.
As shown in Figure 3, the integrated transaction management system 300
includes an Interface System 330, an Application System 340, a Gateway System
350,
and a Cryptography System 360. The Interface System 330 includes one or more
functional modules each of which provides one or more user interfaces
accessible
through a variety of service end points 310. The Application System 340
includes one
or more functional modules, each of which provides functional processing
capabilities
for one or more consumer applications, including a capability of formulating
data
queries and transaction requests for service providers 320. The Gateway System
350
includes one or more functional modules for routing a plurality of
communications
between a variety of disparate networks or communication systems using a
plurality of
different communications, data transfer, and encryption protocols. The
Cryptography
System 360 includes one or more functional modules for encrypting and
decrypting
data according to one or more secure encryption standards.
The Interface System 330 includes one or more functional modules for
presenting and exchanging information through a plurality of thin-client end
points or
terminal devices. The Interface System 330 may access one or more of the
functional
modules providing the plurality of consumer applications within the
Application
System 340, and may provide an interface between such Application System 340
and
a consumer as is appropriate to the varying bandwidths, memory capacities,
processing abilities, input and navigation methods, and common uses and
environments of the plurality of service end points 310 which may be utilized
by the
user. For example, an interface compatible with an SMS device may be limited
to 160
text characters for sending and receiving information. A WAP device provides
greater versatility and, therefore, an interface used in connection with such
a WAP
device may include graphics and other data, but may need to be designed for
the
limited bandwidth and memory of most WAP devices. Web-based devices may have
any range of capabilities, depending largely on the type of terminal device
and the
bandwidth, memory, and input capabilities of the intended terminal device.
Even
within a particular communications protocol, it may be preferable to offer
multiple
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-16-
interface options depending on the attributes of a range of possible terminal
devices
and users.
As shown in Figure 3, the Interface System 330 includes a Web Interface
module 331, an SMS Interface module 332, a WAP Interface module 333, an ATM
Interface module 334, and a POS Interface module 335. Other interface modules
may
also be supported by alternate embodiments, such as interface modules
supporting
other wireless protocols and communications networks, voice interface modules
for
telephone access, proprietary and LAN interface modules for secure limited
access
special services (e.g., for service provider and system administrator side
transactions
and services), and additional interface modules to support the new and
specialized
capabilities of future networkable communication devices.
The Web Interface module 331 provides a number of dynamically generated
HTML documents to interactively exchange information with a user. These HTML
documents may be provided with a specific locator on a WAN, such as a URL
compatible with the World Wide Web portion of the Internet. The Web Interface
module 331 may also include a web site for offering a plurality of online
banking,
money management, investing, bill management, and other financial services.
The
Web Interface module 331 may fiuuther provide a number of specialized web
interfaces for different applications, terminal devices and client software
specifications, and user needs. The Web Interface module 331 may be accessible
to
the user via any Web-enabled device, such as a PC, a WebTV, or another
Internet
appliance. The back end operations for the services offered through Web
Interface
module 331 may be provided by one or more applications in Application System
340.
For example, Web Interface module 331 may link one or more applications in
Application System 340 to specific icons or a plurality of terminal device
function
keys available to the user and may use data stored in the terminal device or
another
data repository to automate application transactions.
The SMS Interface module 332 of Interface System 330 provides one or more
short text messages for interactively exchanging information with a user. SMS
Interface module 332 may provide one or more interfaces each with a plurality
of
limited functions that utilize text-only messages of up to 160 characters for
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-17-
exchanging information. SMS Interface module 332 may further provide one or
more
interfaces each designed for a plurality of limited input options compatible
with a
plurality of limited input capabilities, such as a standard telephone pad with
or without
additional function keys, as are provided in some SMS-enabled devices. SMS
Interface module 332 may be accessible to the user via any SMS-enabled device,
such
as a cellular phone, an alphanumeric pager, or an other wireless device with a
limited
display. The back end operations for the services offered through SMS
Interface
module 332 may be provided by one or more applications in Application System
340.
The WAP Interface module 333 may be used to provide one or more interface
pages, such as pages written in Wireless Markup Language (WML), for
interactively
exchanging information with a user. The WAP Interface module 333 may provide
one or more interfaces each with a plurality of display and input requirements
limited
to those of common WAP-enabled terminal devices and a plurality of bandwidth
and
memory requirements appropriate to WAP enabled devices. The WAP Interface
module 333 may be accessible to the user via any device supporting WAP, such
as a
mobile phone, a pager, a two-way radio, a smart phone, a communicator, and
other
handheld wireless device. The back end operations for the services offered
through
the WAP Interface module 333 may be provided by one or more applications in
the
Application System 340.
The ATM Interface module 334 provides one or more interface screens for
interactively exchanging information with a user through an ATM, such as ATM
317.
The ATM Interface module 334 provides interface data to one or more ATMs using
thin-client software (e.g., a browser) or non-browser based fat client to
provide a
plurality of consumer services. In one embodiment, the ATM Interface module
334
hosts a plurality of HTML pages accessible by a thin-client ATM using client
software
and communication protocols (e.g., TCP/IP) similar to those used to post Web
pages
on the World Wide Web. An ATM 317 communicating with the ATM Interface
module 334 may offer a plurality of consumer services traditionally offered
through
ATMs, such as a plurality of deposit, withdrawal, transfer and account
inquiries
services, as well as providing access to additional applications, such as
account
management, transaction management, event messaging, goods and services
delivery,
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-18-
money management and investing, finance and convenience-related content and
advertising, among other functions. The ATM 317 may be any ATM, including an
institutional ATM, an isolated ATM (such as a standalone ATM in a malls or
retail
establishment), a general purpose kiosk and a convenience station, and an
other
networked computer with a currency dispenser. The ATM Interface module 334 may
also be used as a gateway for providing limited access to a plurality of
applications for
ATMs which use resident interface softwaxe to provide a consumer interface.
The
back end operations for the services offered through the ATM Interface module
334
may be provided by one or more applications in the Application System 340.
The POS Interface module 335 may include one or more interface screens for
interactively exchanging information with a user through a POS system, such as
POS
318. The POS Interface module 335 may provide interface data to one or more
POS
systems using thin-client software (e.g., a browser) or non-browser based fat
client to
provide a plurality of consumer and/or retailer services. The POS Interface
module
335 may host a plurality of HTML pages accessible by a thin-client POS using a
plurality of client software and communication protocols (e.g., TCP/IP)
similar to
those used to post Web pages on the World Wide Web. A POS system
communicating with the POS Interface module 335 may offer core services for
the
POS system, such as electronic payment transactions, electronic order
aggregation,
and consumer transaction verification and authorization services. The POS
system
communicating with the POS Interface module 335 may also provide access to a
plurality of additional applications, such as account balance inquiries and
transfer,
account management, transaction management, event messaging, goods and
services
delivery, money management and investing, finance and retailer related content
and
advertising, among other functions. The POS system may include a retail POS
system
staffed by a clerk and offering at least a limited consumer interface (such as
a card
swipe with an alphanumeric display), an unstaffed POS system (such as a
vending
machine, an automated checkout system, etc. ), a goods and services vending
kiosk and
convenience station, and any other public networked computer that is used for
vending goods and services directly to the consumer. The POS Interface module
335
may also provide a gateway for limited access to applications for POS systems
which
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-19-
use resident interface software to provide a consumer interface (e.g.,
proprietary
systems fully integrated with a retail inventory management system). The back
end
operations for the services offered through the POS Interface module 335 may
be
provided by one or more applications in Application System 340.
The Application System 340 includes one or more modules for providing the
fixnctional processing for one or more consumer applications, including
formulating
data queries and transaction requests for service providers 320. The
Application
System 340 provides a variety of consumer applications according to a modular
architecture that promotes interchangability, upgradability, and universality
for access
by a variety of interface modules serving a variety of service end points 310.
The
Application System 340 utilizes data provided by a variety of external service
providers 320, as well as an internal system and data resources. A single
application
transaction may simultaneously or sequentially access data from, or initiate a
data
exchange with, more than one service provider 320 system. The Application
System
340 may formulate a plurality of queries and issue a plurality of data
exchange
requests based upon a variety of protocols dependent on a destination system
and the
information sought by a user. The Application System 340 may use a combination
of
Standard Query Language (SQL) and a plurality of alternate data exchange and
transaction protocols, depending on the compatibility of the service provider
320
systems with the Application System 340. The Application System 340 may use a
plurality of modules for providing a plurality of service applications
substantially
similar to the modular system 200 described above with regard to Figure 2.
Some
example application modules that may provided through the Application System
340
include an Account Access module 341, an Account Management module 342, a
Transaction Management module 343, an Event Messaging module 344, and a Goods
and Services Transaction module 345. Each application module may include a
variety
of transaction modules for performing the variety of functions which may be
included
within the application module. The possibilities for additional application
modules
and alternative arrangements of application modules and component transaction
modules are infinite.
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-20-
The Account Access module 341 provides a user with access to account
information through any of the interfaces and terminal devices or end service
points
310 described above. Some example transaction modules include a module for
initiating an account balance inquiry which causes a specified service
provider 320 to
reply to the user with a current balance in the user's account, a module for
requesting
a mini-statement of an account history, or a module for conducting a transfer
of a
specified amount of funds from one of the user's accounts to another of the
user's
accounts. Additionally, a user may initiate a request to change the user's
password, a
message relating to a report that one of the user's cards has been stolen, or
a request to
place an order for checks from a financial institution service provider 320.
The user
may request to receive messages or alerts of a specified frequency via one or
more of
the specified service end points 310 relating to any of the above-described
transaction
modules. For example, the user may request to receive an alert once a day to
inform
the user of the user's balance in any one or more account. Further description
of
messages and alerts is provided below with regard to Event Messaging module
344.
The Account Access module 341 may also perform a login, a user verification,
or a
security transaction, such as requiring a user to input a user identifier
(e.g., a user
name, an account number, magnetically encoded card information, etc.) and a
PIN/password. In one embodiment, one or more user-specific identifiers or PINS
may
be retained in a terminal device or an external data repository for more
convenient
access by the user. In one embodiment, a single login, a user identification,
or a
security transaction may be sufficient for conducting multiple transactions
through
one or more of the application modules. The Account Access module 341 may be
connected to a variety of account types such as a plurality of checking
accounts,
saving accounts, brokerage accounts, credit card accounts, retail credit
accounts, and
other accounts. In one embodiment, the Account Access module 341 may offer a
plurality of simultaneous or sequential accesses to a variety of accounts held
by the
same user through one or more service providers 320.
The Account Management module 342 provides access to a plurality of
account management functions through any one or more of the interfaces and
terminal
devices or end service points 310 described above. Some example account
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-21-
management transaction functions might include a plurality of changing
passwords,
openng an account, closing an account, reporting a lost or stolen bank or
credit card,
ordering checks, and initiating other customer service inquiries. As described
above
for the Account Access module 341, the Account Management module 342 may
include a login, a user verification, or a security transaction to ensure that
management transactions are accepted only from the proper account holder.
Also, as
described above for the Account Access module 341, a variety of accounts may
be
accessed through the Account Management module 342. In one embodiment, the
Account Management module 342 may include a two-way messaging platform for
providing a variety of consumer service inquiry applications. The two-way
messaging
platform may include a plurality of transaction modules such as a topic
inquiry
module (to return a list of available customer service topics), a send message
module
(to address a message to one of the customer service topics), a read messages
module,
and a delete messages module. The two-way messaging platform may also include
a
plurality of service provider side transactions modules, such as a reply to
message
module (for replying to a particular user message) and a broadcast message
module
(for sending a message to all or a portion of users).
The Transaction Management module 343 may further provide for a plurality
of automated or on-demand transactions with a plurality of service providers
320 that
allow electronic billing, presentment, and/or payment of bills through any of
the
plurality of interfaces, terminal devices or end service points 310 described
above.
Some example transaction management transaction modules included in
Transaction
Management module 343 include a billing account balance inquiry module, a bill
detail access module, a bill payment module, a creating/editing/deleting
automatic bill
payment module, a change contact information module, and a plurality of other
modules providing other customer service inquiries capabilities. The
Transaction
Management module 343 may also include a module for management of a plurality
of
Account Clearinghouse (ACH) transactions. As described above for the Account
Access module 341, the Transaction Management module 343 includes a login, a
user
verification, or a security transaction module. Also, as described above for
the
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-22-
Account Access module 341, a variety of accounts may be accessed through the
Transaction Management module 343.
The Event Messaging module 344 provides one or more scheduled or
conditional financial information and management messaging services through
any of
the interfaces and terminal devices or end service points 310 described above.
Some
example messaging services might include a scheduled balance information
service
for providing a regularly-scheduled update message alerting a user of the
user's
current checking account balance, a conditional changes in the account balance
message (e.g., a message warning the user of when a transaction takes the
account
below its minimum required balance), a transaction notification message
service for
reporting a plurality of transactions to the user, such as a POS or ATM debits
over a
customer specified amount limit, or a notification of completion of an ACH
transaction, a rate change information message for providing the user with a
notification when interest rates change, and a service enabling a user to
create, edit or
delete the user's messaging service subscription. The Event Messaging module
344
may enable a user to receive messages containing informational content, such
as stock
prices, sports scores, weather, event reminders, advertising and marketing
information, and other general convenience information, on a separate
subscription
basis or as part of the user's financial messaging services. The Event
Messaging
module 344 may provide the user with such notification and content delivery
through
more than one service end points 310. For example, the user may receive an SMS
message via a cellular phone 312 providing the user with a notification and
limited
message content. The user may then access ATM 317 to access additional message
content. The Event Messaging module 344 may also use a combination of a
plurality
of messaging service subscriptions and personalized conditional filtering to
govern
message delivery to individual users. Enhanced security may be provided by
requiring
the user to execute a login, a user verification, or a security transaction,
as described
above for the Account Access module 341, prior to use of the ATM 317.
The Goods and Services Transaction module 345 provides for an actual
delivery of goods and/or services through any of the interfaces and terminal
devices or
end service points 310 described above. Examples of such goods and services
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
- 23 -
transactions which can be performed by the Goods and Services Transaction
module
345 include a sale of prepaid long distance service, a sale of cellular phone
or an
Internet access service, a cash withdrawal in conjunction with a POS system,
and a
person-to-person goods/services transaction. For example, a voucher, including
an
access code or a verification number, may be delivered to a terminal device,
such as
the ATM 317. The voucher may be exchanged by the user for services or goods
desired by the user. Each type of transaction that may be performed by Goods
and
Services Transaction module 345 may include a service request transaction, a
voucher
verification transaction, and a voucher redemption transaction. For example, a
user
with a cellular phone could realize that she is running out of prepaid air
time for the
use of the cellular phone. A service request transaction could be submitted by
the user
to the Services Transaction Module 345 via use of her cellular phone, the user
could
then transmit to the Services Transaction module 345 one of the user's debit
or credit
account numbers for payment for a purchase of additional prepaid air time, and
an
access code could be issued to the user by the Services Transaction module
345. The
access code could then be submitted by the user via the cellular phone to a
phone
company. The phone company would verify the access code and credit the user's
phone account by the amount of the payment. The amount of the payment could
then
be deducted from the user's funds in a bank account and paid to the telephone
company through various EFT channels. A similar process could be followed for
conducting any transaction between any two parties, as long as one party is
able to
submit a request for a voucher to Services Transaction module 345 and the
other party
is able to verify and redeem the voucher. In one embodiment, the verification
and
redemption functions may be combined as a single transaction. In one
embodiment,
the function of submission of the voucher to the redeeming party may be
automated
such that neither party actually sees the voucher. For example, in the
transaction for
the purchase of prepaid air time described above, the request for prepaid air
time may
cause a voucher to be automatically forwarded to the phone company for
processing.
Different devices may be used for requesting and receiving a voucher versus
submitting the voucher for verification and redemption. For example, the user
may
use an ATM 317 to request and receive the voucher, but may then enter the
voucher
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-24-
number just like a credit card number at the beginning of a telephone call
placed from
any telephone.
As shown in Figure 3, the Gateway System 350 includes one or more modules
for directing communications between one or more of a variety of disparate
networks
or communication systems by using different communication, data transfer, and
encryption protocols. For example, Gateway System 350 may include an EFT
Protocol module 351, an Internet Protocol module 352, and a Proprietary
Connection
Protocol module 353. The Gateway System 350 may further include a
communication
gateway, substantially as described above with regard to the Communication
Gateway
110 in Figure 1.
As further illustrated in Figure 3, the Cryptography System 360 includes one
or more modules for encrypting and decrypting data according to one or more
secure
encryption standards. The Cryptography System 360 further includes
cryptography
hardware and software substantially as described above for the Cryptography
System
121 in Figure 1.
Figure 4 shows an example method for providing an event messaging
application using an integrated transaction management system, such as the
systems
described in Figures 1-3. The event messaging application described allows a
user to
select or subscribe to one or more of a plurality of available scheduled
and/or
conditional alerts. The alerts themselves include some form of notification
through
one or more service end points connected to one or more communication networks
interfacing with the integrated transaction management system. The alerts may
also
include messages or additional data, such as sound, graphic, and data files.
The alerts
may be executed through a single delivery, may be interactively delivered, or
may
include a partial delivery and prompt the user to access additional alert
content
through an alternate service end point or procedure. The alerts may be used to
provide
real-time financial data and account and transaction monitoring, access to
current
information (e.g., sport scores, weather, etc.), or simple reminders of events
and
appointments. The steps described below are provided as examples only and
should
not be construed as limiting the scope of event messaging applications or
other
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
- 2S -
consumer applications that may be enabled through an integrated transaction
management system.
In step 401, the user may register for alert services. Registration for alert
services may include the selection of one or more predefined alert service
subscriptions, such as account balance updates, minimum balance alerts,
transaction
alerts, sport scores, weather updates, and other services. Alert service
subscriptions
define the general content and type of alerts the user will receive.
Additional
conditions, information filters, and handling instructions may be provided on
a user-
by-user basis. Registration for alert services may include establishing a
rules database
and a registration database or may utilize or augment an existing rules
database and
registration database (or records contained therein). The registration
database
includes a plurality of tables for customizing the event messaging for a
particular
user's preferences including a table linking the user's unique id number with
all of the
user's bank accounts, a table linking the user's unique id number with all of
the user's
debit and credit cards, and a table linking the user's unique id number with a
description of one or more service end points through which the user would
like to
receive the messages to be delivered, including, for example, a PDA, a
cellular phone,
a PC, a portable computer, a telephone, a facsimile machine, an ATM, or a POS
system. The registration database further includes a table linking the user's
unique id
number with a password for the user for accessing the integrated transaction
management system, and a table describing a plurality of notification rules to
use to
determine a plurality of events for which the user wishes to receive messages,
for
example, a rule defining a frequency for which the messages are to be
delivered, a rule
defining any constraints on the service end points to be used for delivery of
the
messages (for example, no use of a telephone after 10:00 p.m. and to use email
via the
PC after such time instead). The rules and registration databases may also be
utilized
by the transaction management system to enable other financial service
applications,
in addition to the event messaging application, and to define preferences for
use
within those services. It is preferable that the user input the information
required for
the registration database initially through a single set-up procedure prior to
any use of
the event messaging application. Once the set-up procedure is completed for
the user,
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-26-
the user's registration database is stored as a unique profile in a data
resource which is
part of or in communication with the integrated transaction management system.
Thereafter, the user may utilize any one or more of the defined service end
points to
perform the plurality of financial and other information services as described
above.
When a remote service provider wishes to offer its customers use of the
integrated
transaction management system it may require access to or a copy of each of
the
plurality of users' registration databases so that it may correlate each of
the users with
each of the users' preferences saved in the registration databases.
In step 402, the user may add, edit, or delete one or more alert subscriptions
and may be able to modify some or all of the preferences stored in the rules
and
registration databases. As is known by a person of ordinary skill in this
field, a user
may change the password, the notification rules and any of the other user
preferences
initially stored in the registration database by accessing the system through
one or
more service end points enabled for application maintenance. Step 402 may be
invoked at any time after initial registration of the user.
In steps 410 and 420, one or more alert transactions may be initiated through
the event messaging application in the integrated transaction management
system.
Alert transactions may be based upon a scheduled event service (step 410) or a
conditional event service (step 420). Scheduled event services include alerts
that are
based upon a scheduled event, such as a weekly update, an event on a
particular date
or time, or another schedule. Conditional event services are those based upon
the
occurrence of one or more conditions, such as a checking account falling below
a
particular balance. Some scheduled events, may have conditional filters
applied to
them and some conditional events may require scheduled monitoring to
periodically
evaluate whether the conditions have been met. An alert transaction may
contain all
of the information necessary for evaluating alert conditions, data filtering,
message
handling, and message content. For example an alert transaction for an account
balance update may include an account number, account balance, a time and date
stamp indicating when the data was generated by the bank accounting system,
and
other information. Initiation of an alert transaction for execution by the
application
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-27-
system may be dependent on a preliminary evaluation of initiation triggers for
both
scheduled or conditional alerts.
An alert transaction based upon a scheduled event (step 210), may be initiated
dependent upon evaluation of an event schedule (step 211) or receipt of a
service
message from an outside service (step 212). Evaluation of an event schedule
(step
211) may initiate an alert transaction of a particular kind for a particular
user or user
account when the scheduled time arrives. For example, if a user has a
scheduled alert
to receive his or her current checking account balance at 9:30 am every
Monday, then
when a clock in the integrated transaction management system indicates that it
is 9:30
am on a Monday, a new alert transaction is initiated for that user. The alert
transaction may or may not require that the system initiate a service to
retrieve data
from an outside service provider. In the case of a checking account balance, a
query
service (step 213) may be sent to the bank's accounting system. Alternatively,
a
service schedule may be maintained by an outside service provider and the
transaction
management system may receive a service message (step 212), such as an XML
message, from the outside service provider containing the necessary outside
data. For
example, the bank may send a message containing the account balance at the
scheduled time or a weather service provider may send the morning weather
update at
a scheduled time. When a message containing data for a scheduled alert is
received, it
may be filtered to ensure that the alert is indeed scheduled with the
transaction
management system (step 414) and not the result of a mistake at the bank or
another
type of service request. In one embodiment, commonly scheduled events for
multiple
users or accounts may be batch processed through a combined query to a bank
accounting system or a combined message from a bank accounting system. Once
the
alert transaction is initiated and contains the data upon which the alert
message is to
be based, the data and one or more system conditions may be evaluated against
the
rules database in step 430.
An alert transaction based upon a conditional event (step 420) may be
initiated
based upon a message received from a service provider (step 421) or any
transaction
directed through a communication gateway that is part of the transaction
management
system (step 422). Some alerts which appear to be conditional event alerts to
the user,
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-28-
may be initiated through periodic evaluations of the event conditions on a
schedule as
described above for scheduled event alerts. Much as described above for step
412, a
message may be received from a service provider containing the data upon which
a
conditional alert may be based (step 421). In this way, banks and other
service
providers may locally monitor changes in account balances and other conditions
and
only forward data on the changed conditions when notification conditions are
met.
Note, that the conditions upon which the bank forwards the data to the
transaction
management system need not be the same conditions as the alerts themselves.
The
transaction management system may evaluate the data contained in some or all
of the
transactions directed through its communications gateway to discern changes
that
effect alert conditions (step 422). A filter may be applied to transaction
data in order
to redirect relevant data to an alert transaction if the data has a candidate
for an alert
(step 423). For example, the filter may be applied to compare the account
number in a
withdrawal transaction directed through the gateway to a list of account
numbers
enabled for minimum account balance alerts. The data from any withdrawal
transactions with matching account numbers could then be used to initiate an
alert
transaction. Messages received from banks containing transaction information
or data
provided expressly for initiating alerts may also be f ltered to determine
alert status.
Once an alert transaction has been initiated containing transaction data
relevant to alert conditions, each alert candidate is evaluated against the
rules database
for the specific user and/or user account to which the alert relates (step
230). The
rules database may act as an additional layer of filtering to determine
whether
individually defined alert conditions are met. For example, a withdrawal
transaction
may provide the basis for initiating an alert transaction within the system.
However,
the individual user's rules database entry may specify that only withdrawals
over $100
should be the basis for an alert and may further specify that withdrawals in
the amount
of $1,500 by XYZ Mortgage Company are not to be the basis of an alert (even
though
it meets the other alert criteria). Custom filtering on a user-by-user basis
provides
detailed personalization for individual users. The rules database may also
provide
handling instructions for delivery of a desired alert. For example, the user
may
specify a particular service end device and address at which to receive
different types
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-29-
of alerts. Custom handling instructions may allow the user to define varying
handling
instructions, such as delivery device, security protocol, or content format,
based on
alert type, content, and delivery time.
In step 240, alert message delivery is initiated. Alert message delivery may
be
handled by the transaction management system as a service directed to a
communication address through communications gateway. For example, the alert
message may be delivered through an electronic mail message, an SMS page, an
automated voice service (for telephone or cellular telephone delivery), or
another
method. In one embodiment, initial message delivery may provide notification
of the
availability of additional alert content and the user may be prompted to
initiate a
transaction through one or more service end points to receive the full alert
message.
For example, the user may receive a short message to notify her of the
availability of
an account statement or bill (e.g., a credit card bill). The user could then
initiate a
transaction to view the full account statement or bill through an ATM, over
the
Internet, or through any other system supported by the applications and
interface
servers. The event messaging application may provide secure delivery (step
241) .
which requires authentication of the user's identity prior to delivery of the
full
message content. This may be provided through a notification system that then
requires the user to access the full content through a transaction with
security
protocols or may be delivered through an interactive transaction that prompts
the user
to enter a password, PIN, or other user authentication information. The event
messaging application may provide fox delivery and require a response from the
user
(step 242). This may allow the user to establish rules for transaction
authorization
before transaction processing is complete. For example, the event messaging
application may notify the user of an attempted transaction over $100 using
the user's
credit card (and directed through the communication gateway). The user may
then be
able to provide a response, such as by dialing a particular number or sending
a short
message through a two-way short messaging system to either accept or decline
the
attempted transaction. The event messaging system may provide for alternate
and
.delayed delivery of alert messages. The user may define a hierarchy of
delivery
methods or delivery conditions which the system may sequentially work through
in
CA 02418991 2003-02-07
WO 02/13120 PCT/USO1/06922
-30-
response to failed delivery attempts. Among the delivery conditions may be a
hold
command that holds the alert message until a determined time before making
another
delivery attempt. In this way, alerts may be delivered according to the user's
schedule
and repeated attempts may be made in the event that a delivery method does not
work,
such as due to the user's cellular phone or pager being turned off
This invention has been described in connection with the preferred
embodiments. These embodiments are intended to be illustrative only. It will
be
readily appreciated by those skilled in the art that modifications may be made
to these
preferred embodiments without departing from the scope of the invention as
defined
herein.
