WO2001048708A1

WO2001048708A1 - Computer methods and systems for repetitive payment applications

Info

Publication number: WO2001048708A1
Application number: PCT/IB2000/001972
Authority: WO
Inventors: On Hoter-Ishay
Original assignee: Takson Investments Ltd.
Priority date: 1999-12-28
Filing date: 2000-12-28
Publication date: 2001-07-05
Also published as: AU2538701A

Abstract

A computerized method of making repetitive payments without disclosing permanent financial information of customers to E-commerce vendors is provided. The method includes the steps of storing the name of a supplier to the request of a consumer asking to generate APRs, issuing the requested APRs, and storing the APRs and their value in computer memory. A database is provided to enter all or a combination of the following parameters for each APR: a specific supplier, any expiration date, any guarantee or any specific use. A system including computer electronics and software that implement the above method and other functionality is also provided.

Description

COMPUTER METHODS AND SYSTEMS FOR REPETITIVE PAYMENT APPLICATIONS

This is a Continuation- In-Part of Application No. 09/473,117, filed December 28, 1999, which is incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates to computer technology for payment applications including methods and systems for electronic payments in on-line commerce.

BACKGROUND OF THE INVENTION

It is well known to provide credit card information over the Internet or phone to merchants in order to purchase goods and services. ATM bank cards can be used for this purpose as well. Such known methods of payment create potential risks of unauthorized parties intercepting the credit card or bank account information during the transactions and fraudulently misusing this information. Communication systems, such as phone/fax lines and the Internet frequently provide unsatisfactory levels of security and therefore are vulnerable to fraud. Since credit and bank cards are usually associated with significant balances, such a misuse can significantly affect consumer's financial well being. 0

These potential risks associated with credit and bank card purchasing are magnified in the growing E-commerce, i.e., business transactions that take place over the

Internet. E-commerce companies may not provide sufficient security to ensure that the credit or bank card information is securely protected from unauthorized parties. There is ₅ also a possibility of fraud on the part of an Internet site offering goods or services. Consumers are more likely to commit themselves to e-commerce transactions that do not require sharing permanent personal financial information, e.g., a credit/bank card number, with E-commerce companies, which forces the consumer to face a potential risk of a significant loss or at least a substantial inconvenience in the event of o fraud. Therefore, it is desirable to provide a system and method that allow consumers to purchase goods and services repetitively over the Internet without using credit/bank card information or other general permanent financial information, thereby preventing fraud or misuse of such information.

SUMMARY OF THE INVENTION

Therefore, the preferred embodiments provide methods and systems that allow consumers to purchase goods and services by using a unique identifier reference, e.g., an Assigned Payment Reference (APR), associated with a specific supplier. In particular, a consumer wishing to purchase goods or services from a specific supplier first acquires an

APR, from a bank or another financial institute. Such an APR is associated with a specific supplier from which the consumer wishes to purchase repetitively and preferably with the customer's delivery address, without any time limit in making the purchases. An APR preferably may have a guaranteed payment amount, an expiration date, a usage limitation code, an upper limit amount and it may also have other associated conditions or restrictions.

A consumer can purchase goods and services from a specific supplier, e.g., an E-commerce vendor, by presenting his/her APR associated with the supplier preferably over the Internet or using other communication methods. After receiving such an APR, the supplier forwards it to the bank identified in the APR in order to authenticate it. The authentication process may involve approval or actual payment by the bank. Upon the authentication by the bank, the supplier proceeds to deliver goods or services purchased by the consumer. A salient feature of the present invention is that the supplier is not required to maintain any financial information about the customer. Instead, the bank identified in the APR keeps the necessary information to perform the authentication. It should be noted that the APR does not carry any financial information about its owner and, therefore, does not subject the customer to a possibility of a significant future loss by accidentally disclosing financial information of its owner which then can be misused. Additional security can be provided by further associating an APR to a specific delivery address to which the purchased goods and services are to be delivered. Thus, the preferred system provides a computerized method of making repetitive payments without disclosing general permanent financial information about customers. The method executed by the system includes the steps of associating the name of a specific supplier with an APR to be generated, issuing the requested APR, and storing the APRs and their information in computer memory, preferably using a database. The database stored in computer memory preferably includes all or a combination of the following parameters for each APR: a specific supplier, an expiration date, a specific delivery address, a guarantee of payment, and exemplary or a specific use. Multiple APRs each associated with a specific supplier can also be generated and issued to the consumer. As noted above, once a consumer receives an APR, he/she can present it to the associated supplier for purchasing of goods or services. Upon receiving the APRs, the supplier requests to release the amount of the purchase from the bank that issued the APR or another entity administering the APRs. This bank or entity may refuse to release the requested money and disapprove the request if the requested amount exceeds the upper limit value of the corresponding APR. After releasing the money, the corresponding customer account is updated by deducting the released amount from the customer's account balance.

As long as there are a sufficient balance remains in the customer's account, the APR can be used repeatedly.

Preferably, the system administering the APRs stores detailed information associated with each APR, which may include consumer's name, delivery address and the date on which the APR was were issued. Thus, preferably, the money is not released and the transaction is not approved if the detailed information received from an e-commerce vendor, who presented the APR, is not identical to the corresponding detailed information stored in the database.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram showing communication among various participants of the preferred payment system;

FIG. 2 is a block diagram of payment approval system;

FIG. 3 is an example of a printed Assigned Payment Reference ("APR"); FIG. 4 is an example of a printed list of APR' s of the exemplary embodiment;

FIG. 5 is an exemplary flow chart of the steps for approving a request; and FIG. 6 is an exemplary flow chart of the steps for making payments.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates three generalized participants of the preferred payment system: a payment maker (PMAK) 11, a payment receiver (PREC) 13, and a payment administrator (PADM) 15. The PMAK 11 is typically an individual consumer, but can also be a corporation or any other entity. The PREC 13 is an individual or a company that sells goods or services to consumers, businesses, or any other entities (e.g., an E-commerce company). The PADM 15 is a financial institution or a service organization that administers payment transactions.

The PADM 15 operates a payment administration system (PAS) 51, configured for example, as illustrated in FIG. 2. The PAS 51 is preferably a computer system that includes an input device 53, an output device 55, a processor 57 with associated software and a database 59. As understood by a person skilled in the art, the identified components are not required to be implemented as separate units, but can be combined in various ways and may include software and hardware. In general, preferably, PAS is implemented as a conventional computer server selected based on the desired performance as known in the art. Also, a network of computers and a special database server may be employed as known in the art.

The input device 53 is preferably a communication device that can receive electronic messages from remote locations. The input device 53 may also support a scanner with a text recognition system attached thereto, or a keyboard. The output device 55 is preferably a communication device that can forward messages to remote locations. The output device 55 may also support a printer. Preferably, the input and output devices provide communication over the Internet using a common communication protocol such as TCP IP and a common Web browser.

The processor 57 executes software 61 discussed in more detail subsequently. The preferred system can also include a database interface 63, an input interface 67, an output interface 69, and other software as known in the art. The preferred system can optionally include an encryptor 65. The processor 57 is preferably a microprocessor that can execute software modules. The encryptor 65 provides secure data encryption capabilities as known in the art. The input 67 and output 69 device interfaces support communication as known in the art. Other software, as known in the art, such as an operating system, runs on the PAS system. Preferably, the PAS system includes all conventional components of an Internet web server. It may, however, also support other communication and storage system capabilities, as known in the art, such as standard banking systems.

The PAS software modules can also be implemented in a server/client environment or in accordance with a distributed object system such as CORBA as known in the art. In an alternative embodiment, some software functionality can be implemented in an electronic device. For example, the encryptor can be implemented as an encrypting chip.

The database 59 can be implemented using conventional database management systems such as ORACLE^®, SYBASE^® or other similar products. Standard spread sheet software programs may also be used for the database 59. Furthermore, the database 59 can have more than one database to store customer information and APR related information in different databases.

One of the functions of the PAS 51 is to generate and issue one or more of Assigned Payment References (APRs). Each APR includes a unique identifier, e.g., a unique set of alphanumeric reference symbols, so that the APRs are individually identifiable within the relevant database. Moreover, each APR is associated with only one specific PREC. In other words, once an APR is associated with one PREC, no other PREC can use that APR to receive payments from the PADM. Furthermore, once an APR is associated with a specific delivery address, the purchased goods and services using such an APR can be delivered only to its associated delivery address. By specifying the delivery address, even if an APR is lost or stolen and, then, the APR is fraudulently used to purchase goods and services, the purchased goods and services would be delivered to the delivery address. This would diminish the desire to use an APR fraudulently. It should also be noted that an APR issued by one PADM can be paid by another PADM as long as the first and second PADMs share information on this APR.

The uniqueness of the stored APRs allows tracing and checking each APR. The length and complexity of the unique identifiers can vary for different implementations. An identifier for an issued APR is stored in the database 59 by the database interface 63. The uniqueness of the APRs is assured by the software running on the PAS. One way to generate a unique APR is to generate them randomly and then use only those that are not presently used. Other techniques can also be employed for this purpose as known in the art. The unique identifiers of the APRs can be encrypted by the encryptor 65.

In one preferred embodiment, the APRs are printed onto a form by the output device 55. In another preferred embodiment, the APRs are forwarded to the PMAK 11 electronically.

Additional information and parameters can be stored in the database 59 for each APR such as:

1. Upper limit amount associated with the APR;

2. Payment guarantee (this field indicates whether or not the APR was issued under a payment guarantee by the PMAK or PADM);

3. Expiration date of the APR;

4. Specific usage (this field indicates whether the APR can be used for only a specific purpose);

5. Accounting code for the PADM and/or PMAK; and

6. Identification of the PREC associated with the APR.

Referring back to FIG. 1, in operation, the PADM 15 first issues the APRs to the PMAK 11. APRs are issued according to PADM's business practices, as known in the credit card/bank card business. Before an APR is issued, the PAS associates the APR with a specific PMAK 11. When multiple APRs are issued to the PMAK 11 , each APR can be associated with different PRECs, all of them can be associated one specific PREC, or any combination of the above. Further, PAS sets the APR's expiration date, delivery address and determines if the APR is to have an upper limit, only specific usage, and other desired properties. The APR is then issued (e.g., printed or e-mailed) to the PMAK. It should be noted that the choice of associating a specific PREC and/or a delivery address with the APR and making the APR guaranteed, not guaranteed, single use, multiple use, expiring on a given date, having a specific usage as well as having a designated supplier are preferably all set by the PMAK. The guarantee can be made using an existing PMAK's line of credit, savings or checking accounts, or a credit card account with the PADM.

In one exemplary embodiment, a PADM is a retail bank. In this embodiment, an individual who is a customer of the bank is a PMAK, and an entity selling goods and services over the Internet, i.e., an E-commerce company, is a PREC. When the customer requests to generate one or more APRs, the PADM determines whether or not to issue requested APRs based on the relationship between PADM and PMAK, e.g., sufficient fund in an account of the PMAK in PADM. If the request is approved, the customer designates a specific PREC for each APR. After associating the APRs with the corresponding PRECs designated by PMAK, the APRs are forwarded to the customer. It should be noted that the APR can be forwarded via e-mail, mail, in person or using any other standard communication methods. It should be noted that APRs can also be issued by an Automatic Teller Machine (ATM) operated and maintained by the PMAK.

An example of printed APR, illustrated in FIG. 3, includes a unique reference number 71, a specific supplier's name 73, the customer's name 75 and an expiration date 77. This information is stored in the database for such an APR. The APR may also include a unique delivery address of the customer.

The PAS of this embodiment preferably stores all or a combination of the following information in its database: APR unique identifiers; customer's name, customer's delivery address upper limit amount, date issued, customer's account number, specifically associated E-commerce company's name, the E-commerce company's bank code, E-commerce company's bank account and customer's bank account number.

In one embodiment, the PAS can generate and forward an APR summary list to the customer. The list preferably includes APRs that have been generated for the customer. As shown in FIG. 4, the list includes a header 81 that lists the bank's name 82 and the customer's name 83. Below the header 81, each APR line lists the designated supplier 85, the upper limit amount 93, the APR unique identifiers 87, issue date 89 and expiration date 91. It should be noted that the expiration dates and the upper limit amounts are optional.

As noted, once APRs are issued to the customer, they can be used to purchase goods and services offered in E-commerce. Preferably, the designated E- commerce company preferably operates its own Web site. The company's Web site may include a number of Web pages that illustrate its goods and services and allow customers to purchase them using APRs. In particular, such Web pages may include data entry fields to enter the choice of goods and services and to enter a payment using an APR. When the customer chooses payment by an APR, a new Web page is provided that includes options to enter the following data: payment maker name, payment reference, i.e., the APR unique identifier, and the bank reference. The customer enters such information to complete a purchase.

Subsequently, the E-commerce company prepares and forwards a payment request, or an approval request, to the bank that issued the APR. The request may contain all or a combination of the following information: APR unique identifiers, APR issue date,

APR expiration date, customer name, customer's delivery address, company's name, company's bank code, the company's bank account number, actual transaction amount, transaction date, transaction reference, and any remarks. Upon receiving the request, the bank authenticates the APR and its amount. If no conflict arises, the bank approves or pays to the E-commerce company. It should be noted that each APR may include the customer's delivery address to which the good and services purchased are to be delivered.

In an alternative embodiment, the payment is made only after comparing the APR unique identifier without checking other information. In yet another embodiment, other information stored in the database can be compared with the information received from the E-commerce company before the amount is paid. As noted, the above approval procedure is performed by the PAS computer system.

The bank may also execute additional tasks associated with the administration of the system as known in the art such as updating records, keeping audits, and archiving completed transaction records. Other routine operations may include reprinting APRs that the customer lost track of, printing various reports, following-up on rejected transactions, and maintaining a defaulting suppliers file.

More specifically, once the APR is received by the PMAK 11, he/she can purchase goods and/or services from the specific PREC 13. After agreeing upon the amount to be paid for certain goods services, the PMAK 11 presents the PREC 13 with the APR. It is the PMAK's responsibility to ensure that the presented APR can meet the agreed transaction parameters. For example, the transaction amount should not be greater than the upper limit of the APR or the delivery address should be identical to that of the APR. Otherwise the transaction can be rejected.

After the APR is received from the PMAK 11, the PREC 13 makes a request to PADM 15 for approval or payment. When the request for approval is made (instead of making a request for payment) to the PADM, the PAS performs the steps such as preferably depicted in FIG. 5. The PAS first receives the request for approval from the PREC (step 151). The PAS then determines whether or not the received APR exists in the database (step 153). If no such APR exists in the database, the received APR is marked to be checked for fraud and the request is rejected (steps 155 and 156, respectively). If the received APR is found in the database, the name of the PREC presenting the request is compared with PRECs name associated with the APR stored in the database (step 157). If the names do not match, the APR is marked to be checked for fraud and the request is rejected. If the names do match, then the other customer data presented by the PREC is compared to the stored information, (step 159). The APR is rejected if the stored information does not match to the received data. Thereafter, the PAS determines whether the APR has expired (step 163). If the APR has expired, the request is rejected. If the APR is not expired, the PAS determines whether or not the APR is designated for a specific use only (step 165). If the APR is designated as such, the PAS determines if the APR is being used for the designated purpose (step 167). If it is not, the request is rejected. If the APR is not designated for a specific use or the APR is correctly used, the requested amount is compared with the stored upper limit APR amount (step 169). If the requested amount exceeds the upper limit of the APR, the request is rejected. Otherwise, the PAS determines whether or not the payment of the APR is guaranteed (step 171). If the APR's payment is guaranteed, the request is approved (step 177). If the APR is not guaranteed, then the PAS determines whether or not the PMAK's account balance of the fund held with PMAK or the credit account at the PMAK cover the requested amount (step 173). If the balance is sufficient, then the PMAK's account is reduced by the requested amount and the request is approved (steps 175 and 177, respectively). If there is insufficient balance in the PMAK's account, the request is rejected. If the PREC requests payment, the PAS executes the steps such as illustrated in FIG. 6. First, the PAS receives a request for payment from the PREC (step 201). The PAS then determines whether the same request was approved in a previous request for approval from the same PREC for the same APR (step 202) by appropriately processing the information stored in the database. If the request has not been previously approved, the steps similar to the described above in connection with the approval process are performed by the PAS (steps from 203 to 225 correspond to the steps from 153 to 175). However, when the APR is guaranteed, the PREC is paid out of the PMAK's account (see step 243).

Referring back to step 202, if the APR was approved previously and the APR is a guaranteed APR (step 204), then the PAS performs steps 243 to 249. If the APR is not a guaranteed APR, then the PREC is paid out of a transfer account (step 235). After the above steps, the database is updated accordingly (step 249).

As noted above, in addition to the above described functions of the PAS 151, it may also perform tasks associated with maintaining the database and administration of the system. For instance, the PAS can perform updating records, keeping audits, archiving completed transaction records and other operations as known in the art. Further, depending on the embodiment, there may be other specific tasks, such as marking APRs that have expired, re-printing APRs that the PMAK lost track of, printing various reports and other operations as understood by a person skilled in the art.

Thus, this system provides a payment mechanism which increases security by limiting the usage and delivery address associated with a typical APR and not disclosing payer's permanent financial information (e.g., credit card number, bank account). This system may also be used securely by children who do not have credit cards to purchase goods and services on the Internet, and who may use this system by paying with APRs issued to their parents.

The methods of making payments as discussed herein may be applied in any commercial or financial environments. As noted, these methods eliminate the need of disclosing permanent financial details, such as bank account or credit card numbers and limits customer's financial exposure. The payment maker is protected from unwanted disclosure of his/her financial information by the payment receiver and from significant fraudulent or erroneous transactions. The utilization and verification of the APR unique identifiers can be also accomplished by utilizing phone calls among the participants. It should be understood that the software packages and hardware devices described here may be different or modified from the description herein.

The present invention is not to be limited in scope by the specific embodiments described herein. Indeed, modifications of the invention in addition to those described herein will become apparent to those skilled in the art from the foregoing description and accompanying figures. Doubtless, numerous other embodiments can be conceived that would not depart from the teaching of the present invention, whose scope is defined by the following claims.

Claims

THE CLAIMSWhat is claimed is:

1. A computer-implemented method for making a payment on-line comprising: issuing a unique identifier to a first party; associating the unique identifier with a second party when such a request is made by the first party; receiving a payment request from the second party; and approving the request only if the request is made by the second party and only if the second party presents the unique identifier.

2. The method of claim 1 further comprising: storing in computer memory an indication designating whether the unique identifier has a guaranteed payment the first party.

3. The method of claim 1 further comprising: storing in memory an expiration date for the unique identifier, after which the identifier cannot be used.

4. The method of claim 1 wherein the request is to release or to approve an amount of money.

5. The method of claim 4 further comprising: configuring the computer memory so that the unique identifier can be used only under a pre-determined condition.

6. The method of claim 1 wherein the unique identifier is encrypted.

7. The method of claim 1 further comprising printing the unique identifier on paper.

8. The method of claim 1 wherein the step of issuing the unique identifier to the first party is achieved by at least one of: storing a cash payment received from the first party; storing a bank account of the first party; storing a credit card account of the first party; and storing an open credit line of the first party.

9. The method of claim 1 further comprising issuing the unique identifier at an automatic teller machine.

10. The method of claim 1 further comprising issuing the unique identifier over the Internet.

11. The method of claim 1 further comprising storing detailed information associated with the unique identifier, wherein the detailed information includes at least one of the name of the first party's delivery address, and the date on which the unique identifier was issued.

12. The method of claim 11 further comprising: receiving the detailed information from the second party; and refusing to release the payment if the stored detailed information is not substantially identical to the received detailed information.

13. The method of claim 1 wherein the steps of receiving is performed over the Internet.

14. A computer- implemented system for making payments comprising: an input device configured to electronically receive a request from a first party to generate a unique identifier associated with a first amount of money and to associated the unique identifier with a second party; software configured to issue the requested identifier to the first party; software for storing the first amount of money associated with the first party and the identifier; a database configured to store the unique identifier and the corresponding first amount, and to associate the unique identifier with the second party.

15. The system of claim 14 wherein the database stores or specific delivery address.

16. The system of claim 14 wherein the input device is further configured to receive the unique identifier and a request to release a second amount of money.

17. The system of claim 16 further including: software configured to refuse to release the second amount if the second amount exceeds the first amount stored in connection with the identifier, and configured to release the second amount to the second party if the second amount is equal or less than the first amount.

18. The system of claim 16 further including: software configured to release the second amount only if the request to release is made by the second party.

19. The system of claim 14 wherein the input device provides communication over the Internet.

20. The system of claim 16 wherein the database is further configured to indicate that the unique identifier has been paid after releasing the second amount; and software configured to refuse to release the second amount when the unique identifier is to be used only once and the unique identifier has already been used once.

21. The system of claim 14 wherein the unique identifier is encrypted.

22. The system of claim 14 further comprising an output device configured to print a unique identifier on a piece of paper.

23. The system of claim 15 wherein the database is further configured to store detailed information associated with the unique identifier, and wherein the detailed information includes at least one of the name of the first party, a personal identification number of the first party and the date on which the unique identifier was issued.

24. The system of claim 23 wherein the input device is further configured to receive the detailed information associated with the unique identifier from the second party; and the processor executes software configured to refuse to release the second amount if the received detailed information is not identical to the corresponding stored detailed information for the identifier.