Abstract:
An electronic funds system, including a plurality of payment devices, each payment device including a payment application for (i) transferring funds to another payment device, (ii) receiving funds from another payment device, and (iii) synchronizing transactions with a bank server computer, a queue manager for queuing transactions for synchronization with the bank server computer, an encoder for encrypting transaction information, a proximity communication module for wirelessly communicating with another of the plurality of payment devices over a short range, a wireless communication module for communicating with a client computer and with the bank server computer over a long range, a plurality of client computers, each client computer including a payment device manager for (i) transmitting funds to a payment device, (ii) receiving funds from a payment device, and (iii) setting payment device parameters, and a wireless communication module for communicating with at least one of the plurality of payment devices and with a bank server computer over a long range, and at least one bank server computer, each bank server computer including an account manager for (i) managing at least one bank account associated with at least one of the payment devices, and (ii) processing transactions received from the plurality of payment devices, a decoder for decrypting encrypted transaction information, and a wireless communication module for communicating with the plurality of payment devices and with the plurality of client computers over a long range. A method and a computer-readable storage medium are also described and claimed.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates to computerized banking and payment systems. 
       BACKGROUND OF THE INVENTION 
       [0002]    Conventional methods of making payments include paying with cash, paying by personal check, paying by bank check, paying by bank transfer and paying by credit card. Each of these methods has its drawbacks. 
         [0003]    Cash can be lost or stolen. A person may find himself “short” on cash. Cash has to be converted to local currency in foreign countries. 
         [0004]    Personal checks can be forged. Many merchants do not accept checks. Checks may not be honored. Checks must be deposited in a bank, after which there is a waiting period before the funds are available. Processing personal checks includes a heavy overhead of copying every check to microfilm for archival. 
         [0005]    Bank checks are burdensome. A person has to physically go to his bank to get a bank check, and he has to know the exact amount of the payment for which the bank check is intended. 
         [0006]    Bank transfers are also burdensome. A person has to issue explicit instructions to his bank to make a transfer. While this is worth the effort for scheduled payments to vendors such as credit card companies, utility companies, suppliers, tax authorities and department stores, it would require substantial time and effort to use bank transfers for day to day non-scheduled payments. 
         [0007]    Credit cards are vulnerable. There is substantial use of stolen credit cards or stolen credit card numbers, which has cost consumers and the credit card companies billions of dollars. Credit cards have to be sent in the mail. Merchants may neglect to verify credit card validity or overdrawn credit limits. Merchants may have to refuse a sale because their point-of-sale terminal is not currently able to connect to a credit card company for authorization. Not all merchants around the world accept credit cards. Credit cards can only be used for paying merchants, and cannot be used for transferring funds from individual to individual. 
         [0008]    Recently, the advent of microchips has made it possible to incorporate a small microprocessor chip and non-volatile memory onto a card, referred to as a “smart card”. Smart cards are currently able to function as cash accounts and to provide secure authentication with merchant point-of-sale terminals. However, smart cards also have their drawbacks. Smart cards can run out of money. Smart cards can only be replenished by replacing the cards, or by passing the cards through bank machines. Smart cards, like credit cards, cannot be used for transferring funds from individual to individual. 
       SUMMARY OF THE DESCRIPTION 
       [0009]    The present invention concerns computerized banking, payment systems and digital cash. The present invention includes a small, forgery-resistant device, referred to as a “payment device”, which is personalized so that only its rightful owner may use it. A payment device is associated with one or more bank accounts belonging to its owner. 
         [0010]    After being authenticated by his payment device, the owner may identify himself via the payment device to an external system, including a merchant&#39;s point-of-sale terminal or a bank&#39;s electronic funds transfer system or another payment device, and then perform a financial transaction. User identification is such that only selected credentials are released, without releasing any unrelated owner information. 
         [0011]    The payment device of the present invention includes data processing and data storage capability, which the owner may use to maintain personal and financial data. The payment device protects its owner&#39;s data by cryptographic security, and the data can only be accessed by a properly authorized financial institution or the rightful owner himself. The payment device uses a secure communication protocol and, as such, data transmitted by the payment device over a communication link cannot be eavesdropped. Moreover, an identity of the device owner cannot be determined from his transaction data. It may thus be appreciated that the payment device provides maximum protection of privacy. 
         [0012]    The payment device of the present invention is particularly advantageous in performing person-to-person funds transfer. A first owner can perform a payment transaction to a second owner via the owners&#39; respective payment devices. The payment transaction is encrypted, and can only be decrypted by a bank computer that manages the owners&#39; respective bank accounts and that commits the transaction between the accounts. 
         [0013]    There is thus provided in accordance with an embodiment of the present invention an electronic funds system, including a plurality of payment devices, each payment device including a payment application for (i) transferring funds to another payment device, (ii) receiving funds from another payment device, and (iii) synchronizing transactions with a bank server computer, a queue manager for queuing transactions for synchronization with the bank server computer, an encoder for encrypting transaction information, a proximity communication module for wirelessly communicating with another of the plurality of payment devices over a short range, a wireless communication module for communicating with a client computer and with the bank server computer over a long range, a plurality of client computers, each client computer including a payment device manager for (i) transmitting funds to a payment device, (ii) receiving funds from a payment device, and (iii) setting payment device parameters, and a wireless communication module for communicating with at least one of the plurality of payment devices and with a bank server computer over a long range, and at least one bank server computer, each bank server computer including an account manager for (i) managing at least one bank account associated with at least one of the payment devices, and (ii) processing transactions received from the plurality of payment devices, a decoder for decrypting encrypted transaction information, and a wireless communication module for communicating with the plurality of payment devices and with the plurality of client computers over a long range. 
         [0014]    There is moreover provided in accordance with an embodiment of the present invention a mobile wireless communication device for transferring money between users, including a receiver for receiving instructions to transfer money from a second user to a first user, a transmitter for sending instructions to transfer money from the first user to the second user, an instruction formatter for formatting and encrypting an instruction to transfer money, the instruction including at least a transaction identifier, a source account identifier, a destination account identifier, a date of transfer, and an amount to be transferred; and a synchronizer for queuing received instructions and for sending the queued instructions to a bank computer when communication with the bank computer is available. 
         [0015]    There is further provided in accordance with an embodiment of the present invention a method for transferring money between users, including receiving instructions to transfer money from a second user to a first user, where an instruction includes at least a transaction identifier, a source account identifier, a destination account identifier, a date of transfer, and an amount to be transferred, queuing the received instructions, sending the queued instructions to a bank computer when communication with the bank computer is available, encrypting instructions to transfer money from the first user to the second user, and sending the encrypted instructions to the second user. 
         [0016]    There is yet further provided in accordance with an embodiment of the present invention a computer readable storage medium storing program code for causing a computing device to receive instructions to transfer money from a second user to a first user, where an instruction includes at least a transaction identifier, a source account identifier, a destination account identifier, a date of transfer, and an amount to be transferred, to queue the received instructions, to send the queued instructions to a bank computer when communication with the bank computer is available, to encrypt instructions to transfer money from the first user to the second user, and to send the encrypted instructions to the second user. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0017]    The present invention will be more fully understood and appreciated from the following detailed description, taken in conjunction with the drawings in which: 
           [0018]      FIG. 1  is a simplified block diagram of mobile wireless payment devices that transfer funds among users, in accordance with an embodiment of the present invention; 
           [0019]      FIG. 2  is a simplified block diagram of an account-to-account payment and management system, in accordance with an embodiment of the present invention; 
           [0020]      FIG. 3  is a simplified flowchart of a method for making a person-to-merchant payment transaction, in accordance with an embodiment of the present invention; 
           [0021]      FIG. 4  is a simplified flowchart of a method for making a person-to-person payment transaction, in accordance with an embodiment of the present invention; 
           [0022]      FIG. 5  is a simplified flowchart of a method for synchronizing a payment device with a bank account, in accordance with am embodiment of the present invention; and 
           [0023]      FIG. 6  is a simplified block diagram of a payment device, in accordance with an embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0024]    The present invention relates to computerized banking and digital funds. 
         [0025]    In accordance with the present invention, users have financial accounts that are controlled by one or more banks. Users have wireless access to at least one cash account via a hardware unit referred to hereinbelow as a “payment device”. The present invention does not require a live connection between a payment device and a bank. Instead, a user periodically synchronizes his payment device with his bank. 
         [0026]    Reference is now made to  FIG. 1 , which is a simplified block diagram of mobile wireless payment devices that transfer funds among users, in accordance with an embodiment of the present invention. Shown in  FIG. 1  is a bank server computer  110 , which manages user accounts, and three mobile wireless payment devices  120 ,  130  and  140  belonging to user A, user B and user C, respectively. Payment devices  120 ,  130  and  140  are operative (i) to transfer funds between two users, and (ii) to synchronize the funds transfers with the users&#39; bank accounts via bank computer  110 . Moreover, as distinct from cards, the payment devices of the present invention transfer funds between two users whether or not the users&#39; payment devices are currently in communication with bank computer  110 . The funds transfer transaction does not have to be immediately authorized. Instead, the transaction is queued and is subsequently synchronized with the relevant bank accounts. 
         [0027]    It will be appreciated that bank server computer  110  may be a plurality of computers, associated with one or more banks. That is, users A, B and C may have their accounts at the same bank or at different banks. Generally, each bank is uniquely identified by a specific bank routing number, and each user account is uniquely identified by a specific account number within a specific bank. 
         [0028]    Reference is now made to  FIG. 2 , which is a simplified block diagram of an account-to-account payment and management system, in accordance with an embodiment of the present invention. Shown in  FIG. 2  is a bank server computer  210  and two payment devices, A and B, designated by numerals  220  and  230 , respectively, and belonging to respective users A and B. 
         [0029]    Bank server computer  210  includes an account manager  215 , for managing a plurality of user bank accounts, including inter alia bank accounts of user A and user B. Account manager  215  is able to receive an encrypted transaction in the form of a funds transfer from one user&#39;s account to another, execute or decline the transaction as appropriate, and return an acknowledgement of success or failure. Account manager  215  also enables a payment device to access account details including inter alia an account balance and a transaction history. 
         [0030]    Payment devices A and B include respective payment applications  225  and  235 , used to transfer funds between a payment device and a bank account, and between one payment device and another payment device. Also shown in  FIG. 2  are client computers A and B, designated by numerals  240  and  250 , respectively, and belonging to users A and B, respectively. Client computers A and B include respective payment device managers  245  and  255 , respectively. 
         [0031]    When a user&#39;s payment device is in communication with the user&#39;s computer, the user can set his device parameters, and can upload and download data between the device and the computer. Device parameters include, inter alia, a password, a daily cash limit, a daily number of transactions limit and text descriptors. Data uploaded from the device to the computer includes inter alia recent transactions. 
         [0032]    When a user&#39;s payment device is in communication with bank server computer  210 , the user&#39;s queued transactions are committed, and the user can retrieve his account information including inter alia his current balance, a list of his recent transactions, and his current daily limits on cash transfer and number of transactions. 
         [0033]    When a user&#39;s computer is in communication with bank server computer  210 , the user can upload and download data between his computer and bank computer  210 . Data downloaded from bank computer  210  includes inter alia an account summary and recent transactions. 
         [0034]    Reference is now made to  FIG. 3 , which is a simplified flowchart of a method for making a person-to-merchant payment transaction, in accordance with an embodiment of the present invention. The flowchart of  FIG. 3  is divided into three horizontal sections. The top section indicates steps performed by a user. The middle section indicates steps performed by the user&#39;s payment device. The bottom section indicates steps performed by a bank server computer. 
         [0035]    To perform a person-to-merchant transaction, the user initiates a transaction by either activating a “pay” function on his payment device at step  305 , or by waving his payment device in close proximity to the merchant&#39;s payment device at step  310 . Once the user&#39;s and merchant&#39;s payment devices are in communication, the devices perform a handshake operation to verify that the one is authorized to send money and the second is authorized to receive money. If the handshake is successful, then a payment application is launched on both payment devices and a transaction is initiated. The merchant&#39;s payment device wirelessly transmits merchant identification to the user&#39;s payment device. Alternatively, the user&#39;s payment device may have the merchant identification already stored, in which case the user&#39;s payment device need only bring up the stored merchant information. 
         [0036]    At step  315  the user enters the payment amount he wishes to pay to the merchant, and a scheduled date of payment, into his payment device. The user is asked to confirm the transfer. In order to perform step  315 , the user may first have to authenticate himself to the payment application by typing a password, or by having a biometric scan, or both. 
         [0037]    At step  320  the payment device encrypts the transaction information using an asymmetric encryption algorithm, such as RSA encryption, using a pre-stored encryption key. At step  330  the payment device determines whether or not it has a communication connection with the bank server computer. If not, then the transaction is queued for synchronization with the bank at step  335 . If the payment device does have a communication connection with the bank server computer, then at step  340  the payment device sends the transaction information to the bank server computer. 
         [0038]    At step  345  the bank server computer receives the transaction information from the payment device, and decrypts the information. At step  350  the bank computer validates and commits the transaction as appropriate. Specifically, if the user&#39;s bank account and payment device are currently valid, if there are no data transmission errors, if the transaction is authenticated, and if the user has sufficient funds in his bank account, then the transaction is committed. Otherwise, the transaction is declined. At step  355  the bank server computer notifies the user that his transaction was successful or unsuccessful, as appropriate. If the transaction was declined, then the bank server computer may advise the user as to the reason for denial and what course of action to follow. Optionally, the user&#39;s payment device may be configured to send a text message to an Internet address designated by the user. The text messages enable the user to track his purchases and to be aware if there is fraudulent use of his payment device. 
         [0039]    Generally there are at least two levels of authentication; namely, (i) authentication of a payment device into its wireless network to ensure that it is the device making the transaction, that it is authorized and that its payments are current, and (ii) authentication of a user to a payment application. Level (i) authentication is performed by having the payment device authenticate itself to a wireless carrier. 
         [0040]    Level (ii) authentication is performed by personalizing a payment device so that its rightful owner, and only its rightful owner, is granted access to the information and accounts controlled by the payment device. Such authentication may be implemented inter alia by a username/password combination, or by biometric authentication, or both. 
         [0041]    In accordance with an embodiment of the present invention, when a user receives his payment device initially from his bank, the user is given a password, which serves as an access code. As a default, the access code is required for any transaction; however, the user may change the default settings so that he is only required to enter his access code when a transaction exceeds a preset amount, such as $100, or when the user hasn&#39;t authenticated himself for over a preset time interval such as 1 hour. 
         [0042]    Reference is now made to  FIG. 4 , which is a simplified flowchart of a method for making a person-to-person payment transaction, in accordance with an embodiment of the present invention. Specifically, the method illustrated involves a first user, referred to as a transaction initiator, who pays a second user, referred to as a transaction recipient. The flowchart of  FIG. 4  is divided into four horizontal sections. The topmost section indicates steps performed by the transaction initiator. The section second from the top indicates steps performed by the initiator&#39;s payment device. The section third from the top indicates steps performed by the recipient&#39;s payment device. The bottommost section indicates steps performed by a bank server computer. 
         [0043]    As above with respect to  FIG. 3 , to initiate the transaction, the initiator either activates a “pay” function at step  405 , or else waves his payment device into close proximity with the recipient&#39;s payment device at step  410 . Once the initiator&#39;s and recipient&#39;s payment devices are in communication, the devices perform a handshake operation to verify that the one is authorized to send money and the second is authorized to receive money. If the handshake is successful, then a payment application is launched on both payment devices and a transaction is initiated. The recipient&#39;s payment device wirelessly transmits recipient identification to the user&#39;s payment device. Alternatively, the user&#39;s payment device may have the recipient identification already stored, in which case the user&#39;s payment device need only bring up the stored recipient information. 
         [0044]    At step  415  the initiator enters a payment amount and a date for scheduling the payment into his payment device. As above with respect to  FIG. 3 , in order to perform step  415 , the user may first have to authenticate himself to the payment application by typing a password, or by having a biometric scan, or both. 
         [0045]    At step  420  the initiator&#39;s payment device encrypts the transaction information using an asymmetric encryption algorithm, such as RSA. At step  425  the initiator&#39;s payment device sends the transaction information to the recipient&#39;s payment device. 
         [0046]    At step  430  the recipient&#39;s payment device determines whether or not it has a communication connection with the bank server computer. If not, then at step  435  the recipient&#39;s payment device queues the transaction for subsequent validation and processing. If the recipient&#39;s payment device does have a communication connection with the bank server computer, then at step  440  the recipient&#39;s payment device sends the transaction information to the bank server computer for validation and processing. 
         [0047]    When the bank server computer receives the transaction information from the recipient&#39;s payment device, either when the recipient payment device is connected to the bank server computer subsequent to step  435 , or immediately after step  440 , the bank server computer decrypts the transaction information at step  445 . At step  450  the bank server computer validates and commits the transaction as appropriate. Specifically, if the initiator&#39;s and the recipient&#39;s bank accounts and payment devices are current, if the transaction is authenticated, and if the initiator has sufficient funds in his account, then the transaction is committed. Otherwise, the transaction is declined. At step  455  the bank server computer notifies the recipient that the transaction was successful or unsuccessful, as appropriate. 
         [0048]    In comparing  FIG. 4  with  FIG. 5 , it is noted that if the recipient is a merchant, the transaction is sent to the initiator&#39;s bank; whereas if the recipient is an individual the transaction is sent to the recipient. The recipient is thus assured that the transaction has occurred. The recipient subsequently sends the transaction to the recipient&#39;s bank, where the transaction is decrypted and committed. In both  FIG. 4  and  FIG. 5 , if there is no available connection at the time of the transaction, then the transaction is queued for subsequent synchronization. 
         [0049]    Reference is now made to  FIG. 5 , which is a simplified flowchart of a method for synchronizing a payment device with a bank account, in accordance with am embodiment of the present invention. The flowchart of  FIG. 5  is divided into two horizontal sections. The top section indicates steps performed by a user. The middle section indicates steps performed by a user&#39;s payment device. The bottom section indicates steps performed by a bank server computer. 
         [0050]    The method of  FIG. 5  is initiated when a user&#39;s payment device is synchronized with his bank account, such as after step  340  of  FIG. 4 . The user may manually initiate the synchronization, as indicated at step  510 , by the user activating a “synchronize” function while his payment device is connected to the bank server computer. Alternatively, a payment application running in the payment device may automatically attempt to synchronize, as indicated at step  520 ; or both manual and automated synchronization may be operative. The user&#39;s payment device initiates an Internet connection and sends the user&#39;s account information to the bank server computer. The bank server computer may require authentication prior to permitting synchronization, e.g., by issuing a challenge question to the user. If the user correctly answers the question, then synchronization proceeds. Otherwise, the user&#39;s account is frozen and a notification is sent to the payment device advising the user of such. Authentication may be required whenever the user&#39;s account is on alert, such as when suspicious activity is detected. 
         [0051]    At step  530 , the user&#39;s payment device then sends its queued transactions to the bank server computer. At step  540  the bank server computer receives and performs the user&#39;s queued transactions as appropriate. At step  550  the bank server computer sends acknowledgements for queued transactions that were successful and error notifications for queued transaction that were declined. At step  560  the bank server computer sends the user&#39;s updated account information to his payment device. 
         [0052]    Reference is now made to  FIG. 6 , which is a simplified block diagram of a payment device  600 , in accordance with an embodiment of the present invention. Payment device  600  is embodied within a smart phone or as a PDA, or such other conventional or custom hardware device. Included within device  600  is a CPU processor  605  and an operating system  610 . When payment device  600  is part of a smart phone or PDA, CPU  605  may be the smart phone processor or PDA processor, respectively. Alternatively, CPU  605  may be embedded within a SIM chip or such other conventional or custom processing unit. 
         [0053]    For user input, payment device  600  may include various buttons and jog wheels, as well as a keyboard  615 . For user output, payment device  600  may include a display screen  620 . 
         [0054]    Payment device  600  is able to communicate wirelessly with another payment device when the devices are in close proximity to one another, using a proximity communication module  625 . Module  625  may use Bluetooth, Near-Field Communication, Radio Frequency Identification communication, infra-red communication, or such other wireless communication technology that operates over short ranges on the order of 1 meter. 
         [0055]    Payment device  600  is also able to communicate wirelessly with one or more bank server computers, using a wireless communication module  630 . Wireless communication module  630  also enables payment device  600  to communicate with electronic funds transfer (EFT) systems. 
         [0056]    Processor  600  includes a payment application  635 , used for generating and performing transactions, including inter alia the transactions illustrated in  FIGS. 3-5 . Payment application  635  reads and writes its owner&#39;s personal and financial data, stored in a data store  640 , and sends and receives transactions to other payment devices via proximity communication module  625 . Payment application  635  synchronizes its transactions with one or more bank server computers and with EFT systems, via wireless communication module  630 . 
         [0057]    Payment device  600  further includes an authenticator  645  for validating a user. Authenticator  645  operates by validating a password entered by the user, or by recognizing a biometric of the user, or both. 
         [0058]    Processor  600  also includes an encoder  650  for encrypting transaction information, and a data storage  655  of encryption keys. 
         [0059]    In addition to functioning as a funds transfer tool, payment device  600  supports offline user services that are not part of a transaction, and are available to a user at any time. Such services include inter alia generating transaction lists, reporting available balances, and tracking expenses. The payment device enables a user to categorize expenses, and to export this information to a data file or to a financial application such as Quicken. 
         [0060]    In reading the above description, persons skilled in the art will realize that there are many apparent variations that can be applied to the methods and systems described. Thus it may be appreciated that the present invention applies to configurations where each user may have multiple payment devices, where each payment device may be associated with one or more bank accounts managed by one or more banks. For payment devices associated with more than one bank account, a user is able to select which bank account it to be used for payment transactions, and to change his selection from time to time. It will be appreciated that such a mechanism enables a single payment device to function as multiple credit cards. 
         [0061]    In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made to the specific exemplary embodiments without departing from the broader spirit and scope of the invention as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.