MULTIFUNCTIONAL MOBILE BANKING SYSTEM

Abstract: An integrated transaction management system (300) includes a communications gateway (350) for conducting communications and transactions with a plurality of financial data networks utilizing a plurality of communications protocols, a plurality of interface servers (330) providing an interface between a user and a plurality of financial service applications including ATMs (333), POS (335), Internet-based banking (314), telephone-based banking, wireless short messaging services, and wireless applications (312) protocol-based banking.

Description: 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 financial 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 funds 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- 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 fransfer 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. 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 Description 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. 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 Description 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 110 and an Application Server 120 which each act as an 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 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 141a 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 110 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 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 161a connects Communication Gateway 110 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 AS/400 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 platfonn 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 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 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 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, for 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. 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 fransfer 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 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 230 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 PIN, 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. 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 function(s) 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 function(s) locally using the transaction data and local resources and system information, however, their function(s) may be only a portion of the total function(s) 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 fransaction 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 response where response times 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 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 261 and 262 may each include information requested by Application Object 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 210 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 Figure 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 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 fransaction 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 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 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 further 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 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, 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 software 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 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 functional 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. 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 management transaction functions might include a plurality of changing passwords, opening 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 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 fransaction, 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 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 fransaction, 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 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 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, 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 fransaction 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 fransaction 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 occunence 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 system may be dependent on a preliminary evaluation of initiation triggers for both scheduled or conditional alerts. An alert fransaction 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 fransaction may or may not require that the system initiate a service to refrieve 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, 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 fransaction. Messages received from banks containing transaction information or data provided expressly for initiating alerts may also be filtered to determine alert status. Once an alert transaction has been initiated containing fransaction 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 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 for 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 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.

Claims: WHAT IS CLAIMED IS; 1. An integrated transaction management system comprising: a) a communication gateway for communicating fransaction data to and from at least one of a plurality of financial data networks utilizing one or more of a plurality of communications protocols; b) an application system comprising a plurality of modular financial service applications, said application system communicating transaction data for at least one of the plurality of modular financial service applications to and from at least one of the plurality of financial data networks through said communication gateway. c) at least one interface server, said interface server providing interfaces between said application system and at least one of a plurality of service end points. 2. The integrated transaction management system of claim 1 wherein the plurality of modular financial service applications includes: a) an account access service; b) an account maintenance and management service; c) an automated transaction management service; and d) an event messaging service. 3. The integrated transaction management system of claim 1 wherein the plurality of modular financial service applications includes an account access service, said account access service including at least one of a plurality of service transactions including account balance access, account history access, and balance transfer access. 4. The integrated transaction management system of claim 1 wherein the plurality of modular financial service applications includes an account maintenance and management service, said account maintenance and management service including at least one of a plurality of service transactions including opening a new account, closing an existing account, changing a user password, reporting a lost/stolen card, check ordering, initiating a customer service request. 5. The integrated transaction management system of claim 1 wherein the plurality of modular financial service applications includes a transaction management service, said transaction management service including at least one of a plurality of service transactions including billing account balance inquiry, bill detail access, bill payment, automated bill payment management, changing contact information, initiating a customer service request. 6. The integrated transaction management system of claim 1 wherein the plurality of modular financial service applications includes an event messaging service, said event messaging service including at least one of a plurality of service transactions including messaging service maintenance, messaging service customization, and message content access. 7. The integrated transaction management system of claim 6 wherein the user selects at least one messaging service for a plurality of messaging services including scheduled account balance updates, conditional account balance updates, conditional transaction updates, completed transaction updates, financial information updates, and other information updates. 8. The integrated transaction management system of claim 1 further comprising a universal registration database containing a plurality of tables including a table linking a user to one or more of the user's account numbers and a service provider identification for a service provider associated with each of the user's account numbers. 9. The integrated transaction management system of claim 8 wherein the plurality of tables include a user's account numbers for the user's bank accounts, credit card accounts, billing accounts, and brokerage accounts. 10. The integrated transaction management system of claim 1 wherein the plurality of modular financial service applications includes a two-way messaging application for exchanging messages between a user and a service provider through at least one of the plurality of service end points. 11. The integrated transaction management system of claim 1 wherein the plurality of modular financial service applications includes: a) a savings account service; b) a checking account service; c) a credit card service; d) a debit card service; e) a brokerage account access and management service; f) an automatic transaction management service; g) an event messaging service; and h) a goods and services transaction service. 12. The integrated transaction management system of claim 1 wherein the at least one of the plurality of service end points includes: a) a plurality of personal digital assistants; b) a plurality of cellular or mobile telephones; c) a plurality of personal computers; d) a plurality of portable computers; e) a plurality of telephones; f) a plurality of facsimile machines; g) a plurality of Automated Teller Machines; and h) a plurality of POS systems. 13. The integrated transaction management system of claim 1 further comprising a cryptography system for providing for encryption of data. 14. The integrated transaction management system of claim 1 wherein the financial data gateway includes a plurality of communications channels and a plurality of network connections and a hub for directing and routing traffic in electronic financial data to a destination financial data system. 15. The integrated transaction management system of claim 14 wherein the plurality of communications channels includes a standard EFT pipeline, a B2B connection using Internet transaction protocols, and a dedicated line connection. 16. The integrated transaction management system of claim 1 wherein the plurality of financial service applications make use of information gathered from or exchanged with one or more of a plurality of remote service providers, the one or more of the plurality of remote service providers including a bank, a credit card company, a GSM operator, a biller, and a content provider. 17. The integrated transaction management system of claim 16 wherein the plurality of financial service applications includes a plurality of functional modules for providing a capability of formulating one or more data queries and one or more transaction requests of one or more of the plurality of remote service providers. 18. The integrated transaction management system of claim 1 wherein the plurality of interface servers includes at least one web interface server, at least one SMS interface server, at least one WAP interface server, at least one ATM interface server and at least one POS interface server. 19. A method of providing financial services through a plurality of service end points comprising the steps of: a) providing a transaction system including a plurality of user application interfaces accessible through the plurality of service end points; b) accepting a user service request through at least one of the plurality of service endpoints; c) creating a transaction object within the transaction system including transaction data corresponding to the user service request; d) selecting a plurality of provider objects based upon the transaction data and system conditions for executing pre-defined portions of the user service request; e) accessing a financial data network from the transaction system to execute at least a portion of the user service request; f) compiling results returned from the plurality of provider objects within the transaction object; and g) returning a transaction result based upon the compiled results from the plurality of provider objects to the at least one service endpoint from which the user service request originated. 20. A method of providing event messaging through a transaction system based upon a financial data contained in at least one of a user's financial accounts comprising the steps of: a) monitoring at least one of a plurality of user financial accounts for an account event; b) filtering detected account events according to at least one alert condition; and c) initiating an event message to a user defined service endpoint based upon a detected account event meeting the at least one alert condition. 21. The method of claim 20, further comprising the step of evaluating a detected financial transaction meeting the at least one alert condition against a user defined rule database to determine message delivery conditions and destination. 22. The method of claim 20, wherein account events include periodic evaluations of account balances. 23. The method of claim 20, wherein account events include any financial transaction that changes a user account balance. 24. The method of claim 20, wherein account events include a change in an account transaction status, an account payment due date, or a change of account terms.

Inventors: CLARY JEFFREY S, LILES KEVIN G, MILLS MARK A, VRANA KENNETH J, CLARY, JEFFREY, S., LILES, KEVIN, G., MILLS, MARK, A., VRANA, KENNETH, J.
Applicants: EURONET SERVICES INC, EURONET SERVICES, INC.
Application year: 2001
Main classification: G06F17
IPC codes: G06Q20, G06Q40, G07F19