WO2001016828A1

WO2001016828A1 - System and method for conducting financial transactions on an internet enabled electronic funds transfer device

Info

Publication number: WO2001016828A1
Application number: PCT/US2000/020785
Authority: WO
Inventors: John A. Burns; Daniel Mallinger; Matthew W. Kinman; Samuel David Hartman; David Steven Blumenthal; Joyce Ann Konigsburg
Original assignee: Fundsxpress Financial Network, Inc.
Priority date: 1999-08-27
Filing date: 2000-08-21
Publication date: 2001-03-08
Also published as: AU7052500A

Abstract

An improved system and method for conducting online financial transactions via a public communications network (14) is discussed. The system includes a web-enabled ATM connected to the public communications network and a financial service provider's web site. The method for using the system includes checking user identification for permission to access the public communications network via the web-enabled ATM, establishing a secure encrypted session between the web-enabled ATM and a financial service provider's web site over the public communications network, validating a user login to the financial services provider's web site, presenting a variety of online financial transaction options to the user at the web-enable ATM, and processing the selected transaction option over the public communications network.

Description

SYSTEM AND METHOD FOR CONDUCTING FINANCIAL TRANSACTIONS ON AN INTERNET ENABLED ELECTRONIC FUNDS TRANSFER DEVICE

TECHNICAL FIELD

This invention relates to a system and method for using an electronic funds transfer device, such as an automated teller machine (ATM), and more particularly to an improved system and method for increasing the quantity and quality of financial transaction and other information available to a financial institution customer through connection with a public communications network.

BACKGROUND OF THE INVENTION With the rapid growth in popularity of public communications networks, particularly the Internet, it has become almost a necessity for banks and other financial institutions to be able to offer their customers the ability to conduct basic financial transactions, such as account balance inquiry, transfer of funds between accounts and electronic bill payment, without the assistance of a live teller. This ability permits the financial institution customer to perform financial transactions at the customer's convenience rather than during normal business hours. In order to meet this need, most financial institutions have arranged access to a network of self-service cash machines, commonly referred to as automated teller machines (ATMs), which allow their customers to conduct traditional ATM financial transactions (account balance inquiry, fund transfers between accounts and cash withdrawal) after inserting a plastic authorization card into the ATM and entering a validating personal identification number (PIN). A broader name for these types of self-service financial transaction systems is electronic funds transfer, or EFT.

Most existing ATMs use a private leased line between the ATM and the institution's core processing system to enable the conduct of financial transactions by their users. In order to ensure security of the financial transaction data transmitted over the leased line, a standard industry protocol, referred to as 911/912 messaging, is used. While the leased line and 911/912 protocol combination is fast enough to handle a relatively small numerical data stream, such as is common when conducting traditional ATM financial transactions, it is far too slow to handle detailed financial information such as account history, much less data- intensive information such as graphical content. Thus, most ATMs today restrict users to traditional ATM financial transactions involving no more than two accounts (primary savings and primary checking) and are not able to take advantage of the user's captured attention to provide data-rich content, such as graphics or video. As the technology surrounding ATMs has become more sophisticated, new machines with enhanced capabilities have been developed. In one existing version of such an ATM system, the ATM houses a local data storage device on which static information content has been previously placed for display to ATM customers. In a still more advanced ATM system, the ATM is connected to a second private data line over which additional information content is accessible. The disadvantages associated with these prior art systems are that it is expensive and time consuming to regularly update the local data storage drives to change the content that may be accessed and to update the software running on each ATM every time the software is modified. As for those ATM systems that are capable of receiving content from a content provider over a second line while also being able to conduct financial transactions over a dedicated 911/912 ATM network line, customer access to financial information has remained restricted to what the conventional ATM network will support: namely, traditional ATM financial transactions with a maximum of two primary accounts per user. For example, ATMs currently exist which have a private line over which traditional ATM financial transactions are conducted (using the 911/912 protocol) and a second line that provides a connection to the Internet. However, if the ATM customer accesses the Internet via the ATM machine, the customer is limited to visiting a pre-selected web site (typically that belonging to the financial institution that owns the ATM machine). Furthermore, financial information such as the customer's account information is not available over the Internet connection. Instead, general information about the financial institution and the services that it offers are displayed to the customer over the Internet connection.

There is therefore a need for an improved ATM system and method that permits a user to perform more complicated financial transactions through the ATM while accessing data- intensive information content including detailed financial information. There is an additional need for an improved ATM system and method that permits the efficient update of each ATM's software from a central point on the network rather than at each individual ATM location.

SUMMARY OF THE INVENTION

The system and method of the present invention make use of a public communications network such as the Internet to enable the conduct of financial transactions by a financial institution customer or debit cardholder over the network. The system includes a web-enabled ATM connected to the public communications network and a financial services provider's web site. The method of the current invention for conducting online financial transactions at a web-enabled ATM connected to a public communications network includes checking user identification for permission to access the communications network via the web-enabled ATM, establishing a secure encrypted session between the web-enabled ATM and a financial services provider's web site over the public communications network, validating a user login to the financial services provider's web site, presenting a variety of online financial transaction options to the user at the web-enabled ATM, and processing the selected financial transaction option over the public communications network.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 A shows the major components and connections in one embodiment of the present system for using an improved web-enabled ATM to conduct financial transactions over a public communications network via a financial institution network. FIG. IB shows the major components and connections in an alternate embodiment of the present system for using an improved web-enabled ATM to conduct financial transactions over a public communications network via a dial-up connection to an Internet service provider.

FIG. 2 is a flowchart depicting the initial steps of the present invention for conducting financial transactions over the systems of FIGS. 1A and IB.

FIGS. 3A and 3B are flowcharts of two different embodiments for establishing a secure connection between the web-enabled ATM and the financial services provider's web site arid logging onto the web site.

FIG. 4 is a flowchart depicting the final steps of the present invention for conducting financial transactions using a web-enabled ATM.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention is directed to a system and method for providing online financial services to financial institution cardholders and customers via an improved web- enabled ATM capable of conducting traditional ATM financial transactions while also permitting customers the option to access their financial information through a connection to a public communications network, such as the Internet. The term "Internet" or "web" used herein should be understood to mean any public communications network. As used hereinafter "ATM" shall also include any device using an ATM type authentication to validate the identity of the user regardless of whether the device dispenses cash. Such non- cash dispensing ATMs may also be described as financial transaction kiosks.

Figs. 1A and IB illustrate two alternate embodiments of the physical system 10 of the present invention. The main difference between the two embodiments is the way in which a connection is made to the public communications network. The majority of components in each embodiment are the same, and like components are referenced in both figures with the same reference numbers. In Fig. 1A, an Internet enabled ATM, or web-enabled ATM 12, is connected to the Internet 14 through a communication line 16 via a financial institution network 18 such as a LAN or WAN. The web-enabled ATM 12 incorporates a processor 22 running an operating system (not shown) and web browser software 24. For example, the processor 22 may be a microcomputer that processes and controls interaction between all parts of the web-enabled ATM 12. In the preferred embodiment, the processor 22 is a personal computer running the Windows NT operating system and is equipped with a 911/912 emulator and software, such as OPTinet, produced by Diebold, Incorporated of North Canton, Ohio. The web browser software 24 is the interface between the web-enabled ATM user and all other components of the web-enabled ATM 12. The browser software 24 refers to any human interface that meets computer industry, Internet or World Wide Web standards for defining a browser. The web browser software 24 used may vary and includes, for example, text-based browsers, EMAC browsers, Netscape™, Internet Explorer™, and Web TV™. The processor 22 has the ability to store local web content 26 in memory in the web-enabled ATM 12 as well as control the other components of the web-enabled ATM 12. Local web content includes any information that is typically viewable with a standard browser 24. The web-enabled ATM 12 also includes a terminal director 28 that manages and controls instructions and commands that pass between components within and software running on the web-enabled ATM 12.

A peripheral controller 30 is used to control all hardware devices and external connections to the web-enabled ATM 12. The peripheral controller 30 may include but is not limited to controlling the following items. One or more printers 32 may be housed in the web-enabled ATM 12 to provide a hard-copy record of any transactions carried out by the web-enabled ATM user. A cash dispenser 34 may be used to deliver cash requested by the web-enabled ATM user; however certain ATMs without a cash dispenser may also be used in connection with this invention. A card reader 36 pulls the web-enabled ATM user's card into the web-enabled ATM 12, reads the information on the magnetic stripe on the card, passes information to the terminal director 28 and returns the card to the user. One or more network cards 38 may be used to connect the web-enabled ATM 12 to a financial institution computer network 18, such as a Local Area Network (LAN) or a Wide Area Network (WAN). A 911/912 interface 42 allows the web-enabled ATM 12 to send and receive standard ATM transaction information that complies with 911/912 messaging standards. The capability to communicate with devices or networks that meet TCP/IP communications standards, such as the Internet, is furnished by a TCP/IP interface 44. As mentioned above, the web-enabled ATM 12 can process financial transactions requested by a user. This may be accomplished in at least one of two ways. First, the transaction request may be formatted to send 911/912 data packets to a traditional ATM processor 50 over a communication line 52 connected directly to the ATM processor 50. The traditional ATM processor 50 routinely handles 911/912 requests for the ATM system in general. Alternatively, the financial transactions can be routed via communication line 16 directly to a financial services provider web server 54 connected to the Internet 14 via a standard TCP/IP communication line 56.

Turning now to Fig. IB, the system 10 is shown with an alternate connection from the web-enabled ATM 12 to the Internet 14. In this embodiment, the web-enabled ATM 12 does not have a network card but instead contains a modem 40. In general, a modem 40 provides the capability to use analog telephone systems to dial a device or network that is physically or logically separated from the web-enabled ATM 12. The modem 40 connects the web-enabled ATM 12 to a traditional ATM network via a conventional 911/912 dedicated line 20. It also permits a connection 17 between the web-enabled ATM 12 and the Internet 14 via an Internet service provider 46. In short, any known method, including use of cable modems and DSL (digital subscriber lines), may be used to connect the web-enabled ATM 12 to the Internet 14. Figs. 2, 3A, 3B and 4 are flowcharts of the steps in the operation of the present invention to access financial information and conduct financial transactions using the web- enabled ATM 12 and system 10 previously described. As shown in Fig. 2, the user 210, i.e., the customer desiring to perform an online financial transaction, approaches a web-enabled ATM 12 operated by a financial services provider, swipes a cash or credit card and enters a Personal Identification Number (PIN) at step 212. At step 214 the user's card number and other information on the magnetic stripe is validated against a list of customers previously authorized by the financial services provider to use the web-enabled ATM in general and to access the Internet system through the web-enabled ATM. The validation step may occur either locally on the web-enabled ATM itself or remotely via a query issued by the web- enabled ATM to a remote database residing on an intranet or on the Internet. If the user 210 is not authorized to access the Internet system via a web-enabled ATM, the user 210 is presented with the traditional ATM screens at step 216 and can only use the web-enabled ATM to perform those transactions typically available at a traditional ATM. These traditional ATM functions are accomplished through use of the emulated 911/912 protocol messaging capabilities of the web-enabled ATM and system and the ATM verifies the user's card number and PIN as is known in the art. If, however, the user 210 has been authorized to use the Internet capabilities of the web- enabled ATM, the user 210 will be presented with the traditional ATM functions as well as the option to link to the Internet at step 218. In the preferred embodiment, the web-enabled ATM controls the link to the Internet, and the user can only access a particular web site, such as the financial services provider's Internet banking transaction site. The option to link may be presented to the user 210 in a wide variety of ways, any of which will allow the user to indicate the desire to link. As an example, the link option may appear as a button on the web- enabled ATM screen that can be activated by touch (i.e., a touch screen) or by depressing a physical button located on the web-enabled ATM itself. It is through this link option that an authorized user is able to access an increased number and variety of financial service options as compared to those available on a traditional ATM. At step 220, the system checks to see if the user 210 has selected the option to link to the Internet. If not, the user may conduct traditional ATM transactions as previously described in conjunction with step 216. If the user selects the Internet link option, the web-enabled ATM authenticates the user's card number and PIN against the inserted ATM card number at step 222. If the PIN or card number authentication fails, the user is not permitted to proceed further and the session is ended at step 224. The web-enabled ATM will then attempt to establish a secure, encrypted session over the Internet connection at step 226. Assuming the PIN and card number are authenticated, the ATM attempts to communicate with the financial services provider web server 54 in order to establish that it is a trusted ATM. This is accomplished at step 225 using digital identity verification, such as through the use of a digital certificate or similar means. Once the server verifies that the ATM is a trusted ATM, the user is allowed to log in to the web server as any valid user for that ATM. If, on the other hand, the ATM verification fails, the user is not permitted to proceed further as shown at step 227. It is important to note that from this point in the processing, the system of the present invention no longer requires or uses the customer's PIN in order to establish security or to process the requested financial transactions.

At this point in the processing steps of the present invention, the next step performed may be one of two alternate routes used to insure a secure connection between the^' web- enabled ATM and the financial services provider web server 54. These two alternate routes are shown in Figs. 3A and 3B, respectively. Fig. 3A shows the steps taken when digital identity verification is employed so that the system can recognize the web-enabled ATM as authenticated and secure, i.e., one belonging to the system and enabled to perform financial transactions over the Internet. Fig. 3B shows the steps taken when the web-enabled ATM used by the customer cannot be positively identified as a secure ATM and therefore additional verification is required to establish security for conducting the transactions. Fig. 3B itself shows two alternate processing paths, either of which can be used whenever the web-enabled ATM cannot be positively identified as a secure ATM.

With reference now to Fig. 3A, the process for authenticating the web-enabled ATM to ensure that it is one that has been enabled to perform financial transactions over the Internet is described. At step 225, the system automatically verifies that the connection is being established from a trusted web-enabled ATM 12. There are many different ways to automatically verify the web-enabled ATM's identity. A preferred method uses client-side digital certificates on the web-enabled ATM 12. Specifically, the financial services provider contracts in advance with a trusted third party, such as Verisign, Inc. of Mountain View, California, to issue separate electronic certificates for each web-enabled ATM. The certificates are then installed on each web-enabled ATM authorized to perform Internet financial transactions. When a user approaches a web-enabled ATM to perform a financial transaction, the web-enabled ATM will query the financial services provider's web server for a secure connection (such as through Secure Socket Layer). The web server then responds to the query with its certificate and requests that the ATM's certificate information be sent. Upon verification of the web server's certificate, the web-enabled ATM sends its certificate information to the web server. Upon verification of the web-enabled ATM's certificate, a session key is generated for use by the web-enabled ATM and the web server during the session in order to maintain security. In effect, the session key is a temporary password that both the web-enabled ATM and the financial services provider use to authenticate each other for the duration of the specific session connection between them. If the ATM's certificate information is not valid, the session is terminated at step 227. Otherwise, processing continues at step 228.

Another embodiment for authenticating the web-enabled ATM as a trusted ATM involves the use of a shared secret value. Each web-enabled ATM 12 has installed on it in advance a shared secret value, which is a long and cryptographically difficult-to-guess string of characters. This same string is also installed on the financial services provider's web server. A SHA checksum on the shared secret value and other related data is used to verify the identity of the web-enabled ATM 12. SHA is a publicly available, cryptographically strong algorithm for generating a checksum. At step 225, the system authenticates the identity of the web-enabled ATM 12. In particular, the web-enabled ATM 12 uses SHA hashing to create a checksum of the secret key, the ATM identifier, the user's financial institution identifier, and other related data. The web-enabled ATM 12 then queries the financial services provider's web server for a secure connection, and a secure communication channel using a session key is established as described above in connection with the digital certificate method. The web-enabled ATM 12 sends the checksum and all of the data that was used to create the checksum, except for the shared secret, to the web server through the secure channel. The web server uses an identical algorithm as the web-enabled ATM 12 to generate its own checksum, using the data transmitted from the web-enabled ATM 12 and the shared secret that has been pre-installed for this particular web-enabled ATM 12. If the checksum generated by the web server does not match the checksum that was passed to it from the web-enabled ATM 12, the communication session is terminated at step 227. Otherwise, processing continues at step 228.

At step 228, after a secure connection is established between the web-enabled ATM and the financial services provider's web server, the user 210 is presented with a modified form of the financial services provider's web page, in particular, one designed to enable the user to accomplish more complex financial transactions than those offered by a traditional ATM. The web server then searches its customer database 230 for the identity of all customers linked to the number of the card that was inserted. If customer links exist in the database 230 at step 232, the web-enabled ATM displays a list of the customer identities linked to the card and prompts the user 210 to log in as one of the listed identities at step 234. If the user card does not have a customer identity linked to it or if the user selects the option to log in as a user that is not currently linked to the card, the user is prompted to provide an access ID and passcode at step 236. After logging in as a new customer, the web-enabled ATM will check the access ID and passcode combination at step 237, and a query will issue against an access ID database 238. The access ID database 238 may be a part of or separate from the customer database 230. If the access ID and passcode combination are invalid at step 240, a message is displayed informing the user and a termination sequence which may contain a re-try feature follows at step 242. If the access ID and passcode entered are valid, step 244 updates the data in the access ID database 238 to reflect the link between the access ID and user's card number so that the user will be recognized as having a valid customer identity associated with the card at the next log in.

Turning now to Fig. 3B, the steps taken when the web-enabled ATM used by the customer cannot be positively identified as a secure ATM (i.e., the web-enabled ATM could not be authenticated as described above) are shown. Many steps in this embodiment are similar to those shown in Fig. 3A, and like steps are referenced in both figures with the same reference numbers. In the embodiment of Fig. 3B, additional verification is required to establish proper security before the user can conduct financial transactions from the web- enabled ATM over the Internet. As previously mentioned, there are two alternate processing paths shown in Fig. 3B. In the first path, the user may select from a list of customer identities that are linked to the inserted card. In particular, after a secure connection has been established between the web-enabled ATM and financial services provider's web site in step 226, the system searches for those customers that are linked with the card number on the card inserted by the user at step 228. All processing is identical to that described above in connection with Fig. 3 A except as follows. After the web-enabled ATM displays a list of the customer identities linked to the card and the user chooses one of the listed identities at step 234, the user is prompted to enter a passcode which corresponds to the customer identity chosen at step 235. Processing then passes to step 237 where the customer identity and passcode combination are validated. From this point on, further processing is performed as previously described in connection with Fig. 3 A.

In the second processing path shown in Fig. 3B, the user is not allowed to select a customer identity from a list provided by the web-enabled ATM. Instead the customer must provide both an access ID and passcode. Basically, all of the processing steps surrounded by the dashed line in Fig. 3B are removed from processing in this alternate path. Returning to the top of Fig. 3B, after a secure connection has been established between the web-enabled ATM and financial services provider's web site in step 226, the system prompts the user to enter both an access ID and passcode at step 236. From this point on, further processing is performed as previously described in connection with the first path described in connection with Fig. 3B. Thus, if the user either chooses one of the listed customer identities or if the user enters a valid access ID and passcode combination, the financial services provider's main web page for web-enabled ATM transactions is displayed at step 246 as shown in Fig. 4. Some of the transactions that the user may then select include viewing account history for a specified time period for any number of user accounts, sending and receiving financial messages to and from the financial services provider, and paying bills. At step 248, the user has the option of performing another web-enabled ATM transaction, conducting a traditional ATM transaction or exiting the system.

Implementing the present invention requires that the usual "back" feature common to most Internet web browsers be disabled. Those familiar with Internet browsers know that a user can normally push the "back" button to return to a previous web screen. Thus, without modification, a second user could log in to the web-enabled ATM system, press the "back" button and potentially view a previous user's financial information. This function (sometimes referred to as the "history .back" feature) is modified in the present invention so that each page requests that the browser does not cache it. While the images remain cached, the actual html pages do not. The cache clearing process is designed to occur every time the web- enabled ATM user accesses a new web page. The web-enabled ATM software is also designed to reset the time-out mechanism on the web-enabled ATM every time the user accesses a new web page. While the disclosure of the present invention has repeatedly made reference to a financial services provider, the term is not intended to be limited to just financial institutions such as banks and credit unions. While a financial institution may directly operate the web- enabled ATM system described, it may also decide to hire a service bureau to operate the system. If a service bureau runs a network of web-enabled ATMs on behalf of a group of financial institutions, an additional modification to the web-enabled ATM system becomes necessary. As previously described, a user accessing the Internet capabilities of the system of the present invention is limited to visiting the financial institution's web site. This limitation is necessary to prevent web-enabled ATM users from logging onto the system just to access the Internet. Such activity would tie up the web-enabled ATM and prevent others from using it to perform their own financial transactions. If a service bureau operates the system, the user will still be routed to the web site for the related financial institution upon logging into the web-enabled ATM. However, control of the session is then seamlessly passed to the service bureau and its web site and servers to carry out the desired financial transactions.

In order to allow a user logged onto one web site (domain X; i.e., the financial institution's web site) to call functions in another web site (domain Y; i.e., the service bureau's web site) and still remain logged in to the first domain, a process referred to here as "domain unification" has been developed and implemented into the system of the present invention. The difficulty arises from using Javascript™. As a security feature, Javascript™ will not permit command functions to be performed from a web site domain based on a different web server. The system of the present invention is designed to operate in a frame within a web page on the web browser running on the web-enabled ATM. Thus, commands originating from the financial services provider's domain will not be followed by the financial institution's web-enabled ATM as it operates from the financial institution's domain. In order to solve this problem, the web-enabled ATM is programmed to have a uniform resource locator (URL) corresponding to the financial services provider's domain name. Doing so permits commands issued from a first domain to be processed by a second domain.

Claims

1. A method of conducting online financial transactions at a web-enabled ATM connected to a public communications network, the method comprising: checking user identification for previous permission to access a financial services provider's web site from the web-enabled ATM via the public communications network; establishing a secure, encrypted session between the web-enabled ATM and a financial services provider's web server over the communications network; validating a user login to the financial services provider's web site; presenting a variety of online financial transaction options at the web-enabled ATM over the public communications network; selecting one of the financial transaction options; and processing the selected financial transaction option over the public communications network.

2. The method of claim 1 wherein the user identification comprises a user card number and PIN combination.

3. The method of claim 1 wherein the user login comprises an access ID and a passcode.

4. The method of claim 1, wherein establishing a secure, encrypted session further comprises: querying a financial services provider's web server for a secure connection to the web-enabled ATM; and authenticating the web-enabled ATM.

5. The method of claim 4 further comprising exchanging public keys between the web server and the web-enabled ATM.

6. The method of claim 4, wherein authenticating the web-enabled ATM further comprises: issuing a unique electronic certificate for the web-enabled ATM; installing the certificate on the web-enabled ATM and on the financial services provider's web server; verifying the web-enabled ATM certificate against a list of valid certificates on the financial services provider's web server; and generating a session key for use by the web-enabled ATM and the web server.

7. The method of claim 4, wherein authenticating the web-enabled ATM further comprises: installing a shared secret value on the web-enabled ATM and on the financial services provider's web server; creating a first checksum of the shared secret value using a hashing algorithm at the web-enabled ATM; establishing a secure communication channel with the financial services provider's web server; transmitting the first checksum and related data to the financial services provider's web server; generating a second checksum at the financial services provider's web server based on the related data from the web-enabled ATM and the shared secret value at the financial services provider's web server using the hashing algorithm; and verifying that the first checksum and the second checksum match.

8. The method of claim 1 , wherein validating a user login further comprises: checking the user login against a list of valid customer identities; querying an access ID database; and updating the access ID database to reflect a new link between the access ID and the user identification.

9. The method of claim 1 further comprising disabling the back function of the browser.

10. The method of claim 1, wherein processing the selected financial transaction option further comprises programming the web-enabled ATM to have the same uniform resource locator as the financial services provider's web site.

11. A system for conducting online financial transactions via a public communications network, the system comprising: a web-enabled ATM for initiating financial transaction requests over the public communications network; a communication line between the public communications network and the web- enabled ATM; and a financial services provider's web site connected to the public communications network for processing financial transaction requests originating from the web-enabled ATM.

12. The system of claim 11 further comprising a second communication line between the web-enabled ATM and an ATM processor for sending 911/912 data packets from the web- enabled ATM for processing by the ATM processor.

13. The system of claim 11 wherein the web-enabled ATM further comprises a browser with a disabled back function.

14. The system of claim 11 wherein the web-enabled ATM further comprises a unique identifying electronic certificate used to authenticate the web-enabled ATM against a list of valid certificates on the financial services provider's web site.

15. The system of claim 11 wherein the web-enabled ATM further comprises programming the web-enabled ATM to have the same uniform resource locator as the financial services provider's web site.