WO2001046922A2

WO2001046922A2 - Method and apparatus for securely conducting financial transactions over an insecure network

Info

Publication number: WO2001046922A2
Application number: PCT/US2000/034133
Authority: WO
Inventors: Allen J. Seltzer
Original assignee: Online Resources Corp.
Priority date: 1999-12-20
Filing date: 2000-12-18
Publication date: 2001-06-28
Also published as: AU2908101A; WO2001046922A3

Abstract

The existing infrastructure of automatic teller machines and associated secure networks is used to securely authenticate people for financial transactions conducted at least in part via insecure networks such the as Internet. A person who wishes to transact on the web visits his or her local automatic teller machine and is authenticated based on credentials (e.g., possession of an ATM card and knowledge of a secret personal identification number) commonly used to authenticate certain financial transactions such as funds withdrawal. Based on this authentication, a digital certificate or other credential is issued that can subsequently be used to authenticate other transactions such as for example account debit requests the same person originates via different appliances and/or channels (e.g., over the Internet via conventional web access appliances). The method provides a high degree of security and authentication without requiring substantial changes to existing infrastructure and making use of a large number of already-installed automatic teller machines and associated secure networks.

Description

METHOD AND APPARATUS FOR SECURELY CONDUCTING FINANCIAL TRANSACTIONS OVER AN INSECURE NETWORK

Priority is claimed from provisional application no. 60/172.582 filed 12/20/99.

FIELD OF THE INVENTION

The present invention relates to security in conducting financial transactions, and more particularly, to the use of the existing automatic teller machine (ATM) infrastructure to securely authenticate customers so they can conduct secure transactions using devices other than automatic teller machines.

BACKGROUND AND SUMMARY OF THE INVENTION

Internet commerce is growing rapidly, creating a need for a broader set of payment options. Currently, credit card is the primary payment vehicle. As with standard credit card point of sale (POS), credit card transactions are expensive to the merchant due to security risk, fraud risk, and other factors. In the Internet world, the drawbacks of credit cards are magnified, because neither the card nor the purchaser are physically present at the point of sale.

Efforts have been made to increase the security of Internet credit card transactions, most notably the creation of the SET standard. For various reasons, SET has had little success in the Unites States. The primary drawback to SET is its complexity - requiring significant enhancements to the payments infrastructure. Most Internet merchants accept credit cards today with SSL as the only security feature, which doesn^'t provide a high level of security.

A need exists for a simpler payment mechanism for Internet payments exhibiting the following high-level characteristics: • Secure

• Convenient for the consumer

• Requires only minimal changes to existing infrastructure

• Provides guaranteed funds to the merchant • Low cost

The present invention solves this problem by providing a secure method for performing real-time debits for Internet payment transactions, that uses the existing automatic teller machine infrastructure to authenticate consumers.

In accordance with one aspect of the present invention, the standard ATM machine already being accessed by consumers for a variety of secure financial purposes such as funds withdrawal and deposits will now also be used for Internet consumer authentication. In accordance with this aspect of the invention, the existing network of automatic teller machines (ATMs) can be used to authenticate consumers and issue security credentials. A consumer may use the resulting security credential (e.g.. a digital certificate) to conduct transactions through other means (e.g., over the Internet).

Automatic teller machines already provide the highest security level of financial authentication in common use for small to medium sized personal financial transactions. Furthermore, use of an ATM machine guarantees the consumer has a valid ATM card and linked financial account from which funds can be debited in real time. Using an automatic teller machine for issuing security credentials to consumers provides a high degree of security without requiring an entirely new secure infrastructure to be put in place. The ATM machine also connotes security to the consumer, important for establishing a level of comfort for transacting over the Internet. There is not widespread consumer comfort today with entering credit card numbers on the Internet.

Briefly, someone who wants to transact on the web visits his or her local ATM machine once in order to register. The person authenticates himself or herself at the ATM machine by providing already-secure authentication credentials that banks and other financial institutions now rely on every day ~ i.e., presentation of an ATM card and input of a predetermined personal identification number. The person's request for authorization to transact on the web is authenticated by the ATM machine sending a conventional balance inquiry message (or other message that requires authentication) to the person's financial institution operating on an account which can be debited for Internet transactions. Once the card and PIN are authenticated and the person's account has been verified to be valid, a corresponding digital certificate is issued by an appropriate certifying authority. This digital certificate will be used to authenticate transaction authorization requests (e.g., associated digital signatures) originated by the same person from a different appliance (e.g., a home or office PC web browser) — even via an insecure network such as the Internet.

The present invention creates a security credential based on secure consumer authentication at an ATM machine, and allows this security credential to be used to authenticate the same consumer's request, provided over an insecure network, to charge the consumer's account. Information the consumer provides over the insecure network is matched with information the consumer provided at the ATM machine, to determine with high reliability that the person who wishes to engage in a transaction over an insecure network such as the Internet is the same person who was securely authenticated with an ATM card and associated user PIN at the sign-up ATM machine. The present invention offers the significant advantage of using existing secure ATM machine infrastructure to authenticate consumers one-time and certify them to later perform secure transactions from different appliances (e.g.. insecure devices such as personal computers) using different networking channels (e.g., an insecure network such as the Internet). The present invention keeps costs low, provides a real-time authorization mechanism, offers the certainty of guaranteed fund transfer, and minimizes intrusiveness to the consumer by creating a process which is familiar, convenient, portable (not tied to a single client machine), and workable with minimal client- side software beyond a standard browser. The present invention also provides a high degree of security - both at sign-up and for transacting. It allows the issuing financial institution to authenticate and register consumers for Internet transactions (such as shopping) using infrastructure which is already in place and a method which is highly familiar and comfortable to the consumer. Initial authentication is based on what you HAVE (the ATM card) and what you KNOW (the PIN).

Furthermore, to speed implementation and acceptance of the method, the present invention minimizes changes required of industry groups having many members, including: ■ Shoppers

^• Merchants

^• Issuing processors

^• Issuing financial institutions

The present invention also localizes changes to the minimal number of participants where possible, that is: ^• Security agent

^• Acquiring processors

^■ Sign-up financial institutions (those who offer the ability to sign up for a digital certificate at their ATM machine(s)). The present invention also provides a significant advantage in that it uses existing standards where possible, for example: ISO 8583

Existing clearance / settlement Client browser Web server Standard di ^λegi^αtal certificates

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages provided by the present invention will be better and more completely understood by referring to the following detailed description of preferred embodiments in conjunction with the drawings of which:

Figure 1 shows an overall diagram of participants involved in a secure Internet transaction using ATM consumer authentication;

Figures 2-8 show an example sign-up process using automatic teller machines;

Figures 9-11 show an example order digital certificate process;

Figures 12-14 show an example pick-up digital certificate process; and

Figures 15-23 show an example shopping transaction. DETAILED DESCRIPTION OF PRESENTLY PREFERRED EXAMPLE EMBODIMENTS

Figure 1 shows various participants involved in a secure shopping transaction, including the following: • a shopper 10;

• a sponsoring financial institution (Fl) 12 providing sign up services at the institution's automatic teller machines 14;

• an acquiring processor 16, who may operate or cooperate with one or more merchant web sites 18; • a certifying authority 20 who may operate one or more pick up web sites 22;

• a conventional transaction message switch 24 such as an automatic teller machine (ATM) regional switch;

• a security agent 26 who operates and maintains a security database 28: and

• an issuing financial institution 30, where shopper 10 maintains an account. Although not shown in Figure 1 , shopper 10 may access merchant web site

18 over the Internet via a standard conventional TCP/IP connection using a conventional personal computer or other web-access device equipped with a conventional web browser or the like. Shopper 10 may similarly access the pickup web site 22 operated by certifying authority 20 in this same manner.

Phase 1 - Signup

Figures 2-8 show an example signup process in accordance with the preferred embodiment of this invention. Initially, issuing financial institution 30 advertises to his customers (shoppers 10) that the new Internet payment method is available. Issuing financial institution 30 may advertise to consumers through conventional means such as. for example, radio, television, direct mail, telemarketing, statement stuffers or the like. While in many cases it will be the issuing financial institution 30 that initiates the process, there may be other instances where the issuing financial institution is not a willing participant. For example, a party other than the issuing financial institution 30 (e.g., a popular web site) could promote the service and attract consumers without issuing financial institution's involvement. As explained below, since one form of authentication transaction provided in accordance with an aspect of the invention is indistinguishable from a standard point of sale or other transaction presented to the issuer for approval, the issuing financial institution can process the authentication transaction without necessarily knowing that the transaction is being used for some purpose beyond a completely conventional point-of-sale or other financial network transaction.

Irrespective of who distributes the advertisement or other information to the consumer, this advertisement or other information encourages prospective shoppers 10 to sign up at any ATM machine 14 which bears a particular logo or is part of or cooperates with a certain network. ATM machine 14 connotes security in the mind of shopper 10. and is in fact a highly secure environment (i.e., secure enough to be relied on by financial institution 12 for distributing thousands of dollars in currency every day). Additionally, ATM machine 14 is highly familiar to the average shopper 10. Shopper 10 has used ATM machine 14 many times in most cases to withdraw cash or query account balances or to make deposits. The present invention provides, in one of its aspects, a signup process involving an ATM machine 14 providing the highest level of financial authentication in common, readily available use for small to medium sized personal financial transactions. Also, this method guarantees that shopper 10 has a valid ATM card used to access ATM machine 14 and a linked bank account at financial institution 30, both of which may be used to later shop. If an interested shopper 10 doesn't have an ATM card, he or she can obtain one using existing procedures. To begin the signup process, shopper 10 goes to a signup ATM machine 14, inserts his or her ATM card 14 to access the ATM machine's main menu, and selects an "Internet shopping signup" option from the menu of ATM machine 14. This option is not currently available on ATM machines 14 in wide distribution, but can be easily added through software changes by sponsoring financial institution 12. Most commonly-available ATM machines 14 have updatable (often downloadable) software that allows ATM machine programming to be changed to provide new functionality.

In this preferred example embodiment (see Figure 2), ATM machine 14 prompts shopper 10 to enter the following information: • personal identification number (PIN) the shopper was issued when he/she received an ATM card; and • other identification information the consumer knows but which others typically don't know (e.g., mother's maiden name ("MMN") and/or social security number "(SSN")). Input of this additional security information may be via the conventional

ATM machine 14's keypad or through other means (e.g., a full keyboard, selection menus displayed on the ATM machine, or via other input devices such as microphones or biometric-characteristic sensors in future ATM machine designs). In response to this data input. ATM machine 14 generates a "request Internet shopping certificate" transaction message using the ISO-8583 format (or any other format commonly used in ATM networks) and sends this message to security agent 26 (see Figure 3). This new "request Internet shopping certificate" transaction message may be identical to the current conventional "balance inquiry checking" transaction under ISO-8583 except that it has a new transaction code to identify it as a shopping certificate request message, and the shopper's further identification information (such as mother's maiden name and social security number) are placed in private fields.

The security agent 26 may be, in concept, very much like a so-called " Atalla" box in common use today, and may be part of ATM switch 24 if desired. In the preferred embodiment, the security agent operates as an agent of issuing financial institution 30. In alternate embodiments, the security agent functions may be performed by ATM switch 24 or even by an external third party. From a business perspective, it is desirable for the security agent to act on behalf of the issuing financial institution, so the issuer is authenticating the consumer and will therefore guarantee the debit. If the functions of security agent 26 are not performed on the issuer's behalf (e.g., as opposed to being sub-contracted by the issuer), then there may be an issue of who is ultimately liable for the transaction. Liability considerations may, under certain circumstances, encourage security agent 26 to act as agent of an issuing financial institution 30, but other embodiments and arrangements are possible and could be desirable in certain contexts.

Placing the security agent 26 "in front" of ATM switch 24 as shown in Figure 3 is desirable to minimize changes to the overall infrastructure. By being positioned in the transaction flow in front of ATM switch 24, security agent 26 can process, re-format, and/or translate any new messages required by the present invention, thus ensuring that ATM switch 24 and issuer 30 need only process conventional messages, and thus can operate purely in the conventional mode during both signup and transacting. However, in certain contexts where some changes to the financial services network can be tolerated (e.g., where ATM switch 24 and/or issuing financial institution 30 is willing to reprogram its computers to incorporate new features to support further authentication), the goal of maintaining complete compatibility with existing infrastructure can be relaxed. It should therefore be recognized that these nuances are implementation-specific issues and that the invention can provide a wide variety of different configurations to suit the needs of the participants.

Security agent 26 may access a private, secure database 28 to locate an already existing record associated with the PAN (primary account number) contained within the "request Internet shopping certificate" message. If such a record is found, its contents may be cleared, causing a new signup to occur (that is, a new shopping certificate will be issued to that shopper). This check is used to prevent duplicate, differing signups. Alternatively, security agent 26 may issue a warning back to shopper 10 via ATM switch 24 and signup ATM 14 in real time. If no matching record already exists, security agent 26 creates a new record which will be later written to security database 28. In either case, the record is initialized to contain:

• the user's primary account number (PAN) and other data from the magnetic stripe of the ATM card, (card data)

• the shopper's encrypted PIN,

• the user-entered private data (i.e.. mother's maiden name, social security number). Having saved the information, security agent 26 strips off the private fields from the message, changes the transaction code to "balance inquiry checking" and routes the message (as a purely conventional message) to ATM switch 24 (see Figure 4). In one example embodiment, the switch 24 processes the transaction in purely conventional fashion by routing it to issuer 30, and issuing financial institution 30 receives and processes the standard "balance inquiry checking" transaction message including the user's PIN in the conventional way. Figure 5 shows issuer 30 performing this balance inquiry in a conventional fashion, authenticating shopper's 10 PIN as usual, and returning a "success" response message back through the switch 24 to security agent 26. In one example arrangement, issuer 30 and switch 24 do not need to make any changes or perform any new steps to support the sign-up method. This is useful from a practical perspective, since there are approximately 22,000 issuers in the U.S. and if the method required them to change their computer systems, adoption might be expensive and slow. On the other hand, if one or more issuers were willing to make changes to their system to support a new authentication type message, then complete compatibility with existing infrastructure need not be maintained.

Upon receiving the successful balance inquiry response message from issuer 30, security agent 26 matches up the response with its original request and determines that the original transaction was "request certificate." By sending the balance inquiry message to the issuer 30 and receiving a positive response, security agent 26 has verified that issuer 30 has successfully authenticated shopper 10's existing credential (ATM card and PIN) and that shopper 10 has a valid account at that financial institution that can be debited in real time via an ATM debit message. In another embodiment, switch 24 may receive the response message directly from sponsoring financial institution 12 and route it through security agent 26, on its way to issuer 30. Over time, if many financial institutions choose to perform the ATM signup function rather than just a few, that routing may be advantageous. As shown in Figure 6, in response to receipt of the return message from issuer 30, security agent 26 retrieves the shopper's record it previously initialized. Security agent 26 then generates a random EC-PAN and copies it into the record and into a private field of the response message. Security agent 26 also copies time stamp and other data into the record and writes the record into its secure database 28. In this example, the EC-PAN (electronic commerce primary account number) is a new value generated by security agent 26. The EC-PAN may be, for example, a 19-digit unique value that is randomly generated. Security agent 26 may choose to set the ISO digits to a fixed value as opposed to randomly so later transactions will route correctly with minimal changes. The EC-PAN value will be used, in the preferred embodiment, as a pseudo- account number compatible with ATM switch 24 and used for routing electronic commerce transactions that are communicated in part over insecure networks such as the Internet. In this example, the EC-PAN information is not considered secure information and will be visible on the Internet, without compromising overall security. The EC-PAN' s purpose is to uniquely identify each Internet shopping registrant, to allow the participants to route messages appropriately, and to later allow security agent 26 to retrieve the original conventional card data and security credential from secure database 28. As is explained below, security agent 26 may, through its secure database 28, associate the EC-PAN with an actual PAN indicating the shopper 10's account with issuer 30 before presenting debit messages to the issuer — further minimizing changes to the issuer's system.

During sign-up, security agent 26 may also choose to store the encrypted PIN block from the "request certificate" message into secure database 28, thus allowing security agent 26 to later retrieve the PIN block and reconstruct a complete PINNED debit message during shopping. In such a scenario, the issuer could process the debit transaction like any other conventional POS debit. Although this particular technique might be considered somewhat less secure (i.e., because the user's PIN is being stored), it offers the advantage that it could obviate all changes to the processing systems of issuer 30 and switch 24.

Security agent 26 forwards the response message back to the sign-up sponsoring financial institution 12 to provide feedback to the user at sign-up ATM machine 14. The shopper 10 may be charged a fee for this registration service. For example, the switch 24 may interchange funds from the issuer 30 to the signup financial institution 12 to compensate institution 12 for use of his ATM .

Figure 7 shows security agent 26 responding by providing a normal ISO response message to sponsoring financial institution 12. This response is conventional in format except that the EC-PAN data is stored in a private field. Upon receiving this response message, ATM machine 14 (see Figure 8) prints a paper receipt and informs shopper 10 to complete his sign-up by using his computer to visit web site 22 where he can pick up his digital certificate C. In one particular example, ATM machine 14 displays but does not print the EC-PAN (or portions of it) and instructs the shopper 10 to remember or write this information down since he or she will need it at web site 22 to complete the signup process. ATM machine 14 may also instruct shopper 10 to retain his or her paper receipt, which will also be needed for the certificate C pick-up.

Phase 2 - Ordering Certificate -- Behind the Scenes

Figures 9-1 1 show a "behind the scenes" process by which security agent 26 orders digital certificates C from certifying authority 20. Periodically, security agent 26 scans private database 28 looking for new certificate requests ~ or this can be done in real time if desired. Security agent 26 formats each record into an agreed upon format, and sends it via a secure communications channel to certifying authority 20. Upon receiving the request, certifying authority 20 issues a digital certificate C and returns it to the security agent 26. In one particular example, certifying authority can also publish the digital certificate C to a pick-up web site 22 which allows shopper 10 to retrieve the digital certificate and download it to his/her Internet appliance.

In more detail, security agent 26 sends the certifying authority 20 a request based upon shopper 10's record within security database 28. This request may include:

• ATM card number (PAN),

• additional shopper identification information (e.g., social security number and mother's maiden name), • the EC-PAN, and

• additional characters/digits from the ATM machine signup receipt, if any. These pieces of information will be later used during the pick-up step to authenticate shopper 10. i.e., to determine that the person attempting to pick up certificate C is the same person who was reliably authenticated with a particular ATM card and associated user PIN at sign-up ATM 14. The amount of authentication data and its nature and content may be adjusted to balance security with convenience.

Figure 9 shows security agent 26 sending a private request for a certificate C to certifying authority 20. The certifying authority 20, in response, generates a digital certificate C (or, in another embodiment, simply a PK pair) in a conventional manner. The certifying authority 20 may embed the EC-PAN into the digital certificate C. In one example embodiment, the EC-PAN is not a secure piece of information — anyone having access to the certificate C can see the EC- PAN without compromising security. The certifying authority 20 provides the digital certificate C to security agent 26 (see Figure 10). Security agent 26 may store the issued digital certificate C in security database 28, and may also publish digital certificate C in a public or private directory for use in authenticating digital signatures S provided by shopper 10 during web shopping experiences. The certifying authority 20 provides the digital certificate to a pick-up web site 22 (see Figure 11) to enable shopper 10 to download the certificate onto his/her web appliance for use in shopping the web (or the security agent 26 may perform this function).

Phase 3 - Pick-Up Digital Certificate In one example embodiment, shopper 10 may use conventional web access

(via a home or office PC or other web access appliance equipped with an Internet browser for example) to visit pick-up web site 22 and download digital certificate C (see Figure 12). In one example, shopper 10 knows the URL to point his or her browser to because of the information he or she received from sign-up ATM 14. Shopper 10 inputs various identification information to pick-up web site 22 in order to request download of digital certificate C, such information including:

• ATM card number from shopper's 10 ATM card,

• other identifying information (e.g., social security number and/or mother's maiden name) from memory;

• EC-PAN (which was displayed on ATM machine 14);

• certain characters/digits from the ATM receipt such as time stamp Shopper 10 was previously authenticated via the ATM card and PIN by issuing financial institution 30 while the shopper was at ATM machine 14. The object is now to authenticate that the person attempting to pick up certificate C on web site 22 is the same person who was successfully authenticated at the signup ATM machine 14. It is for this authentication reason that shopper 10 is asked to supply this various identification information. The EC-PAN can also be used for additional authentication between ATM machine 14 and the pick-up web site 22 if desired. For additional security, the certificate C may be available from the pickup web site 22 for only a limited amount of time after the ATM sign-up process was performed at ATM machine 14; or in still other embodiments, it could be provided over a secure channel (e.g., by mailing a diskette or other magnetic storage medium to shopper 10 at the shopper's address of record). Referring to Figure 13, the web site 22 (which may be operated by security agent 26 or certifying authority 20 or issuer 30) checks that all data entered by the shopper on the web site is identical to that entered at the ATM machine 14 (i.e.. by comparing the data inputted by shopper 10 to the data provided by security agent 26). Upon being satisfied that the web shopper now at pick-up web site 22 is the same person who was authenticated at sign-up ATM machine 14, the pick-up web site 22 writes digital certificate C to the shopper 10's web access device. Current browsers support this functionality of receiving a downloaded digital certificate C. At this point, sign-up is complete and the shopper 10 is ready to shop the web. If desired, shopper 10 may protect his or her digital certificate C with a local password to prevent others from "forging" his digital signature without the shopper's authorization (see Figure 14).

Phase 4 - Shopping the Web

To shop the web, shopper 10 visits a participating merchant web site 18 and selects goods to purchase in the conventional manner (see Figure 15). When shopper 10 is ready to pay. the payment software of merchant web site 18 prompts shopper 10 to select his preferred payment method and the shopper selects "online debit" (see Figure 16). Referring to Figure 17, the merchant web site 18 then requests shopper 10's digital certificate C. Shopper 10's browser receives the certificate request and prompts the shopper to enter his or her local password used to prevent unauthorized release of the certificate C. Once the user enters the password to release the certificate C, the browser sends the certificate C to the merchant web site 18 (see Figure 18).

Merchant web site 18 may validate the received certificate C to ensure that it is signed by an authorized certifying authority 20 and has not been tampered with (see Figure 19) before proceeding. The merchant web site 18 may also extract the EC-PAN information that certifying authority 20 embedded into the digital certificate C (see Figure 19). Merchant 18 might also look up the EC-PAN in a table of "hot cards" or use other conventional techniques to determine whether to continue to process the sale. In the preferred embodiment, merchant 18 requests shopper 10 to provide a digitally signed message containing certain information describing the transaction. In more detail, merchant web site 18 may send a message to shopper 10's browser including instructions for the browser to digitally sign a message containing the following fields:

• EC-PAN.

• merchant identifier,

• transaction amount,

• transaction identifier, • time stamp.

This request is shown in Figure 20. In response to this request, shopper 10's browser may provide a digitally signed message by using conventional Public Key cryptography already provided within conventional Internet browsers. Upon receipt of this digitally signed message (see Figure 21), merchant web site 18 may use the previously provided digital certificate C to validate the digital signature. In another embodiment, the merchant web site obtains a copy of the digital certificate C from secure database 28 in addition to or instead of from shopper 10's browser. In yet another embodiment, the merchant web site obtains a copy of the digital certificate C from a publicly accessible database of digital certificates. In yet another embodiment, the merchant web site 18 doesn't validate the certificate or digital signature information at all, but leaves that responsibility entirely to an entity further down the chain, such as security agent 26, ATM switch 24, or issuer 30. In the preferred embodiment, however, merchant 30 validates the shopper's certificate and security agent 26 validates the digital signature using a private copy of the certificate stored in security database 28, as will be described more completely in the following paragraph(s).

Once the merchant web site 18 validates the digital certiiicate, merchant web site 18 has some degree of confidence that the purchasing transaction (including the EC-PAN) came from a registered shopper. Merchant web site 18 then, via acquiring processor 16, formats an ISO point-of-sale (POS) debit message and sends it to security agent 26 for authorization. This process is shown in Figure 21.

In more detail, the ISO POS message may be identical to a standard ATM POS message except:

• the EC-PAN is extracted from shopper 10's digital certificate and used in place of the PAN;

• the merchant identifier is placed in an agreed-upon field;

• the transaction ID is inserted into the message as a private field; • the shopper's digital signature is also placed in a private field.

Acquiring processor 16 then presents this message to security agent 26.

Security agent 26 extracts the EC-PAN information from the message and accesses^'security database 28 to retrieve all the data associated with the EC-PAN, in particular the digital certificate C, the original ATM card data, and the encrypted PIN block. Security agent 26 may hold the entire record in volatile

RAM while processing the transaction. In another embodiment, security database 28 contains only the shopper's public key-half, rather than his entire certificate. The digital certificate C can be accessed by security agent 26 in many ways including, for example, local storage: accessing from a directory maintained by certifying authority 20; accessing from a public directory; having it passed from the acquiring processor 16 in the ISO message; or other ways. Storing the certificates C locally in security database 28 simplifies the system and in particular, minimizes the need for the certificate to travel through the entire transaction path. It also allows security agent 26 to maintain tight control over all the shopper's security data, keeping it all in one place for control and security purposes. This approach also minimizes changes to the existing payments infrastructure

Referring to Figure 22. security agent 26 validates the time stamp from the ISO POS message, uses digital certificate C to validate the digital signature of shopper 10 from the ISO POS message, replaces the EC-PAN in the message with the stored PAN (which identifies an actual bank account of shopper 10 within issuer 30), and strips off the digital signature and other private fields ~ thereby forming a standard and conventional ATM POS debit message. In the preferred embodiment, security agent 26 also inserts the encrypted PIN block of shopper 10 into the debit message. There are very stringent rules and policies for encrypting, translating, and handling PIN blocks that are well known in the art. The current invention uses and adheres to these rules and policies to the extent practical.

Referring to Figure 22, security agent 26 then routes the POS debit message (which may be PINNED or PINLESS) through ATM switch 24 and on to issuer 30 for authorization in the conventional fashion. Issuer 30 authorizes the transaction, debits the account of shopper 10 by the appropriate amount, and returns the response to ATM switch 24 in the conventional fashion as shown in Figure 23. ATM switch 24 then returns the transaction to security agent 26 in the conventional fashion. Again, it is worthy to note that the example preferred embodiment provides all the benefits of the current invention, while requiring NO changes of the ATM switch 24 and issuer 30 — but that other arrangements are also possible depending on the particular context and parties involved.

Security agent 26 receives this response, replaces the PAN information with the EC-PAN information, and routes the response back to acquiring processor 16 (see Figure 23). The shopping transaction may now be completed, since the merchant web site 18 has real time acknowledgment that shopper 10 had sufficient funds in his or her bank account and that funds for the purchase have now been debited and applied in a conventional way to the account of the merchant. See, for example, commonly-assigned U.S. Patent No. 5,220,501 entitled "Method And System For Remote Delivery Of Retail Banking Services", incorporated herein by reference. The merchant is guaranteed to receive the funds in the next settlement cycle, thus lowering his risk dramatically, compared to today's payment methods. Merchant web site 18 may respond back to shopper 10 indicating that the transaction has been completed and informing shopper 10 when the ordered goods will be shipped. Shopper 10 will see the transaction with appropriate identifying information on his or her next statement from issuer 30 in the conventional way. The issuer may choose to identify the transaction in a distinctive way on the shopper- s statement.

While the preferred embodiment involves debiting shopper 10's bank account within financial institution 30 via an ATM network debit request message, another variation might be to use a similar technique with a credit card or offline debit card, or another financial transaction. While such debit transactions involving credit or debit cards may not require as high a degree of security as ones involving an ATM debit, they nevertheless can benefit from the additional user authentication features using a secure ATM machine provided in accordance with the present invention.

While the example illustrates using the invented authentication and payment methodology to complete a shopping purchase on the web, it is well understood that the same method can be used for other online transactions. Another example would be so-called person-to-person payments, where the object is to transfer money from one consumer to another. In this case, merchant web site 18 could be a person-to-person payments web site, the guaranteed debit is performed as described above, and rather than shipping out an ordered shopping item to the consumer, the web site is provided with means for crediting the funds to any account of the consumer's choosing. As another example, the credit side of the transaction could credit money onto a smart card or other form of electronic money. Another application would be to pay an online gambling debt or to pay for items "purchased" at auction. While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims.

09

Claims

WE CLAIM:

L A process for securely conducting a financial transaction comprising: (a) authenticating a person at least in part using an automatic teller machine; (b) receiving a financial account debit request initiated at least in part from a user appliance different from said automatic teller machine; and (c) authorizing said financial account debit request based at least in part on said authentication performed by step (a).

2. A process for facilitating purchase of goods or services via the Internet, comprising: (a) accepting at least one shopper credential through an automatic teller machine infrastructure; (b) using the automatic teller machine infrastructure to authenticate the shopper credential; (c) relying on said authenticated shopper credential to issue, to said shopper, at least one further credential; and (d) using said further credential to authorize at least one purchasing transaction over the Internet.

3. A process for securely conducting an online transaction comprising: (a) using existing ATM network-compatible infrastructure to authenticate a participant; (b) using said authentication to create a credential associated with the participant; and (c) empowering a security agent to use the credential to authenticate at least one transaction on the participant's behalf.

4. The method of claim 3 wherein steps (a) and (c) are performed in different channels.

5. The method of claim 3 wherein step (a) is performed using an automatic teller machine.

6. The method of claim 3 wherein step (a) is performed using a point of sale terminal.

7. The method of claim 3 wherein step (a) is performed at a kiosk.

8. The method of claim 3 wherein step (b) comprises associating a digital certificate with the participant.

9. The method of claim 3 wherein step (b) comprises creating or assigning a password.

10. The method of claim 3 wherein step (b) comprises creating or programming a smart card.

11. The method of claim 3 wherein step (b) comprises associating biometric measurement data with the participant.

12. The method of claim 3 wherein step (c) includes making the credential available to the security agent. -

13. The method of claim 3 wherein step (c) includes making the credential available to a network switch.

14. The method of claim 3 wherein step (c) includes making the credential available to a merchant.

15. The method of claim 3 wherein step (c) includes making the credential available to a service provider.

16. The method of claim 3 wherein step (c) includes performing a financial transaction.

17. The method of claim 3 wherein step (c) includes performing a debit or credit transaction.

18. The method of claim 3 wherein step (c) includes performing a shopping purchase.

19. The method of claim 3 wherein step (c) includes performing a person-to-person payment transaction.

20. The method of claim 3 wherein step (c) includes performing a gambling transaction.

21. The method of claim 3 wherein step (c) includes performing an auction payoff.

22. The method of claim 3 wherein step (c) includes replenishing funds in a stored value card or account.

23. The method of claim 3 wherein step (c) includes authenticating for computer network/access.

24. The method of claim 3 wherein step (c) includes authenticating for access to particular information or electronic services.

25. The method of claim 3 wherein the infrastructure includes a conventional financial network switch and a conventional issuing financial institution, and step (a) requires no alteration to said switch or to said institution.

26. The method of claim 3 wherein the infrastructure includes an automatic teller machine accepting a predetermined authentication credential for authenticating automatic teller machine transactions such as cash withdrawal, the automatic teller machine being connected to an electronic financial transactions network, step (a) includes authenticating the participant based at least in part on said predetermined authentication credential, and step (c) includes performing at least a part of said transaction over said electronic financial transactions network.

27. A transaction authorizing system for use with a financial transactions infrastructure that authenticates participants for a predetermined range of transactions, the system including at least one computer that interacts with the financial transactions infrastructure, said computer creating a credential associated with the participant based at least in part on the participant authentication performed by said financial transactions infrastructure and making said credential available for use in authorizing other than said predetermined range of transactions.

28. A system for securely conducting a financial transaction comprising: means for using existing infrastructure to authenticate a participant; means for using said authentication to create a credential associated with the participant; and means for empowering a security agent to use the credential to authenticate at least one transaction on the participant's behalf.

29. A system for securely conducting a financial transaction comprising: automatic teller machine infrastructure used to authenticate a participant; a first computer coupled to the infrastructure, the first computer using said participant authentication performed by the infrastructure to create a credential associated with the participant; and a further, transaction computer operatively coupled to the first computer, the transaction computer using the credential to authenticate at least one transaction on the participant's behalf.

30. The method of claim 17 wherein said credit or debit financial transaction is performed in real-time.

31. The method of claim 17 wherein said credit or debit financial transaction is performed through an inter-bank financial network.

32. The method of claim 17 wherein said credit or debit financial transaction is performed through an ATM-compatible network.

33. The method of claim 31 wherein said debit financial transaction compensates an online goods or services or information provider by shifting financial liability in real-time to the issuing financial institution.

34. The method of claim 32 wherein said online goods or services or information provider conducts business on the internet or world-wide web.

35. The method of claim 3 wherein said created credential is managed within a digital wallet.

36. The method of claim 3 wherein said created credential is managed by software resident on the participant's computer or internet appliance.