WO2004031908A2

WO2004031908A2 - Method and system for secure person to person payment

Info

Publication number: WO2004031908A2
Application number: PCT/US2003/030900
Authority: WO
Inventors: David John Liu
Original assignee: Rysix Holdings, Llc
Priority date: 2002-10-01
Filing date: 2003-10-01
Publication date: 2004-04-15
Also published as: AU2003277132A8; AU2003277132A1; WO2004031908A3; WO2004031908A9

Abstract

The invention relates to a method and system for enabling an interparty payment. A request for payment is sent by a payee, including an account number and personal identification number (PIN) for a credit account, to a host computer. In response, the host computer generates a transaction reference that indexes a payment amount and the credit account into which the payment amount is to be credited. The transaction reference is forwarded through the payee to a payer. The payer then provides the host computer with payment information comprising the transaction reference and a debit account with authentication token, such as a PIN, from which the payment amount is to be taken. The host computer, using a bank financial network, transfers the payment amount from the debit account to the credit account to complete the interparty payment. The payer and/or payee are then optionally sent payment receipts by the host computer.

Description

METHOD OF AND SYSTEM FOR SECURE PERSON TO PERSON PAYMENT

FIELD OF THE INVENTION

The present invention relates to the field of money transfer between the account of one person or entity and the account of another person or entity. More particularly, the present invention relates to a method and system for the transfer of money from a payer to a payee, securely and instantly without exchanging account data between the parties to the transfer.

BACKGROUND OF THE INVENTION

As the financial needs of the general population evolve, there is a demand to improve the way a payment may be transferred from one person to another. The traditional method of payment using cash provides a minimal transfer of information between the payer and payee, yet is not practical in many ways. Cash can be easily lost or stolen, at which time it may be difficult to find or replace. Payment by cash on a regular basis also leads to an exhaustion of the payer's cash supply, which in turn requires repeated trips to a bank or other cash source to replenish the supply.

On the payee's side, a large number of payers using cash lead to an accumulation of cash. Such an accumulation must be protected from theft and deposited into the payee's bank account at regular intervals. Cash transactions create other problems, as well. For example, a payee accepting cash payments must keep additional cash on hand to make change when a payer uses relatively large denomination bills and does not tender exact change. This requirement causes additional accounting overhead to a typical payee, as well as necessitating closer scrutiny of employees and customers for potential theft. While payment by check alleviates some of the problems of using cash, it creates other problems. A check is generally not guaranteed unless the payer goes the length of giving a bank check or a money order. This is not a practical solution for many payers, particularly those with a large volume of payees to pay. It is also often expensive to purchase bank checks or money orders.

Payment by check also provides the payee, as well as any subsequent endorsers, information regarding the account on which the check is drawn. For example, the bank and account number is normally printed on a check. A payer may not want the payee and others to have this additional information. Moreover, checks often contain other information, such as the payer's name, address and telephone number. In many instances, the tendering of a check by a payer elicits a demand by the payee for the payer's driver's license or other identification information. Clearly, the use of checks for payment includes many serious negatives. Another method of transferring funds from a payer to a payee is for the payer to wire the funds into the payee's account, either from the payer's account or by a service that accepts cash or other payment and then sends the funds to a payee (such as Western Union®). Wiring funds usually requires that the payer visit a bank and pay a fee, which may be substantial. It also normally requires that the payer have knowledge of the payee's account number, so as to enable the transfer. This is information that the payee may not want to disclose.

None of these methods result in a real time credit to a payee's account. Moreover, the payer's account is not debited in real time. These methods thus may entail inconvenient delays. For example, the payment of cash from a payer to a payee requires that the payer first go to a bank or other source of cash, withdraw funds from their account, go to the payee's location, transfer the cash and optionally receive change. The payee collects the cash, optionally pays out change, goes to their bank or place of deposit, and deposits the cash into their account. Each of these steps involve a potential delay. Accordingly, there is a need for a method of and system for transferring money from a payer account to a payee account, securely, which overcomes problems with the prior art. Moreover, there is a need for a method of and system for transferring money between a payer and a payee wherein account data of the parties is not shared between the parties and wherein the transfer is instantaneous or nearly instantaneous.

SUMMARY OF THE INVENTION

The purpose and advantages of the present invention will be set forth in and apparent from the description that follows, as well as will be learned by practice of the invention. Additional advantages of the invention will be realized and attained by the methods and systems particularly pointed out in the written description and claims hereof, as well as from the appended drawings.

To achieve these and other advantages and in accordance with the purpose of the invention, as embodied and described herein, the invention includes a method of interparty payment. A host computer generates a transaction reference that indexes a payment amount and a credit account into which the payment amount is to be credited in response to a request for payment by a payee. Next, the host computer forwards the transaction reference through the payee to a payer. The payer then forwards payment information comprising the transaction reference and a debit account from which the payment amount is to be taken to the host computer, which transfers the payment amount from the debit account to the credit account to complete the interparty payment.

In another embodiment, the host computer issues a transaction receipt to the payee, the payer, or both.

In yet another embodiment, the request for payment includes an account number and authentication information for the credit account. In another embodiment, the authentication information is a personal identification number (PIN).

In another embodiment, the payment information provided to the host computer by the payer includes an account number and authentication information for the debit account. In yet another embodiment, a request for credit is sent by the payee to the host computer, along with the amount, the transaction reference, and the authentication information for the credit account. The host computer then transfers the amount from the credit account to the debit account.

The invention also includes a system for interparty payment that includes a host computer in communication with a payer, a payee, and a bank financial network. The bank financial network includes a payee account and a payer account. The host computer is configured to generate, in response to a request for payment by a payee, a transaction reference that indexes a payment amount and a credit account into which the payment amount is to be credited. Next the host computer forwards the transaction reference through the payee to a payer. The payer then sends the host computer payment information comprising the transaction reference and a debit account together with authentication token (information) and a PIN from which the payment amount is to be taken. The host computer then transfers, by communication with a bank financial network, the payment amount from the debit account to the credit account to complete the interparty payment.

In another embodiment, the host computer is further configured to issue a transaction receipt to the payee, the payer, or both.

In yet another embodiment, the request for payment includes an account number and authentication information for the credit account, debit account, or both. In another embodiment, the system further includes a computer database into which the host computer is further configured to store the payer, the payer, the amount and the transaction information.

It is understood that both the foregoing general description and the following detailed description are exemplary and are intended to provide further explanation of the invention claimed.

The accompanying drawings, which are incorporated in and constitute part of this specification, are included to illustrate and provide a further understanding of the method and system of the invention. Together with the description, the drawings serve to explain the principles of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings:

Figure 1 is a block diagram of a person to person payment system in accordance with one embodiment of the present invention;

Figures 2(a) and 2(b) are flowcharts of the process of account registration by the payer and payee, respectively, in accordance with an embodiment of the present invention;

Figure 3 is a flowchart depicting the processing of a person to person payment by a payment manager, payer and payee in accordance with an embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

The following description is presented to enable any person of ordinary skill in the art to make and use the present invention. Various modifications to the preferred embodiment will be readily apparent to those of ordinary skill in the art, and the disclosure set forth herein may be applicable to other embodiments and applications without departing from the spirit and scope of the present invention and the claims hereto appended. Thus, the present invention is not intended to be limited to the embodiments described, but is to be accorded the broadest scope consistent with the disclosure set forth herein.

In accordance with the present invention, a system and method is provided for the transfer of money from a payer to a payee, securely and instantly without exchanging account data between the parties to the transfer. Advantageously, the system and method provides a minimal transfer of information between the payer and payee, yet does not incur the disadvantages of using cash. Thus, it does not require the payer carry a supply of cash, which might be lost or stolen. Also, the payee does not need to maintain a cash supply for making change, nor handle accumulations of cash by making bank deposits on a regular basis. Moreover, the payee has a reduction in their need to scrutinize employees due to the lack of available liquid currency exposed to internal theft.

The method and system of the present invention also has advantages over the use of checks in the prior art. The present invention does not communicate the payer's account number to the payee, as is typically done on the face of a check. Moreover, there is no longer a need for any of the payer's personal information to be communicated to the payee, as is normally the case when a payer uses a personal check to pay a payee. For example, most personal checks have the payer's name, address, account number, and the name of the bank on the face of the check. It is not unusual for a payer to provide a payee with additional information, such as the payer's telephone number, social security number, or driver's license number as an assurance to the payee that the check is valid. This additional assurance , and thus the additional information is not necessary using the present invention.

The present invention is additionally advantageous over the wiring of funds by a payer to a payee. Wiring funds requires that the payer travel to a location from which funds can be wired, such as a Western Union®, pay both the amount to wire and an additional fee, and provide the information of where to send the wire. This, in turn, requires either that the payee provide the payer with the payee's account information for wiring the funds to, or that the payee travel to a location, such as another Western Union®, to receive the funds so wired. The present invention forgoes the need for the payer to travel to travel, pay an additional fee, and provide payee account information, as well as the need for the payee to either travel or provide account information to collect the wired funds.

Another advantage of the present invention over other methods and systems of transferring a payment from a payer to a payee is that, unlike the prior art, the payment amount is debited from the payer account and credited to the payee account quickly, in real time. Other methods of transferring payment from a payer to a payee required further non-real time steps before the payer account was debited and the payee account could be credited. Referring to Figure 1, a person to person payment system and method in accordance with one embodiment of the present invention is shown.

The system includes a payer 2, payee 1, payment manager 3, payer account 4, and payee account 5. The payer account 4 is alternatively, but equivalently referred to herein as a debit account. Likewise, the payee account 5 is alternatively, but equivalently referred to herein as a credit account. The method of this embodiment may be used when a payer 2 decides to transfer funds from the payer's account 4 to a payee's account 5. For example, the payer 2 can be shopping in a retail establishment operated by the payee 1. When the payer 2 decides to purchase an item, the payer 2 informs the payee 1 that the payer 2 wants to transfer the purchase price from the payer's account 4 to the payee's account 5.

To begin the transfer, the payee 1 sends the payment manager 3 a payment request which includes the payee's account information 6. Any communications link may be used between the payee 1 and payment manager 3, including, but not limited to a telephone or cellular link, the Internet, or any other communications channel. Since the payee account information transferred generally includes confidential account information, it is preferable that the communications link employed be secure. This security can be achieved through a suitable combination of encryption of the data to be transferred with the choice of physical communications link. The payment request 6 includes information regarding the payee's account 5 to receive the transfer. This information includes the amount of money to transfer, and may also include an identification of the currency to be used. For example, a domestic system in the United States can default to the US dollar as the currency of exchange. To transfer other currency on the domestic system would require that an identification of the currency to transfer be provided, unless the transfer currency can be determined from the context of the transaction.

An important component of the payment request 6 is the information identifying the payee's account 5 to the payment manager 3. This identifying information includes the payee account number. In a preferred embodiment, the identifying information also includes the personal identification number (PIN) of the payee's account 5. Alternatives exist to allow the payee 1 to not have to send their account information and PIN directly to the payment manager 3 at the time of the transaction. For example, the payee 1 could have previously registered their payee account number and PIN with the payment manager. This information could then be indexed to an alternative registration number by the payment manager 3. It may even be accessed by the payee's telephone number using caller identification technology. Alternatively, if the payee 1 accesses the payment manager 3 over the Internet by logging into the payment manager 3 using a user id and password, the user id and password may be used by the payment manager 3 to index the payee's account information.

Whatever technique is used to transfer the payee's account information to the payment manager 3, the payment manager 3 then issues a transaction reference number 7 to the payee 1. The payment manager 3 will later use this reference number 7 to determine the amount to transfer and the account to transfer it to (the payee account 5). The payment manager should save the reference number 7, preferable in a database with the payee account information and the amount to transfer. This information may be indexed for easy access when needed.

The reference number generated by the payment manager is next sent to the payer by the payee 8. Communication between the payer and payee can be by any of several methods. For example, the payee may be a retail establishment and the payer may actually purchase an item at the retail establishment. In such a situation, the payer 2 and payee 1 may communicate verbally or in writing, or may use an electronic form of communication. As an example, the payee can print out the reference number and hand it to the payer. Next, the payer sends payer account information to the payment manager 9. This information should include the reference number the payer 2 received from the payee 1. Using this reference number, the payment manager 3 can determine the amount of the payment and the payee account 5 to transfer the payment to.

The payer 2 can send the payer account information and reference number to the payment manager 3 using any of several different methods. In a preferred embodiment the payer 2 has already registered the payer account 4 to be used by the payment manager 3 whenever the payer 2 authorizes such payment. The transfer 9 of payer account information and reference number by the payer 2 to the payment manager 3 can then be a accomplished without the payer 2 actually sending the payer account 4 number or its associated PIN. For example, if the payer 2 has previously registered a payer account number and PIN with the payment manager 3, and the payment manager 3 has provided the payer 2 with a login identification or account number and password, the payer could send their login identification and password together with the reference number. Upon receipt, the payment manager 3 could verify the payer login identification and password, and retrieve the transaction information using the reference number. Thus, no account information would necessarily be communicated at the time of the transaction.

Alternatively, in another embodiment, the payer and/or payee may choose not to register with the payment manager. In this instance, sufficient account information would need to be sent by the payer/payee to the payment manager to enable the payment manager to correctly identify and access the payer/payee account using a financial network.

Figures 2(a) and 2(b) are flowcharts of the process of account registration by the payer and payee, respectively, in accordance with an embodiment of the present invention.

In Figure 2(a), a payer first decides to begin the process of registering with a payment manager 20. The payer provides the payment manager with the payer account information 21. The payer can provide this information by any of several methods. For example, the payer can communicate their account information over an Internet web page maintained by the payment manager. In this case the payer could enter their account information onto an online form and send it to the payment manager via a secure encrypted web transfer. Numerous alternatives exist for encrypting information for communication over an Internet link.

Alternatively, the payer may fill in an actual form and send it to a payment manager through the mail system or another delivery service. Regardless of the method used to send the payer account information to the payment manager, the payer account information would include an identification of the payer, the payer account number, and the institution or bank where the payer account is held. The payer may also include the personal identification number ("PIN") for the account, although this is not strictly required.

Next, the payment manager issues a user identification and a password to the payer 22. From this point onward, the payer no longer needs to refer to the actual payer account number in communications with the payment manager. Instead, the payer uses the user identification/password combination issued by the payment manager. It should be noted that the choice of user identification and password does not necessarily have to be made by the payment manager. An alternative embodiment allows the payer to select a user identification and a password. In such an embodiment the user identification would be issued to the payer if it conforms to certain minimal standards, such as a length requirement, and if it is available (not being used by another user). Otherwise, the payment manager would either allow the payer to select another user identification or assign one by itself.

Similarly, a payer-selected password would need to satisfy certain minimal standards, such as length of the password. Usually, however, a given password may be used by several users at the same time without being a burden on security.

Once the payer has been assigned (or has selected) a user identification and password, the payment manager saves the payer account information, user identification and password 23. The payment manager may use any of several methods to save this information. A particularly useful and efficient method is to save the information into a relational computer database. Such a database may also be object-oriented. In a preferred embodiment, the database would also be indexed for fast and efficient database searches and other queries.

Many database hardware and software systems are commercially available which are capable of supporting the storage, indexing and retrieval demands of a preferred embodiment of the invention.

In Figure 2(b), a payee registers with the payment manager in a manner synonymous with the payer registration described above. After deciding to register 30, the payee provides account information to the payment manager 31. The payment manager 31 then issues a user identification and a password to the payee 32. The methodology employed by the payment manager in issuing the user identification and password to the payee may vary significantly from one embodiment to another. For example, in one embodiment, the payee selects their user identification, which is checked by the payment manager for uniqueness. Once the payee's user identification is selected in this embodiment of the invention, the payment manager sends a randomly-generated password to the payee. Alternatively, the payee may select their own password, adhering to a simple set of rules for password construction, such as a requirement that the password be alphanumeric and of at least 8 characters. These requirements are cited here for exemplary purposes, another embodiment of the invention may incorporate entirely different rules for password construction. Once generated, the payee's account information, user identification and password are saved 33 in a manner similar to the method used to save the payer's information.

Figure 3 is a flowchart depicting the processing of a person to person payment by a payment manager, payer and payee in accordance with an embodiment of the present invention. The payer and payee first determine to transfer funds from the payer to the payee 41. This decision may be the result of a retail sale, wherein the payee is a merchant and the payer is a customer. It may also, however, be due to any other transaction between a payer and payee resulting in a need to transfer funds from a payer to a payee. Next, the payee sends a payment request for the amount to transfer, along with the payee account information, to the payment manager 42. The payee account information includes all the information necessary to identify the account to the payment manager. If the payee has previously registered with the payment manager, the payee may only need to send their user identification and password in order for the payment manager to correctly identify the payee account. Otherwise, enough information needs to be sent by the payee to enable the payment manager to correctly identify and access the payee account.

The payee then verifies the payee account information, and, if verified, saves the payee account information, the amount, and a payment manager-generated transaction reference number 43. In a preferred embodiment, these items are saved in a computer database to allow for efficient indexed lookups and record-keeping. Alternatively, any method may be employed by the payment manager to save this information. If the payee account information is not verifiable, the process terminates without transferring any payment.

If the payee account information is verified, the payment manager sends the transaction reference number to the payee 44, who then sends it to the payer 45. It is only the transaction reference number that is passed to the payer, not payee account information, thus providing an added layer of security to the payee. The transfer of the transaction reference number to the payer may be by any method, including an electronic, written, or verbal transfer, as well as any other method. Next, the payer sends the payer account information and the transaction reference number to the payment manager 46. The payer account information, including the account number and any validation code, or personal identification code (PIN), may be explicitly sent in this step. If, however, the payer has previously registered with the payment authority, the payer would only need to send their user identification and password together with the transaction reference number to the payment manager. As is the case with the payee, the payer may communicate with the payment manager by any means, including over the Internet, over a telephone line, or using any other method. For example, a payer using the Internet to communicate in a preferred embodiment would enter their user identification, password, and the transaction reference number into a web page maintained by the payment manager. Alternatively, the payer might in another embodiment speak with an operator representative of the payment manager on a telephone and verbally communicate the payer's information and transaction reference number to the operator, who would then enter the data into the payment manager system.

However acquired, the payment manager then verifies the payer account information and the transaction reference number. If valid, the payment manager causes the amount of the transaction to be debited from the payer account and credited to the payee account 47. In invalid, the process is terminated without any transaction of funds taking place.

The payment manager accesses the payee and payer accounts by participating on a network for real-time financial transaction. The mechanism of interacting with such a network is well known to those skilled in the art. Typically, the procedure starts with establishing a connection to a remote computer operated by the network. The computer operated by the payment manager then authenticates itself to the network. After being admitted to the network, the payment manager then sends transaction requests for debit and credit, and receives results (approval or decline) of these transactions.

Once the accounts have been properly credited and debited, the payment manager issues transaction receipts to the payer and payee for their records 48. This step of issuing transaction receipts is not mandatory, and alternative embodiments of the payment manager can issue receipts to both, one or none of the payer and payee, as preferred.

If the payment manager issues one or more transaction receipts, the receipt(s) may take any of several forms, including an electronic receipt sent over a communications network or the Internet, a verbal receipt sent over a telephone connection, a paper receipt sent by mail, or any other form.

Thus, in accordance with the foregoing the objects of the present invention are achieved. Modifications to the foregoing would be obvious to those of ordinary skill in the art, but would not bring the invention so modified beyond the scope of the appended claims.

Claims

THE CLAIMSWhat is claimed is:

1. An interparty payment method comprising the steps of: generating, by a host computer in response to a request for payment by a payee, a transaction reference that indexes a payment amount and a credit account into which the payment amount is to be credited; forwarding from the host computer the transaction reference through the payee to a payer; providing to the host computer from the payer, payment information comprising the transaction reference and a debit account from which the payment amount is to be taken; and transferring, by the host computer, the payment amount from the debit account to the credit account to complete the interparty payment.

2. The method of claim 1 , further comprising the step of issuing, by the host computer, a transaction receipt to the payee, the payer, or both.

3. The method of claim 1 , wherein the request for payment includes an account number and authentication information for the credit account.

4. The method of claim 3, wherein the authentication information is a personal identification number.

5. The method of claim 1 , wherein the payment information provided to the host computer by the payer includes an account number and authentication information for the debit account.

6. The method of claim 5, wherein the authentication information is a PIN.

7. The method of claim 1, further comprising the steps of: authenticating the host computer with a bank financial network; communicating transaction reference information by the host computer to the bank financial network; and communicating validation information by the bank financial network in response to the host computer communication.

8. The method of claim 1, further comprising the step of: storing the payee, the payer, the amount and the transaction information in a computer database by the host computer.

9. The method of claim 8, further comprising the steps of: sending a request for credit, the amount, the transaction reference, and the authentication information for the credit account from the payee to the host computer; and transferring the payment from the debit account to the credit account by the host computer system.

10. The method of claim 9, wherein the transferring of the amount from the credit account to the debit account is done by the host computer using a bank financial network.

11. The method of claim 9, further comprising the step of issuing, by the host computer, a transaction receipt to the payee, the payer, or both.

12. The method of claim 1, wherein the sending of information between any of the payee, payer, and the host computer is performed over the Internet.

13. The method of claim 1 , wherein the payee has previously registered the credit account with the host computer, which has issued an credit account reference number to the payee, and all subsequent references to the credit account use the credit account reference number.

14. The method of claim 1 , wherein the sending of information between any of the payee, payer, and the host computer is performed over an automated telephone system interface.

15. A method of sending payment from a payer to a payee, the method comprising the steps of: sending a request for payment and an identification of a credit account from a payee to a host computer; sending a transaction reference generated by the host computer to the payee; sending the transaction reference by the payee to a payer; sending the transaction reference and an identification of a debit account from the payer to the host computer system; and transferring the payment from the debit account to the credit account by the host computer system.

16. The method of claim 15, further comprising the steps of: communication of account and payment information by the host computer system to a bank financial network; and communication of account credit and debit information from the bank financial network to the host computer system.

17. The method of claim 16, further comprising the steps of: sending a request for credit and a transaction reference from a payee to a host computer system, wherein the host computer system previously generated and stored the transaction reference, amount of transfer, payee, and payer information for a transaction; transferring the payment from the account of the payee to the account of a payer, the transfer based on the stored amount of transfer, payee and payer, by the host computer system.

18. The method of claim 17, further comprising sending a transaction receipt to the payer and payee by the host computer system.

19. An interparty payment method comprising the steps of: generating, by a host computer in response to a request for payment by a payee including an account number and personal identification number (PIN) for the credit account, a transaction reference that indexes a payment amount and a credit account into which the payment amount is to be credited; forwarding from the host computer the transaction reference through the payee to a payer; providing to the host computer from the payer, payment information comprising the transaction reference and a debit account from which the payment amount is to be taken; transferring, by the host computer using a bank financial network, the payment amount from the debit account to the credit account to complete the interparty payment; and issuing, by the host computer, a transaction receipt to the payee, the payer, or both

20. A system for interparty payment comprising: a host computer in communication with a payer, a payee, and a bank financial network; said bank financial network including a payee account and a payer account; said host computer configured to generate, in response to a request for payment by a payee, a transaction reference that indexes a payment amount and a credit account into which the payment amount is to be credited; forward the transaction reference through the payee to a payer; accept from the payer, payment information comprising the transaction reference and a debit account from which the payment amount is to be taken; and transfer, by communication with a bank financial network, the payment amount from the debit account to the credit account to complete the interparty payment.

21. The system of claim 20, wherein the host computer is further configured to issue a transaction receipt to the payee, the payer, or both.

22. The system of claim 20, wherein the request for payment includes an account number and authentication information for the credit account, debit account, or both.

23. The system of claim 22, wherein the authentication information for the credit account, debit account, or both is a personal identification number.

24. The system of claim 20, wherein the host computer is further configured to store the payer, the payer, the amount and the transaction information in a computer database.

25. The system of claim 20, wherein the host computer is furtlier configured to: accept a request for credit, the amount, the transaction reference, and the authentication information for the credit account from the payee; transfer the amount from the credit account to the debit account using the bank financial network.