Abstract:
An automatic-transaction-machine (ATM) has a housing covering at least a portion of the ATM, a transmitter, and a receiver. The processor controls at least portions of some financial transactions conducted by the ATM. A banking computer system associated with the ATM is receives a pre-created transaction request from a customer using a mobile device. The ATM will not process the pre-created transaction request until the customer is verified to be present at the ATM. When the customer later brings the mobile device within range of the transmitter of the ATM, the ATM presents transaction-verification data to be received by the mobile device. The receiver of the ATM is configured to receive mobile-verification data back from the mobile device that is responsive to the transaction-verification data. When the mobile-verification data is authenticated by the banking computer system the ATM is configured to execute the pre-created transaction request.

Description:
PRIORITY CLAIM 
       [0001]    This patent application claims priority to U.S. provisional patent application Ser. No. 61/990,946 filed on May 9, 2014. This application also claims priority to PCT application PCT/US15/030174 filed on May 11, 2015. The subject matter of both applications is hereby incorporated by reference. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    There remains a need in the art for cardless ATM transactions and related methods. 
     
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
         [0003]      FIG. 1  is a flow diagram showing an embodiment for creating a mobile-wallet data set. 
           [0004]      FIG. 2  illustrates an embodiment for pre-staging a cardless ATM transaction using a personal computing device. 
           [0005]      FIG. 3  illustrates an embodiment for performing a cardless ATM transaction using a personal computing device in coordination with an ATM. 
           [0006]      FIG. 4  is a flow diagram showing a universal overview of an embodiment for performing a cardless ATM transaction. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0007]    Generally provided is a cardless ATM transaction driven by inputs from both 1) a personal computing device, and 2) an ATM. In embodiments, inputs from a personal computing device are used to create data set(s) that are subsequently used to drive an ATM transaction in a similar fashion to the dataset(s) created from a traditional debit card when inserted into an ATM to initiate an ATM transaction. As a result, embodiments allow for a cardless ATM transaction to be performed. 
         [0008]    Method and system embodiments are directed to: 1) creating a mobile-wallet data set, and 2) executing an ATM transaction using the mobile-wallet data set. Embodiments are generally described in the context of computer-readable logic executed by one or more general-purpose computers. For example, in a portion of an embodiment, computer readable logic is stored on a server computer system and accessed by a client computer via a communications link or a network, such as an intranet, Internet, virtual private network, or another computer network. And because the basic structures and functions related to computer-readable routines and corresponding implementations are known, they have not been shown or described in detail below to avoid unnecessarily obscuring the described embodiments. 
         [0009]    Details are set forth in the following description and in  FIGS. 1-4  to provide a thorough understanding of various embodiments of the invention. Those of ordinary skill in the art will understand that the invention may have additional embodiments that may be practiced without several of the details described below. In some instances, persons of ordinary skill in the art will appreciate that the methods and systems described herein can include additional details without departing from the spirit or scope of the disclosed embodiments. Additionally, some known structures and systems associated with automated teller machines (ATMs), mobile devices, and associated computer networks have not been shown or described in detail below to avoid unnecessarily obscuring the described embodiments. 
         [0010]    In the following figures, identical reference numbers identify identical or at least generally similar elements. In the flow diagrams, a rectangle represents a process, task, action, or operation; a diamond presents a question; and a parallelogram shows input or output. 
         [0011]      FIG. 1  is a flow diagram showing an embodiment of how a user can create mobile-wallet data set  16  by using personal computing device  4 , e.g., a computing tablet or mobile phone, to input a plurality of required data sets that together make up mobile-wallet data set  16 . Mobile-wallet data set  16  is a collection of one or more electronic data sets that may include at least one personal debit-card data set  18 , e.g., a data set that provides debit-card number, CVV number, and expiration-date information, and at least one personal-information data set  20 , e.g., cardholder name. In an embodiment, mobile-wallet data set  16  may include a data set associated with a credit or debit card distinct from personal debit-card data set  18  mentioned above. Block  100  shows a user being prompted to create mobile-wallet data set  16  by using personal computing device  4  to input a plurality of data sets that include 1) personal debit-card data set  18 , and 2) personal-information data set  20 , shown respectively in blocks  100 A and  100 B. In decision block  102 , the user is shown as having to decide whether to input the prompted data sets, i.e., personal debit-card data set  18  and personal-information data set  20 . Block  104  shows the user inputting the requested data sets by populating the data fields prompted to the user; these combined requested data sets make up mobile-wallet data set  16 . In response to populating the prompted data fields, block  106  shows computing device  4  sending mobile-wallet data set  16  to server  6  that then forwards mobile-wallet data set  16  to mobile-wallet server  8  for hosting. 
         [0012]    In an embodiment, personal computing device  4  sends mobile-wallet data set  16  to server  6  that then forwards mobile-wallet data set  16  to server  8  for hosting. In another embodiment, computing device  4  sends mobile-wallet data set  16  to server  6  that executes an algorithm on at least a portion of mobile-wallet data set  16  and thereby determines the appropriate host-server destination for mobile-wallet data set  16 . In response to reaching this algorithm-driven-host-server-destination determination, mobile-wallet data set  16  is then forwarded from server  8  to the identified host-server destination from amongst a plurality of host servers. In an embodiment, server  6  may have a plurality of host-server destinations to select from, wherein the plurality of host-server destinations are specific as to the type of mobile-wallet data set  16  that they each respectively host. In other words, each host-server destination (i.e., host server) may respectively host different types of mobile-wallet data set(s)  16 . Mobile-wallet data set  16  may include data that the algorithm (performed on server  6 ) determines is associated with a specific banking institution, and in response to reaching this determination, causes mobile-wallet data set  16  to be forwarded from server  6  to the dedicated host server for that specific bank or bank data. As an illustrative example, mobile-wallet data set  16  relating to ABC bank is sent from server  6  to a host server dedicated to hosting ABC-bank mobile-wallet data sets; mobile-wallet data set  16  relating to DEF bank is sent from server  6  to a host server dedicated to hosting DEF-bank mobile-wallet data sets; mobile-wallet data set  16  relating to GHI bank is sent from server  6  to a host server dedicated to hosting GHI-bank mobile-wallet data sets; and so on. 
         [0013]      FIG. 2  illustrates an embodiment for pre-staging a cardless ATM transaction using personal computing device  4 . More specifically,  FIG. 2  illustrates a graphical-user-interface (GUI) flow diagram, depicted as it would be displayed on personal computing device  4 , for pre-staging an ATM transaction. 
         [0014]    In an embodiment, a mobile-cash-access app is lauched on personal computing device  4 , and “password/passcode” data-entry page  22  is displayed on personal computing device  4 &#39;s touchscreen GUI. In response to entering an acceptable password/passcode, “home” page  24  is subsequently displayed on personal computing device  4 &#39;s touchscreen GUI. In response to selecting “set up withdrawal” displayed on “home” page  24  on the touchsceen GUI, “accounts” page  26  is subsequently displayed on personal computing device  4 ′s touchscreen GUI. In response to selecting the card image on the touchscreen GUI that represents the account and desired mobile data set  16  to be used in the transaction, “PIN” page  28  is subsequently displayed on personal computing device  4 &#39;s touchscreen GUI. In response to entering the correct PIN associated with the account and desired mobile data set  16  to be used in the transaction, “cash amount” page  30  is subsequently displayed on personal computing device  4 &#39;s touchscreen GUI. In response to selecting a cash amount on personal computing device  4 &#39;s touchscreen GUI, pre-staging of the cardless ATM transaction using personal computing device  4  is complete. 
         [0015]      FIG. 3  illustrates an embodiment for performing a cardless ATM transaction using personal computing device  4  in coordination with ATM  2 . More specifically,  FIG. 3  illustrates a graphical-user-interface (GUI) flow diagram depicted as it would be displayed on personal computing device  4  at the time of performing a cardless ATM transaction using personal computing device  4  in coordination with ATM  2 . 
         [0016]    In an embodiment, “home screen”  24  is displayed on personal computing device  4 &#39;s touchscreen GUI. In response to selecting the “pay” button on “home screen” page  24 , “select queued transaction” page  34  is subsequently displayed on personal computing device  4 &#39;s touchscreen GUI. In response to selecting the desired queued transaction, “scan code” page  36  is subsequently displayed on personal computing device  4 &#39;s touchscreen GUI. In response to personal computing device  4  scanning the QR code displayed on ATM  2 &#39;s GUI interface, “transaction processing” page  38  is subsequently displayed on personal computing device  4 &#39;s touchscreen GUI. In response to the ATM transaction being complete, “transaction complete” page  40  is subsequently displayed on personal computing device  4 &#39;s touchscreen GUI. 
         [0017]      FIG. 4  is a flow diagram showing a universal overview of an embodiment for performing a cardless ATM transaction. In  FIG. 4 , consumer uses the GUI interface of ATM  2  to initiate a cardless ATM transaction. ATM  2 , that is configured to receive and execute the “initiate-a-cardless-ATM-transaction” command, responds to the command by sending client request  101  to mobile-wallet server  8  (that hosts mobile-wallet data set  16 ) via cloud server  6 . In response to receiving client request  101 , mobile-wallet server  8  generates and sends a token, e.g. a QR code, response  102  back to ATM  2  via cloud server  6  using a virtual-private-network (VPN) connection. In response to receiving the token/QR code back from server  8 , ATM  2  displays the token/QR code on its GUI interface to be scanned by personal computing device  4 . Consumer opens mobile-cash-access app on personal computing device  4  and captures the token by scanning the token displayed on ATM  2 &#39;s GUI interface. Capturing of the token by personal computing device  4  is shown as data transfer  103 . In response to personal computing device  4  capturing the token, personal computing device  4  subsequently sends token data, that includes at least a portion of mobile-wallet data set  16 , to both mobile-wallet server  8  and PIN authentication engine server  10  (via server  6 ); these data transfers are shown as  104   a  and  104   b  respectively. 
         [0018]    Regarding data-transfer  104   a,  in response to receiving token-data transfer  104   a,  mobile-wallet server  8  executes an algorithm that i) validates the authenticity of personal computing device  4 , ii) validates the authenticity of the mobile-cash-access app running on personal computing device  4 , iii) validates the app passcode entered by the consumer, and iv) validates the token. In response to validating these items, mobile-wallet server  8  sends available consumer financial accounts to personal computing device  4  shown as data transfer  110 . In response to receiving available consumer financial accounts, personal computing device  4  displays the available consumer financial accounts on the GUI of personal computing device  4 ; an illustrative embodiment of this is shown on webpage  26  of  FIG. 2 . Consumer then selects a consumer financial account from those displayed on personal computing device  4 . In an embodiment, the amount of the transaction is not pre-staged and the amount of the transaction must be entered into either ATM  2  or personal computing device  4 . 
         [0019]    Regarding data transfer  104   b  from personal computing device  4  to PIN authentication engine server  10 , in response to receiving data transfer  104   b,  PIN authentication engine server  10  then forwards at least a portion of data transfer  104   b  to EFT network and issuer for PIN authentication purposes. In an alternate embodiment, in addition to receiving token-data transfer  104   b,  an embodiment has PIN authentication engine server  10  also receiving the consumer&#39;s PIN data entry that has been entered by the consumer into ATM  2  or personal computing device  4 . 
         [0020]    Data transfer  105  represents the i) card number, ii) PIN, and iii) transaction data set being sent from ATM  2  to EFT network  14  via ATM driver  12 . Data transfer  105  is sent to EFT network in order to receive authorization to execute the transaction. Upon authorizing the transaction (based at least in part on the data provided by data transfer  104   b ), EFT network  14  sends authorization data set  106  to ATM  2  via ATM driver  12 . The transaction is then authorized and settlement occurs as is commonly known in the ATM industry and is represented as data transfer  107 . A digital receipt is then delivered to personal computing device  2  from cloud server  6  as shown by data transfer  108 . 
         [0021]    Persons of ordinary skill in the art will appreciate that changes could be made to the embodiments described above without departing from the broad inventive concepts thereof. It is to be understood, therefore, that this invention is not limited to the particular embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the appended claims.