Abstract:
A transaction authorization server comprising: a database storing a plurality of customer account records, a network connection operable to communicate with a remote cash dispenser and to receive transaction requests therefrom; and a processor. Each customer account record includes: a unique identifier associated with that customer, an account balance, and customer contact information. The processor is operable to: (i) receive a transaction request, (ii) ascertain from the transaction request a unique identifier and a transaction amount. The processor then (iii) accesses the database using the ascertained unique identifier to: (a) identify a customer account record having a unique identifier matching the ascertained unique identifier, (b) confirm that the transaction amount meets an acceptance criterion based on information contained within that customer account record, but without verifying a personal identification number, and (c) ascertain customer contact information from that customer account record.

Description:
FIELD OF INVENTION 
       [0001]    The present invention relates to transaction authorization. In particular, although not exclusively, the invention relates to authorization of a transaction that does not include a personal identification number (PIN). 
       BACKGROUND OF INVENTION 
       [0002]    ATMs provide bank account holders with the most useful source of cash because ATMs are deployed in a large number of locations and are usually accessible on a 24×7 basis. Some ATMs only provide cash dispensing; other ATMs provide a range of different transactions, including cash deposit, cash dispense, check deposit, bill payment, and the like. However, the most popular transaction at an ATM is cash dispensing. 
         [0003]    It would be desirable to increase the number of ATMs deployed. One limitation on the number of ATMs that can be deployed is the high cost of each ATM; even if the ATM is limited to cash dispensing (as opposed to cash deposit and/or cash recycling, check deposit, and the like). 
         [0004]    A large part of the cost of a cash dispenser arises from the peripheral devices needed (a display, a cash dispenser, a receipt printer, a journal printer, and the like), and also from the software needed to control these peripheral devices (referred to as the platform software, which is effectively an enhanced operating system). 
         [0005]    Some low cost cash dispensers have been proposed, such as those described in U.S. Pat. No. 6,659,342 and U.S. Pat. No. 7,577,612. 
         [0006]    However, even low cost dispensers typically require the customer to enter a PIN (either directly at the dispenser or via a dislocated interface). This means that there must be a secure mechanism for ensuring that the customer&#39;s PIN is not vulnerable to access by a fraudulent device or person. 
         [0007]    It would be desirable to provide a mechanism for authenticating a transaction that does not require a PIN to be transmitted from a cash dispenser, or even entered by the customer. 
       SUMMARY OF INVENTION 
       [0008]    Accordingly, the invention generally provides methods, systems, apparatus, and software for authorizing a cash dispense transaction for a customer&#39;s account, where the transaction is authorized without verifying a customer&#39;s PIN, and a message is sent to the customer to notify the customer of the transaction. 
         [0009]    In addition to the 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 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. 
         [0010]    According to a first aspect there is provided a transaction authorization server comprising: 
         [0011]    a database storing a plurality of customer account records, each customer account record being dedicated to a customer, and each customer account record including: a unique identifier associated with that customer, an account balance, and customer contact information; 
         [0012]    a network connection operable to communicate with a remote cash dispenser and to receive transaction requests therefrom; and 
         [0013]    a processor operable to: (i) receive a transaction request from a remote cash dispenser via the network connection, (ii) ascertain from the transaction request a unique identifier and a transaction amount, (iii) access the database using the ascertained unique identifier to: (a) identify a customer account record having a unique identifier matching the ascertained unique identifier, (b) confirm that the transaction amount meets an acceptance criterion based on information contained within that customer account record, but without verifying a personal identification number, and (c) ascertain customer contact information from that customer account record, (iv) approve the transaction request in the event that the transaction amount meets the acceptance criterion, and (v) send a message to the customer using the ascertained customer contact information. 
         [0014]    As used herein, the word “database” relates to an organized collection of data in digital form. The word database is not limited to data stored in SQL format, DB2 format, or in any other specific format. 
         [0015]    The transaction authorization server may further comprise a cryptographic memory for storing cryptographic information so that transaction requests can be decrypted and responses to transaction requests (such as transaction approved messages or transaction denied messages) can be encrypted and/or digitally signed prior to being sent. 
         [0016]    The network connection may comprise a modem, such as a cellular radiofrequency modem, an Ethernet card, or any other convenient network connection. 
         [0017]    The cryptographic memory may be tamper responsive so that encryption keys are automatically deleted if an attempt is made to compromise the cryptographic memory. 
         [0018]    Each customer account record may also include a biometrics template for that customer. 
         [0019]    According to a second aspect there is provided a method of authorizing a transaction, the method comprising: 
         [0020]    (i) receiving a transaction request; 
         [0021]    (ii) ascertaining from the transaction request a unique identifier and a transaction amount; 
         [0022]    (iii) accessing a database of customer account records using the ascertained unique identifier; 
         [0023]    (iv) identifying a customer account record having a unique identifier matching the ascertained unique identifier; 
         [0024]    (v) assessing whether the transaction amount meets an acceptance criterion, without verifying a personal identification number provided by the customer; 
         [0025]    (vi) ascertaining customer contact information from the identified customer account record; 
         [0026]    (vii) authorizing the transaction request in the event that the transaction amount meets the acceptance criterion; and 
         [0027]    (viii) sending a message to the customer using the ascertained customer contact information, where the message indicates that a transaction has been approved. 
         [0028]    The step of (v) assessing whether the transaction amount meets an acceptance criterion, may include: (a) ensuring that the transaction amount does not exceed a maximum withdrawal amount, and (b) ensuring that the customer account has at least as much funds as would be required to dispense the transaction amount. 
         [0029]    The maximum withdrawal amount may be set by the account holder and/or by the account provider (for example, a financial institution that provides the customer with the account). 
         [0030]    The maximum withdrawal amount may relate to an aggregate amount within a set time period. For example, there may be a limit on the total amount that can be withdrawn in any given 24 hour period, or on a rolling 24-hour basis. The maximum withdrawal amount may vary depending on the location of a self-service terminal at which the transaction is executed. 
         [0031]    Alternatively, or additionally, the maximum withdrawal amount may relate to a maximum amount that can be withdrawn per transaction. 
         [0032]    The method may comprise the further step of (ii-1) decrypting the transaction request. 
         [0033]    The transaction request may be received from a remote cash dispenser. 
         [0034]    The step of (vii) authorizing the transaction request, may include the sub-steps of (a) encrypting the authorized transaction request, and (b) transmitting the encrypted authorized transaction request to the remote cash dispenser that sent the transaction request. 
         [0035]    The step of (viii) sending a message to the customer using the ascertained customer contact information is implemented directly in the sense that the message is not sent via a cash dispenser that sent the transaction request. The step of (viii) sending a message to the customer using the ascertained customer contact information may be implemented by sending text to be included in the message to a message aggregator that sends a text message to the customer. 
         [0036]    According to a third aspect there is provided a method of authorizing a cash dispense transaction for a customer&#39;s account, where the method comprises: receiving a transaction request that does not include a personal identification number; authorizing the transaction based on information stored in a customer account record; and transmitting a message to the customer to notify the customer that a transaction has been authorized. 
         [0037]    The message may be transmitted using a text messaging service (such as SMS). 
         [0038]    The telephone number of the customer may be stored in a customer account record associated with that customer. 
         [0039]    It should now be appreciated that these aspects enable a transaction authorization server to authorize a transaction without requiring the customer (or any other party) to provide a PIN, and also to provide a customer with immediate notification that a transaction has been executed. 
         [0040]    For clarity and simplicity of description, not all combinations of elements provided in the aspects recited above have been set forth expressly. Notwithstanding this, the skilled person will directly and unambiguously recognize that unless it is not technically possible, or it is explicitly stated to the contrary, the consistory clauses referring to one aspect are intended to apply mutatis mutandis as optional features of every other aspect to which those consistory clauses could possibly relate. 
         [0041]    These and other aspects will be apparent from the following specific description, given by way of example, with reference to the accompanying drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0042]      FIG. 1  is block diagram of a media dispensing self-service terminal for use with a transaction authorization server; 
           [0043]      FIG. 2  is a block diagram illustrating the self-service terminal of  FIG. 1  coupled to a remote transaction authorization server for authorizing transactions according to one embodiment of the present invention; 
           [0044]      FIG. 3  is a flowchart illustrating steps implemented by a company operating the terminal of  FIG. 1  to register a prospective customer of that terminal; 
           [0045]      FIG. 4  is a flowchart illustrating steps implemented by the terminal of  FIG. 1  to create and transmit a transaction request in response to a customer request; 
           [0046]      FIG. 5  illustrates a table stored in a memory in the remote server of  FIG. 2 ; 
           [0047]      FIG. 6  is a flowchart illustrating steps performed by the remote server of  FIG. 2  in response to receiving an encrypted transaction request from the self-service terminal of  FIG. 1 ; and 
           [0048]      FIG. 7  is a flowchart illustrating the steps implemented by the self-service terminal of  FIG. 1  to fulfill the transaction request for the customer. 
       
    
    
     DETAILED DESCRIPTION 
       [0049]    Reference is first made to  FIG. 1 , which is a block diagram of a media dispensing self-service terminal  10  (in the form of an ATM) according to one embodiment of the present invention. 
         [0050]    The ATM  10  comprises a secure casing  12  defining a user interface area  14 . The user interface area  14  includes a dispense slot  16  through which banknotes can be dispensed. The user interface area  14  also includes a media exit indicator  18  surrounding the dispense slot  16 , a plurality of lights in the form of a tri-color LED  20 , a loudspeaker  22 , and a contact token reader  24  in the form of a conventional NFC reader. The user interface area  14  also includes a “customer tap” area  26  in front of the NFC reader  24 . This customer tap area  26  includes a decal with text stating “Tap here for cash” and an image of a mobile phone and/or a card. This decal is used to alert customers to the area to be tapped to initiate a cash dispense transaction. 
         [0051]    The secure casing  12  encloses a media dispenser  30  in the form of a two-high currency dispenser, an uninterruptible power supply  32  for powering the currency dispenser  30 , and a control board  34 . 
         [0052]    The currency dispenser  30  includes two currency cassettes  40 , 42 , and a banknote pick unit  44 , and a banknote transport  46  for conveying a picked banknote to the dispense slot  16 . The first currency cassette  40  stores a plurality of ten dollar banknotes; the second currency cassette  42  stores a plurality of twenty dollar banknotes. 
         [0053]    The control board  34  comprises control components  50  for controlling the dispenser  30 , a processor  52  programmed to control the ATM  10 , and a cryptographic memory  54  storing cryptographic data (for example, encryption keys) to support creating and maintaining a virtual private network (VPN). The cryptographic memory  54  is tamper responsive so that it will delete cryptographic data if a third party attempts to compromise the cryptographic memory  54 . 
         [0054]    The control components  50  are conventional and include interfaces, in this embodiment USB interfaces, an audio interface, and an SPI interface, to allow devices to be connected to the control components  50 . In this embodiment, a cellular radiofrequency modem  60  is coupled to the control components  50 . In addition, the media exit indicator  18 , the tri-color LED  20 , the loudspeaker  22 , and the NFC reader  24  are also connected to the control components  50  via the interfaces. 
         [0055]    Reference will now also be made to  FIG. 2 , which is a block diagram illustrating the ATM  10  coupled to a remote server  70  via an Internet Protocol network  72 . As will be discussed further below, the ATM  10  creates a virtual private network (VPN) with the remote server  70  to ensure that communications between the ATM  10  and the remote server  70  are secure. 
         [0056]    The operation of the ATM  10  will now be described with reference to  FIG. 3 , which is a flowchart  100  illustrating steps implemented by a company owning and/or operating the ATM  10  to allow a customer to create an account from which cash can be dispensed by the ATM  10 . 
         [0057]    Initially, the prospective ATM customer (hereinafter “customer”) contacts the ATM owner (in this example, a financial institution, but in other embodiments a payment provider or other trusted third party) to create an account. In this example, the customer contacts the financial institution (referred to herein as the operating bank) using a Web site of the operating bank. 
         [0058]    The customer then requests a “tap and dispense” account to be created for him/her using the operating bank&#39;s Web site. The operating bank receives this request (step  102 ), and then asks the customer some account related questions via the Web site (step  104 ). These questions request the customer&#39;s name, address, date of birth, and the like. In addition, the customer is requested to provide at least one near-real-time contact mechanism. Examples of a near-real-time contact mechanism includes a cellular telephone number for receiving an SMS message, a cellular telephone number for receiving a voice call from a computer providing computer-generated speech, an email address for receiving an email, an instant messaging address, or the like. The customer is also asked to select at least one of the near-real-time contact mechanisms as the default mechanism for notifying the customer of a transaction. 
         [0059]    The operating bank collates these responses (step  106 ) and associates the responses with a newly created tap and dispense account for the customer (step  108 ). The operating bank may additionally require the customer to provide photographic identification (such as a passport or drivers&#39; license) and a utility bill including the customer&#39;s address and to visit a branch of the operating bank in person so that a member of branch staff can validate the customer&#39;s identity. 
         [0060]    The operating bank then allocates a near field communication (NFC) transmitter to the customer (step  110 ), reads a unique identification stored in the NFC transmitter (step  112 ), and then associates that unique identification with the customer&#39;s newly-created account (step  114 ). 
         [0061]    The operating bank then mails the NFC transmitter to the customer. The NFC transmitter is mounted on an adhesive carrier so that the carrier can be adhered to another object. 
         [0062]    If the customer is not an existing customer of the operating bank then this will be a new account. If the customer is an existing customer, then this may be a new account or it may be a logical partition of the customer&#39;s existing account. 
         [0063]    The customer can then transfer money into this new tap and dispense account using a conventional funds transfer feature from another account. Alternatively, the customer may go to a branch of the operating bank and pay cash into the account, or the customer may deposit cash into a cash deposit ATM owned by the operating bank to credit the tap and dispense account. Whichever mechanism is used, the operating bank receives the transferred funds and credits the customer&#39;s tap and dispense account (step  116 ). 
         [0064]    The customer may use the operating bank&#39;s Web site to configure rules for how this account operates. In this example, the customer sets a maximum daily withdrawal amount of thirty dollars (this period may cover a calendar day, or a rolling 24 hour period). The Web site receives this request and applies it to the customer&#39;s account (step  118 ). The operating bank may include default rules that apply in the absence of any customer configured rules. In this embodiment, the default rules limit the daily withdrawal amount to twenty dollars, but the customer can change this in ten dollar increments between ten and fifty dollars (the maximum daily withdrawal). 
         [0065]    When the customer receives the NFC transmitter, the customer can then adhere the carrier to an inside surface of a battery compartment of the customer&#39;s cellular telephone (or to any other part of the cellular telephone, or to any other object the customer wants to use to enter transaction requests at the ATM  10 ). 
         [0066]    At this stage, the customer&#39;s account is ready for use and the customer is ready to conduct a transaction. 
         [0067]    To withdraw cash, the customer will tap his/her mobile phone on the ATM  10 . Each tap by the customer corresponds to a request for dispensing ten dollars (or some other fixed amount determined by the ATM operator). By tapping multiple times (for example three times) in quick succession, the customer requests dispensing of that multiple of ten dollars (for example thirty dollars for three taps). However, the ATM  10  will only dispense a maximum amount in any one transaction (in this embodiment fifty dollars) and/or on any one day and/or in any twenty-four hour period. Although each tap represents ten dollars, the ATM  10  includes two currency cassettes  40 , 42 , so a request for thirty dollars may be fulfilled using one ten dollar banknote (from the first cassette  40 ) and one twenty dollar banknote (from the second cassette  42 ). 
         [0068]    The operation of the ATM  10  will now be described with reference to  FIG. 4 , which is a flowchart  130  illustrating steps implemented by the ATM  10  of  FIG. 1  to create and transmit a transaction request in response to a customer request to withdraw cash. 
         [0069]    Initially, the customer walks (or drives) up to the ATM  10 . The customer then taps the rear of his/her cellular telephone (hereinafter “mobile phone”) on the user interface area  14 . In particular, the customer taps his/her mobile phone on the customer tap area  26 . 
         [0070]    The NFC reader  24  receives a transmission from the NFC transmitter in the customer&#39;s mobile phone (step  132 ). This transmission includes the unique identification of the NFC transmitter, which the processor  52  in the control board  34  ascertains and stores temporarily (step  134 ). 
         [0071]    The processor  52  then illuminates the tri-color LED  20  so that a green color is temporarily energized (step  136 ) and emits a short beep through the loudspeaker  22  (step  138 ). This provides the customer with audible and visual feedback to indicate that the ATM  10  has detected the customer tapping his/her phone. 
         [0072]    The processor  52  then waits for a delay period to ascertain if there will be any subsequent taps (step  140 ). In this embodiment, the delay period is approximately four seconds. If a subsequent tap of the customer&#39;s mobile phone is received within the delay period (step  142 ) (that is, prior to the delay period elapsing), then the processor  52  increments a transaction amount by ten dollars (one tap means ten dollars, a second tap within the delay period means twenty dollars, a third tap within the delay period means thirty dollars, and so on) (step  144 ) and then resets the delay period (step  146 ). 
         [0073]    The processor  52  continues in this loop (steps  140  to  146 ) until the delay period expires. 
         [0074]    When the delay period expires, the processor  52  creates a transaction request (step  150 ). 
         [0075]    The transaction request includes a transaction amount equal to the number of taps that the ATM  10  received from the customer (where each successive tap was received within the delay period from the previous tap). The transaction request also includes a transaction amount (in this example, thirty dollars) corresponding to the number of taps received by the ATM  10 . 
         [0076]    The processor  52  also accesses encryption data stored in the cryptographic memory  54  so that the transaction request is encrypted (step  152 ) for transmission to the remote server  70  using a virtual private network. 
         [0077]    The processor  52  transmits the encrypted transaction request to the remote server  70  using the cellular radiofrequency modem  60  (step  154 ). 
         [0078]    Reference will now also be made to  FIG. 5 , which illustrates a table  170  stored in a memory (not shown) in the remote server  70 , where the table  170  stores account information. 
         [0079]    The table  170  comprises a header row  172  including a plurality of columns, each with a respective column header. These column headers include: an NFC identifier  174 , an account balance  175 , a contact type  176 , a contact identifier  177 , a contact preference  178 , a maximum withdrawal amount as set by the operator of the ATM  10  (the operating bank)  179 , and a maximum withdrawal amount as set by the account holder  180 . Additional columns may be provided, for example there may be multiple sets of columns  176  and  177 , one set for each type of contact (for example, SMS, email, telephone, instant messaging). 
         [0080]    Table  170  includes multiple rows (for example, row  190  for a first customer), each row dedicated to a different account. 
         [0081]    The first customer row  190  includes an identification cell  191  under column header  174  that includes a numeric/text string corresponding to the unique NFC identification associated with that customer&#39;s NFC transmitter. 
         [0082]    The first customer row  190  includes a cash balance cell  192  under column header  175  that includes the current balance of the customer&#39;s tap and dispense account. This is a numeric field. 
         [0083]    The first customer row  190  includes a contact type cell  193  under column header  176  that includes a code indicating the type of contact the customer has registered. For example, this may comprise a code relating to SMS messaging, email, instant messaging, or the like. 
         [0084]    A contact identifier cell  194  under column header  177  is associated with the contact type cell  193 , and includes a string corresponding to the contact number or contact name of the contact type. For example, this may comprise a telephone number for SMS or telephone, an email address for email, or the like. 
         [0085]    A contact preference cell  195  under column header  178  is associated with all of the contact type cells and contact identifier cells that are used (there may be multiple sets of these cells). The contact preference cell  195  indicates the preferred contact method as set by the customer. This may comprise sending a message via all of the contact types registered, or sending a message to only one of the contact types, but if that fails, sending a message to another contact type. Alternatively, there may be preference rules set by the customer that select a contact type based on the time or day. The contact preference cell  195  comprises a code that is interpreted by the server  70  to indicate the preferred contact method selected by the customer. The server  70  interprets the codes by accessing an additional table (not shown) that maps codes from the contact preference cell  195  to the contact type(s). 
         [0086]    An ATM-owner-set maximum withdrawal cell  196  under column header  179  indicates the maximum amount that the owner/operator of the ATM  10  is willing any customer to withdraw per day. In this example, the ATM owner is willing to allow up to $60 to be withdrawn each day. In this embodiment, the ATM owner controls all of the ATMs that can dispense cash deducted from the customer&#39;s account. For this reason, the customer&#39;s account can include a field containing the maximum amount set by the ATM owner. However, in other embodiments, a plurality of ATM owners may control the ATMs that can dispense cash deducted from the customer&#39;s account. In such embodiments, the customer&#39;s account may not include a field containing the maximum amount set by the ATM owner, unless the plurality of ATM owners all agree on the same maximum daily withdrawal amount. 
         [0087]    A customer-set maximum withdrawal cell  197  under column header  180  indicates the maximum amount that the customer (the account holder) will allow to be withdrawn from his/her account per day. In this example, the customer is only willing to allow up to $30 to be withdrawn each day. As a result, this is the maximum that the customer can withdraw in a day, or if the customer&#39;s mobile phone is stolen, this is the maximum amount that can be withdrawn in any continuous twenty-four hour period. If the customer&#39;s mobile phone is stolen, then the customer should be able to notify the operating bank immediately, which can freeze the tap and dispense account, so that only $30 (the daily withdrawal limit set by the customer) of the customer&#39;s money is at risk. 
         [0088]    Reference will now also be made to  FIG. 6 , which is a flowchart  200  illustrating the steps performed by the remote server  70  in response to receiving an encrypted transaction request from the ATM  10 . 
         [0089]    Initially, the server  70  receives the encrypted transaction request (step  202 ), decrypts the request (step  204 ), and ascertains the unique NFC identification from the decrypted request and the amount of cash requested (step  206 ). 
         [0090]    The server  70  then uses the unique NFC identification as a key to access the appropriate row of the table  170  (referred to herein as the “customer row”) (step  208 ). The customer row is the row that includes the ascertained unique NFC identification under the NFC identifier column header  174 . 
         [0091]    Once the customer row has been identified, the server  70  then ascertains if the customer&#39;s account has sufficient funds to cover the dispense request (step  210 ). This is implemented by ascertaining the account balance from the cell in the customer row under the account balance column header  175 . 
         [0092]    If the customer&#39;s account does not have sufficient funds then the server  70  sends a transaction denied response to the ATM  10  (step  212 ). 
         [0093]    If the customer&#39;s account does have sufficient funds to cover the requested transaction, then the server  70  then ascertains if the requested amount exceeds either the operator defined daily maximum (under column header  179 ) or the customer defined daily maximum amount (under column  180 ) (step  214 ). 
         [0094]    The transaction request will be denied if at least one of the following conditions occurs: (i) the transaction amount exceeds the operator defined daily maximum amount, or (ii) the transaction amount exceeds the customer defined daily maximum amount, or (iii) the transaction amount, when added to previous transactions executed on the day of the transaction, exceeds either condition (i) or condition (ii). If any of these conditions occur, then the server  70  sends a transaction denied response to the ATM  10  (step  212 ). 
         [0095]    To enable condition (iii) to be checked, the server  70  updates the table  170  (the specific field is not illustrated) with the amount withdrawn each day. This amount is reset at the start of each day. 
         [0096]    If none of these three conditions occur, then the server  70  sends a transaction approved response to the ATM  10  (step  216 ). 
         [0097]    The server  70  then sends out a notification of approval of a transaction to the customer&#39;s preferred contact mechanism (step  218 ). This is implemented using the following sub-steps. The server  70  accesses the cell in the customer row under the contact preference column header  178  to ascertain the code indicating the customer&#39;s preferred contact mechanism. The server  70  interprets this code (by accessing another table (not shown)). In this example, the code indicates that a text message (SMS) should be sent to the customer&#39;s mobile phone. The server  70  then accesses the cell in the customer row under the contact identifier column header  177  to ascertain the customer&#39;s mobile phone number. Where multiple customer identifier columns are provided, the cell relating to the customer&#39;s mobile phone (in this example) is the cell that is accessed. The server  70  then sends a text message to the customer&#39;s mobile phone number including details of the transaction. In this embodiment, the details of the transaction include the time, date, and amount of the transaction. The details of the transaction may also include an amount remaining that can be withdrawn that day (or rolling period) and/or a total amount remaining in the account. 
         [0098]    The server  70  then updates the table  170  by decrementing the account balance by the amount approved for dispensing (plus any transaction fee that is applied) and by adding the transaction amount to a daily amount field (not shown) for that customer (step  220 ). 
         [0099]    The fulfillment part of the transaction will now be described with reference to  FIG. 7 , which is a flowchart  230  illustrating the steps implemented by the ATM  10  to fulfill the transaction for the customer. 
         [0100]    The processor  52  in the ATM  10  receives a response from the server  70  (step  232 ). The processor  52  then decrypts the response (step  234 ) and ascertains if the server  70  approved or denied the transaction (step  236 ). 
         [0101]    If the transaction was denied by the server  70 , then the processor  52  uses the control components  50  to illuminate the tri-color LED  20  so that a red color is temporarily energized (step  238 ). The processor  52  also emits a long beep through the loudspeaker  22  (step  240 ). This provides the customer with both visual and audible feedback to indicate that the transaction is denied. 
         [0102]    If the transaction was approved by the server  70 , then the processor  52  illuminates the media exit indicator  18  surrounding the dispense slot  16  (step  250 ). This draws the customer&#39;s attention to the area at the requested cash (thirty dollars) will be dispensed. 
         [0103]    The processor  52  also illuminates the tri-color LED  20  so that a green color is temporarily energized (step  252 ). Steps  250  and  252  may occur simultaneously. 
         [0104]    The processor  52  then uses the control components  50  to dispense the requested cash (thirty dollars) to the customer (step  254 ), thereby concluding the transaction. 
         [0105]    Once the customer has removed the cash, the ATM  10  is then ready for the next customer. 
         [0106]    If at any time the ATM  10  needs to go out of service (for example, because of a banknote jam) then the processor  52  illuminates the tri-color LED as a red light. The ATM  10  may also send a message (in this embodiment an out of service message) to either (or both of) the remote server  70  or a remote management centre (not shown) so that the remote server  70  or remote management centre can dispatch a service engineer to fix the ATM  10 . The out of service message may also include some diagnostic information. 
         [0107]    If the ATM  10  does not have enough cash to fulfill a transaction, then the processor  52  illuminates the tri-color LED  20  as an amber light. The ATM  10  also sends a message to the remote server  70  to inform the remote server  70  that the transaction should be reversed because no funds were dispensed. The remote server  70  may send an SMS message to the customer to explain why the transaction was not fulfilled. 
         [0108]    It should now be appreciated that this embodiment allows a rudimentary dispenser to be equipped with a modem and a simple user interface and used as a low-cost cash dispenser. 
         [0109]    Various modifications may be made to the above described embodiment within the scope of the invention, for example, in other embodiments a different entity may operate the ATM to the entity that owns the ATM. 
         [0110]    In other embodiments, the customer may use an NFC transmitter built-into his/her mobile phone. The customer may have to attend a branch of the operating bank to register the unique identification of the NFC transmitter, or a secure mechanism may be used to convey the NFC transmitter identification to the operating bank. For example, the customer may download a mobile phone application (generally referred to as an “app”) that allows the customer to convey the NFC transmitter identification (or other token identification being used) to the bank (or other account provider). 
         [0111]    In other embodiments, a different object than a phone may be used to carry the token. For example, the object may comprise a card, a wallet, a camera, a purse, a watch, or the like. 
         [0112]    In other embodiments, a different wireless technology may be used to NFC, for example, an inductive or capacitive technology. 
         [0113]    In other embodiments, if more taps are received than the maximum dispense amount (in this example, five taps), then the processor  52  illuminates the tri-color LED  20  so that an amber (or orange) color is energized for a longer period than the temporary green illumination that indicates that a tap was successfully received. The processor  52  also emits a long beep through the loudspeaker  22 . This provides the customer with audio and visual feedback to indicate that the ATM  10  will not execute the requested transaction. 
         [0114]    In other embodiments, the tri-color LED may be replaced with a plurality of LEDs, each emitting a different color. 
         [0115]    In other embodiments, the table  170  may not store the customer account balance; instead, the table  170  may include a link to another table that stores the customer&#39;s account balance. 
         [0116]    In other embodiments, the contact token reader  24  may comprise a biometrics reader, such as a fingerprint reader. A customer would first register his/her fingerprint when creating a tap and dispense account. To enter a transaction, the customer would press his/her finger on the contact token reader  24  a desired number of times corresponding to the amount to be withdrawn (for example, three times for thirty dollars). 
         [0117]    In other embodiments, the dispense slot  16  may include a sensor for detecting when banknotes have been removed therefrom. The processor  52  may illuminate the media exit indicator  18  surrounding the dispense slot  16  until the dispensed cash is detected as having been removed. 
         [0118]    In other embodiments, each tap may correspond to a fixed amount other than ten dollars. For example, each tap may correspond to twenty dollars. In other embodiments, the fixed amount may relate to a currency other than US dollars, for example, Euros, Pound sterling, Yen, or the like. 
         [0119]    In other embodiments, the media dispenser may dispense tickets, coupons, or the like instead of, or in addition to, currency. 
         [0120]    In other embodiments, the media dispenser may comprise more or less than two currency cassettes. Each cassette may contain the same denomination, or a different denomination. Each cassette may contain the same currency or a different currency. 
         [0121]    In other embodiments, the media dispenser may comprise a spray dispenser rather than a bunch dispenser. 
         [0122]    In other embodiments, the media dispenser may retract any dispensed cash that is not retrieved by a customer. 
         [0123]    In other embodiments, the ATM  10  may include a biometrics reader, such as a fingerprint reader. The table  170  may also include a column for biometrics templates, so that a biometric template is stored for each customer. When the customer enters a transaction, the customer taps the object containing the NFC tag (for example, a mobile phone) on the NFC reader  24  a desired number of times to indicate the amount of cash requested. The customer then places his/her finger on the fingerprint reader. The fingerprint reader captures an image of the customer&#39;s finger and creates a biometric template based on that image. The ATM  10  then transmits (after performing encryption) a transaction request including the unique identifier read from the NFC tag, the amount of cash requested, and the biometrics template. The remote server  70  decrypts this transaction request, performs the same authentication steps that are described in  FIG. 6 , but also compares the received biometrics template with the biometrics template stored in the table  170 . If the two templates are a sufficiently close match then the transaction is approved, subject to the other steps in  FIG. 6  being satisfied. 
         [0124]    In the above embodiment, the remote server  70  is operable to authorize a transaction without verifying a personal identification number and without receiving a biometrics template for comparing with a stored biometrics template for that customer. In other embodiments, the remote server  70  may store a biometrics template for each customer. This would prevent a third party from accessing cash using the customer&#39;s mobile phone or NFC transmitter. 
         [0125]    In other embodiments, the remote server  70  may contain a second database. The second database may store information relating to all ATMs in the network that can access the remote server  70 . The stored information may include, for each ATM in the network: a serial number (or other identification) of the ATM, a location of the ATM, a maximum daily amount, a code identifying a bank owning the ATM, and the like. 
         [0126]    The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. The methods described herein may be performed by software in machine readable form on a tangible storage medium or as a propagating signal. 
         [0127]    The terms “comprising”, “including”, “incorporating”, and “having” are used herein to recite an open-ended list of one or more elements or steps, not a closed list. When such terms are used, those elements or steps recited in the list are not exclusive of other elements or steps that may be added to the list. 
         [0128]    Unless otherwise indicated by the context, the terms “a” and “an” are used herein to denote at least one of the elements, integers, steps, features, operations, or components mentioned thereafter, but do not exclude additional elements, integers, steps, features, operations, or components. 
         [0129]    The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to” or other similar phrases in some instances does not mean, and should not be construed as meaning, that the narrower case is intended or required in instances where such broadening phrases are not used. 
         [0130]    The reader&#39;s attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.