Abstract:
A transaction authorization method and system. The system includes a host coupled to a plurality of transaction request channels (telephone, PC, and the like) for receiving and authorizing transaction requests for a specific self-service terminal. The system also includes a self-service terminal coupled to the host for receiving a transaction message therefrom. The transaction message includes a transaction identifier and a customer identifier, so that the self-service terminal is operable to provide a customer with a transaction amount from the transaction identifier in response to the customer entering details matching the contents of the customer identifier.

Description:
FIELD OF INVENTION 
       [0001]    The present invention relates to transaction authorization. The invention is related, but in no way limited, to transaction authorization at a self-service terminal (SST). 
       BACKGROUND 
       [0002]    SSTs are public access devices that are suitable for allowing a customer to conduct a transaction or to access information in an unassisted manner and/or in an unattended environment. 
         [0003]    Common examples of SSTs include automated teller machines (ATMs), information kiosks, financial services centers, bill payment kiosks, lottery kiosks, postal services machines, check-in and check-out terminals such as those used in the hotel, car rental, and airline industries, retail self-checkout terminals, vending machines, and the like. 
         [0004]    A particularly important example of an SST is an automated teller machine (ATM). ATMs allow customers to perform financial transactions, such as cash withdrawal transactions. Such cash withdrawal transactions typically require the customer to insert a card and enter an associated personal identification number (PIN) to authenticate himself/herself. The PIN is authenticated at a host, which also confirms whether the customer has sufficient funds to cover the cash withdrawal request. 
       SUMMARY OF THE INVENTION 
       [0005]    Accordingly, the invention generally provides methods, systems, apparatus, and software for transaction authorization at a self-service terminal to enable a customer to obtain authorization for a transaction prior to executing the transaction at the self-service terminal. 
         [0006]    In addition to Summary of Invention provided above and the subject matter disclosed below in the Detailed Description, the following paragraphs of this section are intended to provide further basis for alternative claim language for possible use during prosecution of this application, if required. If this application is granted, some aspects of the invention may relate to claims added during prosecution of this application, other aspects may relate to claims deleted during prosecution, other aspects may relate to subject matter never claimed. Furthermore, the various aspects detailed hereinafter are independent of each other, except where stated otherwise. Any claim corresponding to one aspect should not be construed as incorporating any element or feature of the other aspects unless explicitly stated in that claim. 
         [0007]    According to a first aspect there may be provided a transaction authorization method implemented by a self-service terminal, the method comprising: receiving a transaction message from a host, the transaction message including a transaction identification field, a customer verification field, and a transaction amount field; storing the received transaction message as an entry in a pending transaction list; receiving a transaction code and a customer code from a customer; matching the received transaction code and the received customer code with an entry in the pending transaction list; and providing the customer with the amount from the transaction amount field of the matched entry from the pending transaction list. 
         [0008]    The step of storing the received transaction message as an entry in a pending transaction list may include the further step of storing the received transaction for a predefined time and then deleting that entry if not executed prior to expiry of the predefined time. For increased security, the predefined time may be relatively short, for example, one hour, two hours, or the like. When the self-service terminal deletes that entry because of expiry of the predefined time, the self-service terminal may send a message to the host indicating that the transaction was not executed. 
         [0009]    The step of providing the customer with the amount from the transaction amount field may include dispensing the amount to the customer in physical cash, in electronic cash, in valuable media to the value of the transaction amount (for example, a cheque for that amount), or the like. 
         [0010]    The method may comprise the further step of transmitting a transaction fulfilled message to the host subsequent to the step of providing the customer with the amount from the transaction amount field. 
         [0011]    According to a second aspect there may be provided a computer program for a self-service terminal, the computer program being operable, when executed on a self-service terminal, to implement the method of the first aspect. 
         [0012]    The computer program may be embodied on a tangible medium, executed in memory, propagated as a signal, or the like. 
         [0013]    According to a third aspect there may be provided a transaction authorization method comprising: receiving a transaction request from a customer entered at a device other than a self-service terminal, the request including a transaction amount and a self-service terminal identification; verifying that the transaction request fulfils an acceptance criterion; and transmitting a transaction message to a self-service terminal corresponding to the self-service terminal identification so that the self-service terminal is operable to execute a transaction using only the transaction message and information entered by the customer. 
         [0014]    The method may comprise the further steps of: storing the transaction message in a pending transaction store; and deleting the transaction message from the pending transaction store in response to receipt of a transaction fulfilled message from the self-service terminal. 
         [0015]    The step of receiving a transaction request from a customer may be implemented via any convenient channel. For example, the transaction request may be received via the Internet, an interactive voice response (IVR) system, a text messaging system (such as SMS), electronic mail, or the like. 
         [0016]    The acceptance criterion may include any convenient authorization mechanism. For example, the acceptance criterion may include: comparing a password received from the customer with a stored password for that customer; comparing a PIN received from the customer with a stored PIN for that customer; comparing a telephone number (landline or cellular) to a stored telephone number for that customer; comparing answers to one or more questions supplied by the customer to stored answers previously supplied by that customer. 
         [0017]    The host may be used to authenticate customers from multiple channels; for example, Internet, telephone, text messaging, teller in a branch, or the like. 
         [0018]    The acceptance criterion may also include verifying account details; for example, verifying that the transaction amount is less than an amount available for withdrawal from an account of the customer. 
         [0019]    The method may comprise the further step of debiting the customer&#39;s account by an amount equal to the transaction amount. The step of debiting the customer&#39;s account may be performed when the transaction request is received, when the transaction fulfilled message is received, or at any other convenient time. 
         [0020]    According to a fourth aspect there may be provided a computer program for a transaction authorization host, the computer program being operable, when executed on the transaction authorization host, to implement the method of the third aspect. 
         [0021]    According to a fifth aspect there may be provided a system for authenticating transactions at a self-service terminal, the system comprising: a host coupled to a plurality of transaction request channels for receiving and authorizing transaction requests for a specific self-service terminal; a self-service terminal coupled to the host for receiving a transaction message therefrom, the transaction message including a transaction identifier and a customer identifier, so that the self-service terminal is operable to provide a customer with a transaction amount from the transaction identifier in response to the customer entering details matching the contents of the customer identifier. 
         [0022]    The transaction identifier may comprise a transaction identifier field (which may include a code to identify a specific transaction) and a transaction amount field. 
         [0023]    The customer identifier may comprise a customer identifier field, which may include a code to identify a specific customer. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0024]    These and other aspects will be apparent from the following specific description, given by way of example, with reference to the accompanying drawings, in which: 
           [0025]      FIG. 1  is a block diagram of a transaction authorization system according to one embodiment of the present invention; 
           [0026]      FIG. 2  is a flowchart describing the steps involved in requesting authorization of a transaction using the system of  FIG. 1 ; 
           [0027]      FIG. 3  is a pictorial diagram illustrating a Web page presented to a customer to enable the customer to request authorization of a transaction using the system of  FIG. 1 ; 
           [0028]      FIG. 4 , which is a flowchart illustrating the steps performed by a part of the transaction authorization system (a transaction host) in response to a customer request for authorization of a transaction; and 
           [0029]      FIG. 5  is a flowchart describing the steps performed by another part of the transaction authorization system (a self-service terminal) to fulfill an authorized transaction. 
       
    
    
     DETAILED DESCRIPTION 
       [0030]    Reference will now be made to  FIG. 1 , which is a block diagram of a transaction authorization system  10  according to one embodiment of the present invention. The system  10  comprises a plurality of ATMs  12  (for clarity only two of which,  12   a  and  12   b , are shown in  FIG. 1 ) coupled to a transaction authorization host  14  by a private network  16 . The system  10  also comprises a branch  18 , an interactive voice response (IVR) system  20 , and a Web server  22 , all of which are coupled to the private network  16 . The branch  18  may include a plurality of teller stations, each coupled to the host  14  by the private network  16 . The host  14  includes a pending transaction store  26 , and the ATMs  12  each contain a pending transaction list  28 , as will be described in more detail to below. 
         [0031]    The Web server  22  is also coupled to the Internet  30  to allow customers to access banking information, such as information about their current balance, recent transactions, and the like, via a personal computer  32  (again, for clarity, only two PCs  32  are shown). 
         [0032]    As illustrated in  FIG. 1 , a customer can access account information using a secure channel, such as a PC  32 , a telephone (via the IVR system  20 ), or at the branch  18 . The customer can use any of these secure channels to request authorization of a transaction. In this example, the customer uses a PC  32  to make the authorization request, as Will now be described with reference to  FIGS. 2 and 3 .  FIG. 2  is a flowchart illustrating the steps implemented by an ATM customer to request authorization of a transaction at one of the ATMs  12   b .  FIG. 3  is a pictorial view of a Web page presented to the customer. 
         [0033]    Initially, the customer accesses his/her bank&#39;s Web site (step  100 ) and selects an option to request authorization of a transaction (step  102 ). The Web site then provides a Web page  50  having a plurality of fields for completion by the customer, as illustrated in  FIG. 3 . These fields include an ATM identification field  52 , a transaction amount field  54 , a transaction type field  55  (if needed), a username field  56 , and a password field  58  (although the customer may already have entered his/her username and password to reach this Web page). 
         [0034]    The ATM identification field  52  is a drop-down list that identifies ATMs by the location of the ATM, for example, an address (20 Main Street) or a retail location (within a named department store). The Web page  50  may allow the customer to replace the address of an ATM in the drop-down list with his/her own label, to enable the customer to select the desired ATM (for example, “ATM near my office”). In this example, the customer selects ATM  12   b.    
         [0035]    The transaction amount field  54  allows the customer to enter the amount of money to be dispensed. In this example, the customer selects fifty U.S. dollars ($50). 
         [0036]    The username field  56  and password field  58  allow the customer to enter his/her Web site username and password that he/she uses to access that Web site. 
         [0037]    The customer then completes these fields  52  to  58  (step  104 ), and submits the request (step  106 ) to the Web server  22  by clicking on the “Submit” button  62 . 
         [0038]    The Web server  22  responds by confirming receipt of the request and providing the customer with a transaction code. In this example, the transaction code provided is “12345”. 
         [0039]    The operation of the host  14  will now be described with reference to  FIG. 4 , which is a flowchart illustrating the steps performed by the host  14  in response to the Web server  22  forwarding the transaction request entered by the customer. 
         [0040]    Initially, the host  14  receives the transaction request (step  110 ), and parses the received request (step  112 ) to ascertain which customer account is being referenced and the details of the transaction requested (in this example, withdrawal of fifty dollars). 
         [0041]    The host  14  then applies an acceptance criterion (step  114 ). In this example, the acceptance criterion comprises (i) comparing the password entered in field  58  with the password registered for that username to ensure that they match, and (ii) confirming that the customer has sufficient funds in his/her account to meet the withdrawal request (in this example, fifty dollars). 
         [0042]    If the acceptance criterion is not fulfilled, then the host  14  denies the request (step  116 ) and sends a message to the customer (for example, by email, text message, and/or by placing a message for that customer on the customer&#39;s Web page  50 ) to alert the customer to this failed transaction request (step  118 ). 
         [0043]    If the acceptance criterion is fulfilled, then the host  14  transmits a pending transaction message to the ATM identified in the ATM identification field  52  (in this example, ATM  12   b ) (step  120 ). The pending transaction message comprises a transaction identification field, a customer verification field, a transaction amount field, and a lifetime field. 
         [0044]    The transaction identification field includes the transaction code provided to the customer. 
         [0045]    The customer verification field includes a code assigned to the customer, which may be a PIN or a PIN offset—for convenience, both a PIN and a PIN offset will be referred to herein as a PIN. 
         [0046]    The transaction amount field includes data indicating that fifty dollars is to be withdrawn. 
         [0047]    The lifetime field includes a time at which the transaction will expire, in this example, one day after the customer sent the transaction authorization request. 
         [0048]    The host  14  then creates an entry for the pending transaction message in the pending transaction store  26  (see  FIG. 1 ) within the host  14  (step  122 ). 
         [0049]    The operation of the ATM  12   b  will now be described with reference to  FIG. 5 , which is a flowchart illustrating the steps implemented by the ATM  12   b  in response to receipt of the pending transaction message. 
         [0050]    Initially, the ATM  12   b  receives the pending transaction message (step  130 ), parses the message (step  132 ) to ascertain the lifetime of the transaction (from the lifetime field), and stores the received message (step  134 ) as an entry in the pending transaction list  28   b.    
         [0051]    The ATM  12   b  periodically monitors the pending transaction list  28   b  to identify any expired transactions (step  136 ) 
         [0052]    If the transaction referenced by the pending transaction message is not executed before expiry of the time limit in the lifetime field then the ATM  12   b  deletes the pending transaction message (step  138 ) and notifies the host  14  accordingly (step  140 ). 
         [0053]    If the customer arrives at the ATM  12   b  prior to expiry of the lifetime of the pending transaction (step  142 ), then the customer can select an option to execute an approved transaction (step  144 ). The customer can do this without presenting any token to the ATM  12   b  because the option is provided as part of a welcome screen on the ATM  12   b . Conventional tokens include an ATM card, a credit card, a part of the customer&#39;s body (for reading by a biometric reader), a Bluetooth (trade mark) device, or the like. 
         [0054]    In response to the customer selecting the option to execute an approved transaction, the ATM  12   b  presents the customer with an input screen prompting the customer to enter a transaction code and a customer code (in this example, a four digit PIN that the customer uses to access his/her bank account) (step  146 ). 
         [0055]    The customer then enters the transaction code he/she was provided by the Web page  50 , that is, “12345”, and his/her PIN (which is a four digit number). The ATM  12   b  detects these customer entries (step  148 ). 
         [0056]    The ATM  12   b  then attempts to match the received transaction code (“12345”) with the transaction codes in the pending transaction list. If there is a match, then the ATM  12   b  ascertains if the entered PIN matches the PIN for the matched entry in the pending transaction list (step  150 ). 
         [0057]    If both the transaction code and the PIN match the corresponding codes in an entry in the pending transaction list, then the transaction is fulfilled (step  152 ) by the ATM  12   b  by dispensing fifty dollars (the transaction amount) to the customer. The ATM  12   b  then deletes the transaction from the pending transaction list (step  154 ) and notifies the host  14  that the transaction has been executed (step  156 ), so that the host  14  can delete the transaction from the pending transaction store  26  and debit the amount of money dispensed (fifty dollars) from the customer&#39;s account. 
         [0058]    If either (i) the received transaction code (“12345”) does not match any of the transaction codes in the pending transaction list, or (ii) the received transaction code does match a transaction code in the list, but the PIN does not match the corresponding code for that entry, then the transaction is not fulfilled by the ATM  12   b  (step  158 ). Instead, the ATM  12   b  returns to step  136 , where the ATM  12   b  periodically monitors the pending transaction list to identify any expired transactions. 
         [0059]    It will now be appreciated that this embodiment has the advantage that a customer can enter a transaction for subsequent execution at a selected ATM, and execute that transaction even if the ATM is temporarily offline. 
         [0060]    This embodiment has a number of advantages over a conventional transaction where an identification token is required and a real-time authorization is performed with a remote host. 
         [0061]    This embodiment is economical because it does not need any new hardware on the ATM. It enables offline transactions to be performed. It speeds up transactions because no remote authorization is required. There is also less traffic between the ATM and the host. ATM availability is improved since no card readers are required to execute these transactions, so even when a card reader is broken or faulty, an ATM can remain in service for this type of transaction. 
         [0062]    Various modifications may be made to the above described embodiment within the scope of the invention, for example, in other embodiments, a customer may use the IVR system to request a transaction, or the customer may send a text message or electronic mail message to request a transaction. 
         [0063]    In other embodiments, the Web page may be different to that shown. The customer may have to login to the Web site prior to being able to access the Web page shown in  FIG. 3  or may have to provide additional security information to request authorization for a transaction. In other embodiments, the Web page may have different fields to those shown, for example, the customer may be allowed to select the lifetime of the transaction. 
         [0064]    In other embodiments, the customer&#39;s account may be debited when the transaction request is accepted by the host. 
         [0065]    In other embodiments, the customer may be allowed to select a transaction code rather than the Web server assigning it to the customer. This allows the customer to select a memorable code for use in executing the transaction. In such embodiments, the acceptance criterion may include confirming that there is no pending transaction with the same transaction code as that requested by the customer. 
         [0066]    In other embodiments, the ATM may dispense electronic cash to the customer or some other form of valuable media, such as a ticket. 
         [0067]    In other embodiments, an SST other than an ATM may be provided, for example, a ticket issuing kiosk. 
         [0068]    In the above embodiment, the customer&#39;s PIN was used in the customer verification field. In other embodiments, a different code may be used to increase security and reduce the possibility of the customer&#39;s PIN being intercepted. 
         [0069]    In other embodiments, a public network (such as the Internet) may be used instead of the private network. 
         [0070]    All communications may be encrypted to reduce the possibility of fraud. 
         [0071]    In another embodiment, a text message from a cellular telephone may be used to send a transaction authorization request. In such embodiments, the customer may pre-register his/her cellular telephone number with the bank so that the host can identify the customer. When the customer wishes to withdraw cash, the customer sends a text message to a specific telephone number that the bank uses for requesting this type of service. The text message may have the format shown below:
       Message Format: &lt;TX&gt;&lt;ACCTNUM&gt;&lt;AMT&gt;&lt;ATMID&gt;&lt;CODE&gt;       
 
         [0073]    Where TX is the type of transaction required, such as withdrawal of cash (WDL), cash deposit (DCASH), cheque deposit (DCHK), or the like. ACCTNUM is the number of the customer&#39;s account. AMT is the amount of the transaction (for example, thirty dollars). ATMID is the identity of the ATM at which the customer desires to execute this transaction. CODE is an additional customer identification code (such as a four digit code) to verify the identity of the customer. 
         [0074]    Once received, the bank will apply an acceptance criterion to this text message (for example, ascertaining if the telephone number and customer identification code pair combination is correct, and ascertaining if the customer has sufficient funds for the requested transaction). If the acceptance criterion is fulfilled, then the bank authorizes the transaction and sends the customer a verification code, for example, as a text message. The customer can visit the ATM identified by the ATMID field within a preset time period (for example, within two hours of sending the text message), and enter the verification code and his PIN. Since the ATM has already received the approval from the host, it will verify the PIN/verification code locally and dispense the requested cash without any delay. This embodiment enables a person to enter a transaction while traveling home from work (for example, on a train) and collect the requested cash at an ATM en route to his/her home. 
         [0075]    In other embodiments, different transactions to that shown can be implemented, for example, dispensing stamps. 
         [0076]    In other embodiments, the customer&#39;s ATM card number may be used as a transaction code so that the customer can enter that number at the selected ATM, or insert the card having that number at the selected ATM, to provide the transaction code to the ATM. Where an integrated circuit card is used, the ATM may update account details (such as the amount of cash withdrawn) stored on the card. 
         [0077]    In other-embodiments, a transaction code may be derived from characteristics (a biometric) of the customer. For example, a customer&#39;s fingerprint may be used to create the transaction code, so that the customer on arriving at the selected ATM presents his/her finger to a biometric reader at that ATM. 
         [0078]    In other embodiments, a customer&#39;s card and a biometric reading may be used as the transaction code and customer code. 
         [0079]    In other embodiments, a customer may be able to cancel a previously entered transaction request. This cancellation may be made using the same transaction request channel or a different transaction request channel to that used to request the transaction. The host would then inform the selected self-service terminal to remove the transaction from the pending transaction list. Alternatively, the customer may be able to cancel a previously entered transaction request at the terminal storing the transaction request. This terminal would then remove the transaction from the pending transaction list and transmit a transaction cancelled message to the host. The host would then delete the transaction from the pending transaction store and ensure that the customer&#39;s account was not debited for that transaction. 
         [0080]    In other embodiments, the customer may submit multiple transaction requests to a host in a single session. These requests may be entered individually or concatenated. Examples include dispense fifty dollars, print a cheque for one hundred and sixty dollars, dispense stamps to the value of five dollars, and the like. These requests may be submitted for execution at one terminal, or at a plurality of different terminals, for example, transaction number one at a first terminal, transaction number two at a second terminal, and the like. 
         [0081]    In other embodiments, if a selected terminal goes out of service subsequent to the transaction request but prior to transaction fulfillment, then that terminal may inform the host with the change in its state. Either the terminal or the host may provide the customer with an alternative terminal at which the transaction may be executed. 
         [0082]    In other embodiments, the terminal may not be a financial terminal, and the transactions may not be related to cash.