CA2199942C

CA2199942C - Computerized payment system for purchasing information products by electronic transfer on the internet

Info

Publication number: CA2199942C
Application number: CA002199942A
Authority: CA
Inventors: Lee H. Stein; Einar A. Stefferud; Nathaniel S. Borenstein; Marshall T. Rose
Original assignee: PayPal Inc
Current assignee: PayPal Inc
Priority date: 1994-09-16
Filing date: 1995-09-14
Publication date: 2007-08-21
Anticipated expiration: 2015-09-14
Also published as: CA2199942A1

Abstract

A payment system (10) for enabling a first Internet user to make a payment t o a second Internet user, for the purchase of an information product deliverable over the Internet (12). The payment system (10) provides cardholder accounts for the first and second Internet users. When the second user sends the information product to the first user over th e Internet (12), the second user also makes a request over the Internet (12), the front end portion of the payment system (10) requests payment from the first user. The front end portion of the payment system (10) queries the first user over the Internet (12) whether to proceed with payment to the second user. If the first user replies affirmatively, a charge to the first user is processed off the Internet (12); however if the first user replies negatively, the first user is not charged for the information product. The payment system (10) informs the second user of the first user's decision and pays the second user upon collection of the charge from the first user.

Description

COMPUTERIZED PAYMENT SYSTEM
FOR PURCHASING INFORMATION PRODUCTS
BY ELECTRONIC TRANSFER ON THE INTERNET
BACKGROUND OF THE INVENTION
The present invention relates to a system for enabling payment for information products that can be transferred electronically over a nonsecure network, and more particularly, the present invention relates to a payment system that can be used to enable an Internet user to make a payment to another Internet user for information products of value that can be electronically transferred over the Internet.
The Internet has emerged as a large community of electronically-connected users located around the world who readily and regularly exchange significant amounts of information. The Internet continues to serve its original purposes of providing for access and exchange of information among government agencies, laboratories, and universities for research and education. In addition, the Internet has evolved to serve a variety of interests and forums that extend beyond its original goals.
The Internet has been considered as a potential new marketplace for information products. It is now physically possible to transfer information products such as articles, software, cartoons, etc., via the Internet.
Using the Internet as a marketplace has several advantages. Information products can be delivered electronically without physical packaging. Because information is easily duplicated with the point and click of a mouse on a user's workstation, the cost of manufacturing and reproducing inventory closely approaches zero, leaving the cost of creating or synthesizing the information as the dominant cost. Once an information product has been developed, there may be little or no cost of manufacturing or inventory since a copy of the product can be shipped whenever a buyer makes a purchase given that the merchant has the bandwidth WO 96/08783 219 9 9 4 2 pCT1US95/11606 available. Given that,,the cost of inventory on the Internet is close tv~zero, there are potentially tens of thousands of information sellers, i.e. people with ideas or information products to sell, on the Internet.
Another advantage of using the Internet as a marketplace is that, depending on the kind of information product involved, processing of a buyer's order can be automated, so there is no need for a worker to manually intervene to complete a transaction.
io Although the Internet presently has the capability to serve as a marketplace for new information products, use of the Internet for this purpose has been slow to develop. One reason that accounts for this lack of development is that it is difficult to pay for information products using the Internet. A user cannot send cash or a check via the Internet and sending a check via physical delivery services is slow. Sending a credit card number over the Internet poses security problems.
Moreover, even if it were reasonably safe to send credit card numbers, there are a lot of potential sellers of information products who do not have --and could not qualify for-- the required merchant accounts. Credit card companies require a seller who accepts credit card for payment, to have a merchant account. Conventional merchant accounts require a relatively high standard of credit worthiness and a financial guarantee. The need for a conventional merchant account impedes commerce in the Internet marketplace because an average Internet user may have a difficult time qualifying for a merchant account.
Accordingly, there is a need for a system that solves the payment problem on the Internet to enable development of a commercial market.

SUMMARY OF THE INVENTION
According to a first embodiment of the present invention, there is provided a method and payment system 3 219,9942 PCT/US95f11606 for enabling a first Internet user to make a payment to a second Internet user, typically for the purchase of an information product deliverable over the Internet. The payment system provides cardholder accounts for the first and second Internet users. When the second user sends the information product to the first user over the Internet, the second user also makes a request over the Internet to a front end portion of the payment system requesting payment from the first user. The front end io portion of the payment system queries the first user over the Internet whether to proceed with payment to the second user. If the first user replies affirmatively, a charge to the first user is processed off the Internet;
however if the first user replies negatively, the first is user is not charged for the information product. The payment system informs the second user regarding whether the first user's decision and pays the second user upon collection of the charge from the first user. Security is maintained by isolating financial and credit 20 information of users' cardholder accounts from the front end portion of the payment system and by isolating the account identifying information from the associated e-mail address.
BRIEF DESCRIPTION OF THE DRAWINGS
25 These and other features, aspects, and advantages of the present invention will become better understood with regard to the following description, appended claims, and accompanying drawings where:
Figure 1 is a block diagram illustrating the 30 relationship between a payment system of a first embodiment of the present invention to a large network.
Figure 2 is a block diagram of a hardware configuration for the payment system of Figure 1.
Figure 3 is a block diagram of the program 35 arrangement of the payment system of Figure 1;
Figure 4 is a diagram of data for a cardholder account for use with the payment system of Figure 1;

WO 96/08783 + PCT/US95/11606 Figure 5 is a flow chart showing message flow for the initial steps of a funds transaction using the payment system of Figure 1;
Figures 6A-6P are diagrams of data messages used in connection with the payment system of Figure 1;
Figure 7 is a flow chart showing the message flow for a cardholder inquiry request using the payment system of Figure 1;
Figure 8 is a flow chart showing the message flow io for a transfer query request and reply using the payment system of Figure 1;
Figure 9 is a flow chart showing the message flow for payment failure using the payment system of Figure 1;
Figure 10 is a flow chart showing the message flow i5 for payment notification using the payment system of Figure 1;
Figure 11 is a flow chart showing message flow for a chargeback process using the payment system of Figure 1;
Figure 12 is a flow chart showing message flow for a 20 capabilities request process using the payment system of Figure 1; and Figure 13 is a message flow diagram showing messages for a new account transaction between a user and the payment system of Figure 1.

I. OVERALL SYSTEM
Figure 1 shows a block diagram of a first embodiment of the present invention for a payment system 10. The payment system 10 is shown in relation to the Internet 30 network 12. The Internet network 12 is a large, quasi-public network having many users 14. The Internet network 12 is of a type that the users 14 can access by various means such as conventional commercial telephone systems. The network 12 provides numerous services for 35 its users such as e-mail or World Wide Web (WWW).
Although the payment system 10 is specifically useful for the Internet, it may be used in conjunction with other WO 96/08783 21" "' 94Z PCT/US95/11606 e-mail based systems having a plurality of users.
In the embodiment of Figure 1, one of the users 14 (designated as an information buyer 20) wishes to acquire an information product 26 from another of the users (designated as an information seller 28). The information seller 28 may be any user with an information product to vend. The information product 26 can be any item that is transferable over the Internet network 12.
The information product 26 may be a message, an article, io an original work of authorship, a composition, a writing, music, a pictorial work, a drawing, a cartoon, a story, a software program, a recipe, jokes, and so on. The information seller 28 wishes to sell a copy of the information product 26 to the information buyer 20 at a i.s price. The price may be an advertised price (e.g.
advertised over the Internet, on a bulletin board, or other media), or may be a negotiated price (e.g.
negotiated via e-mail exchange). Although the example of Figure 1 shows only one information seller 28 and one 20 information buyer 20, the payment system 10 is understood to extend to include multiple buyers of one seller, multiple sellers to one buyer, and multiple sellers and multiple buyers. Also, a buyer or a seller may be an individual, a company, or an institution.
25 Also shown in Figure 1 is a financial transaction settlement system 30. The financial transaction settlement system 30 represents presently-available commercial institutions that process credit and other financial transactions. For example, the financial 30 transaction settlement system 30 may represent commercially available credit card processing institutions (e.g. Visa, Master Card, Discover, and so on). The financial transaction settlement system 30 includes two components: an issuer 32 and an acquirer 34.
35 The issuer 32 includes banks, or other institutions, that issue credit cards to persons, sends statements and bills to credit card holders on a regular basis, and collects payment from the credit-card holders. These functions are not performed on the Internet but use conventional mail delivery, authorized direct withdrawals from bank accounts, etc. The payment system 10 of the present embodiment utilizes these commercially available issuers 32 to bill users and to collect payment from users for their transactions on the Internet 12 using the payment system 10. For example, a user's transactions using the Internet would show up on the user's credit card statement as a charge from the payment system 10 although individual transactions using the payment system 10 on the Internet 12 may not be specifically listed on the credit card statement. The financial transaction settlement system 30 also includes the acquirer component 34. This acquirer component 34 is a bank or other institution that provides a merchant account to the payment system 10. The merchant account provided to the payment system 10 is similar or identical to the conventional merchant accounts that are provided to other businesses. By means of having the merchant account, the payment system 10 forwards user charges to the acquirer component 34 thereby getting user charges into a conventional, commercially-available settlement system.
As mentioned above, the acquirer 34 processes the user charges received from the payment system and passes this information to the issuer component 32 for the preparation and sending of monthly statements and bills to users and collecting payment from users.
Figure 2 is a block diagram illustrating one possible configuration of hardware components used to implement the payment system 10 of Figure 1. The payment system 10 includes two computers: a front end computer 50 and a back end computer 52. The front end computer 50 and the back end computer 52 are connected together via a private network 53. In a preferred embodiment, the private network is an Ethernet network. The front end computer 50 includes a front end system board 54 WO 96/08783 2t ~ ~ ~ ~ ~ PCT/US95/11606 associated with a front end memory 56, a storage device 58 such as a fixed disk drive, a back up tape drive 60, a removable media drive 62, a monitor 64, and a power supply 66. The front end computer 50 is connected to the Internet 12 is by means of a leased Ti line 69.
The back end computer 52 includes a back end computer system board 68 associated with a back end computer memory 70, a back end computer storage device 72 such as a fixed disk drive, a back up tape drive 74, a removable media drive 76, a monitor 78, and a power supply 80. The back end computer 52 is connected to the front end computer 50 by means of Ethernet cable. The back end computer 52 also has a Novell LAN 81 that provides a communication link to the settlement system 30.
Both the front end computer 50 and the back end computer 52 in this embodiment are preferably commercially available Sun Microsystems SS1000 computers.
Preferably, both the front end computer 50 and the back end computer 52 are equipped with 64 MB memory. The dedicated private network is an Ethernet and includes a SBus host adaptor. The communication server is a Sun Microsystems SPARCserver 1000. Both the front end monitor 64 and the back end monitor 78 are commercially available Sun 1711 monitors. The front end and back end tape drives are Python 5GB tape drives using 4mm tape available from Sony, Inc.. The front end disk drive 58 and the back end disk drive 72 are commercially available Seagate 1.7GB disk drives. The host adaptor is a Sun Microsystems SBus host adaptor. The network server is a commercially available Sun Microsystems SSarray 101.
Referring to Figure 3, the front end computer 50 runs a front end program 90. The front end program 90 is a software program that provides for communication with users 14 on the Internet network 12. The front end program 90 includes several modules that can be accessed and used by users 14 of the Internet. The modules included on the front end program include modules that permit users 14 to make a funds transfer transaction 91, to check a subscriber's status 92, to enroll as subscribers 93, etc.
The back end computer 52 runs a back end program 92.
Thus, the front end program 90 is physically separate and isolated from the back end program 92. The back end program 92 receives information from and sends information to the front end program 90 only by means of io batch processing. This results in an inherently safe method of communicating between the publicly accessible part of the payment system, i.e. the front end computer 50, and the secure part of the payment system, i.e. the back end computer 52.
i5 II. REOUIREMENTS OF A SUBSCRIBER
In order to use the payment system 10 for transactions, the information buyer 20 and the information seller 28 both need to have subscriber or cardholder accounts with the payment system 10. As 20 subscribers, users of the Internet network 12 may conduct commercial transactions with each other, such as paying for information products 26, making charitable contributions, etc.
Referring to Figure 4, a cardholder account 100 25 includes at least the following information: a cardnumber 102, an Internet e-mail address 104, a state 106, a pay-in selection 108, a pay-out selection 110, and a currency preference 112. Each of these items is explained below.
30 The cardnumber 102 uniquely identifies the cardholder account 100. The cardnumber 102 is an alphanumeric string that is easily typed and read by a human. Also, the cardnumber 102 is relatively hard to guess and bears no deducible relationship to any 35 financial artifact, such as a credit cardnumber, a checking account number, nor to any e-mail address.
The cardholder Internet e-mail address 104 is the WO 96/08783 PCT/US95l11606 e-mail address of the cardholder that is unique for each user of the Internet.
The state 106 is one of "active", "suspended", or, "invalid".
The pay-in selection 108 is how the cardholder transfers funds, i.e. makes payment, to the payment system 10. Typically, this may be done by using a conventional authorization to charge a credit card. The pay-in selection is not encoded in or directly derivable io from the cardnumber.
The pay-out selection 110 is how a the payment system 10 transfers funds to, i.e. pays, the cardholder.
This may include use of a direct deposit checking account, etc. The pay-out selection 110 is not encoded is in or directly derivable from the cardnumber.
The currency preference 112 is the national currency used for the pay-in selection 108 and pay-out selection 110 between the payment system 10 and the subscriber.
Subscriber account information is distributed in the 20 payment system 10. Referring again to Figure 3, only a portion of the subscriber account information resides on the front end computer 50 where it is accessible by the front end program 90. However, a full copy of all the cardholder account information resides on the back end 25 computer 52 where it is accessible by the back end program 92. Included on the back end computer 52 is a copy of the portion of the cardholder information on the front end computer 50. Specifically, the part of the subscriber account information that resides on the front 30 end computer 50 is located in a data file 113 stored on the front end computer storage device 58. The subscriber account information that resides on the back end computer 52 is located in a data file 114 stored on the back end computer storage device 72.
35 Specifically with respect to the items of information in a cardholder account, located on the storage device 58 associated with the front end computer WO 96/08783 21" " O 42 PC1/US95/11606 50 is that portion of the subscriber account information 106 that includes the subscriber account number 102, the Internet e-mail address information 104, the state 106, and the currency preference 112. However, the front end s computer 50 does not contain any of the pay-in 108 or pay-out 110 informa:tion, such as credit card information, etc., associated with any of the subscribers. Credit card or other payment information is located only in the data file 114 on the storage device 72 of back end io computer 52 To access the front end program 90 over the Internet, users 14 may use a user interface software program 118 that can be run on their own computers for interactive access, or alternatively, users 14 may access 15 the payment system 90 via conventional e-mail programs, for store-and-forward access. Programs 90 and 118 may be written in any suitable programming language, such as Tcl or C. The software modules are capable of being used with the UNIX operating system, DOS, and may be ported to 20 various other operating systems. A publication entitled "The application/green-commerce MIME Content-type" is includes a format for Internet communication for use between users of the Internet and the payment system 10.
III. METHODS OF OPERATION OF THE PAYMENT SYSTEM
25 As mentioned above, the payment system 10 provides users of the Internet with a variety of services and functions, including making a funds transfer transaction, validating a subscriber's status, and enrolling as a subscriber. Several of these services and functions are 30 described below.
A. Funds Transfer Transaction A funds transfer transaction occurs when one Internet user who is a subscriber, i.e. who has a cardholder account on the payment system 10, acting as an 35 information seller 28, requests payment from another cardholder, acting as an information buyer 20.
Typically, this may occur when a buyer 20 purchases an information product 26 over the Internet 12. However, this transaction may result for other reasons, e.g. to facilitate charitable contributions, to pay for computer or software customer support, etc.
For purposes of the example described below, it is assumed that the buyer 20 already is aware that the seller 28 has an information product 26 to sell and that a price has been established. The buyer 20 may be aware of the seller 28 and his information product via .
advertising, on the Internet or other media, through others, from a bulletin board, from a product warehouse on the Internet, or any other means. The buyer 20 is aware of a means to contact the seller via the Internet.
The buyer 20 may contact the seller 28 by sending a message to the seller's Internet address or by an interactive protocol, World Wide Web (WWW), FTP, etc., so that a message can be sent to the seller 28. The means to contact the seller may be included in advertising, etc.
Figure 5 shows an initial part of the message flow for a funds transfer transaction according to the first embodiment of the present invention. The Internet user who is the buyer 20 sends a message 128 to (or otherwise communicates with by means of interactive protocols, WWW, etc.) the Internet user who is the seller 28 via the Internet 12. The communication 128 sent by the buyer 20 to the seller 28 includes the buyer's cardnumber 102B
("102B11 = cardnumber "10211 + buyer "B"), as illustrated in Figure 6A. The buyer's message 128 is the first step in initiating the funds transfer transaction using the payment system 10. Alternatively, the buyer 20 may include the cardnumber 102B as a username in a file transferred from the buyer 20 to the seller 28 using the Internet 12.
B. Inquiry Transactions At this stage, the seller 28 may wish to communicate with the payment system 10 to have a cardnumber inquiry transaction performed on the buyer's cardholder number.
A cardnumber inquiry transaction occurs when one cardholder wishes to ascertain the state 106 of another cardholder's account. Typically, a cardnumber inquiry transaction occurs when one cardholder, acting as a seller, is deciding whether to send an information product 26 to another cardholder, who represents to be a cardholder and who is interested in acquiring the information product from the seller 28.
Referring to Figure 7, the seller 28 may send an inquiry-request message 216 containing the buyer's cardnumber 102B to the front end program 90 using the Internet 12. As shown in Figure 6B, the inquiry-request message 216 contains at least the buyer's cardnumber 102B. In response, the front end program 90 sends the seller 28 an inquiry-result message 218. As shown in Figure 6C, the inquiry-result message 218 contains the buyer's cardnumber 102B and the state 106B associated with the buyer's account. If the buyer's cardholder account state 106B is "active", presumably the buyer is in good standing and the seller 28 can proceed with the transaction by sending the information product 26 to the buyer 20 via the Internet. If the buyer's cardholder account status 106B is "invalid", the seller 28 knows that the account is no good and that funds transfer transactions cannot be processed through it. If the buyer's cardholder account status 106B is "suspended", the seller knows that the buyer 20 has not been responsive to recent transaction attempts. The seller 28 may still decide to send the information product 26 to the buyer 20 and a funds transfer transaction will be processed. No guarantee of payment is made however.
Although an information seller 28 may prefer to send an inquiry-request 216 to the payment system 10 prior to sending an information product to the buyer 20, the seller 28 may choose to skip the inquiry-request step.
At this stage, the seller 28 sends the information product 26 to the buyer 20 via the Internet.
Funds Transfer Transaction (continued) Referring again to Figure 5, at approximately the same time that the seller 28 sends the information product to the buyer 20 via the Internet, the seller 28 also sends a transfer-request message 129 to the payment system 10 via the Internet 12. Specifically, the seller 28 sends the transfer-request message 129 to the front end program 90 on the front end computer 50. The io transfer-request message 129 may be sent by either e-mail or using an interactive protocol on the Internet 12.
Referring to Figure 6D, the transfer-request message 129 contains the following information: the buyer cardnumber 102B, the seller cardnumber 102S, a transfer type 130 is (e.g., sale of information), a textual description 132 of the transaction, a transfer amount 134, the currency 112S
(e.g., USD); and optionally, the merchant's transaction-identifier 136.
After receiving the transfer-request message 129, 20 the front end program 90 asks the buyer 20 whether the buyer 20 wishes to authorize payment for the transaction 132 to the seller 28. Specifically, the front end program 90 sends a transfer-query message 140 to the buyer 20, as shown in Figure 8. Using the information 25 contained in the transfer-request message 129 from the seller 28, specifically the buyer's cardnumber 102B and the seller's cardnumber 102S, the front end program 90 looks up the buyer's name 103B and the seller's name 103S. As shown in Figure 6E, the transfer-query message 30 140 contains: a transaction-identifier 142 uniquely-generated by the front end program 90, the buyer's name 103B, the seller's name 103S, the transfer type 130, the textual description of the transaction 132, and a transfer amount 135 in the currency preference 112B
35 associated with the buyer's cardholder account (which may represent a currency exchange of the transaction amount 134 into the buyer's currency preference 112B and further :, which fixes the tran'sfe~r amount, with respect to currency fluctuations, in the currency used by the buyer). In addition, if currency denomination exchange occurred, the original currency 112S and amount 134 are noted in the s message 140. In the transfer-query message 140, the buyer's name 103B and the seller's name 103B are used instead of the buyer's cardnumber 102 and the seller's cardnumber 102S in order to minimize transmission of the cardnumber information over the Internet thereby io improving security of the system. After sending the transfer-query message 140, the front end program 90 waits for a response from the buyer 20.
The buyer 20 may respond by sending a transfer-response message 150 to the front end computer 50 via the is Internet, as shown in Figure 8. As illustrated in Figure 6F, the transfer-response message 150 contains the following data: the payment system generated transaction-identifier 142 and an indication 152 of the buyer's willingness to allow transfer of funds. The 20 willingness indication 152 is one of "yes", "no", or, " f raud" .
In a preferred embodiment, the structure of the transfer-query message 140 facilitates preparation of the transfer-result message 150 by the buyer 20. In the 25 transfer-query message 140, the transaction-identifier 142 is placed in the "subject" of the transfer-query message 140 and the e-mail address to which the buyer's transfer-response message 150 should be sent (e.g.
"response@card.com") is placed in the "sender's address"
30 of the transfer-query message 140. Many conventional e-mail programs in use on the Internet, including many older programs, have a feature that will automatically read the "subject" and "sender's address" of a received message and format a reply message directed to the 35 sender's address with the same "subject" as the received message. If the buyer 20 uses this common feature to send his transfer-response message 150 back to the _ 21 999,12 payment system 10, the only information that the buyer 20 will have to add is the willingness indication 152 which is only a one word reply, (i.e. "yes", "no", or, " f raud" ) .
Referring again to Figure 8, if the buyer 20 indicates "yes" in the willingness indication 152, the front end program 90 then sends a transfer-result message 160 to the seller 28 via the Internet 12. As shown in Figure 6G, the transfer-result message 160 contains the io following information: the transaction-identifier 142, the seller's name 103S, the buyer's name 103B, the transfer type 130, the textual description of the transaction 132, the transfer amount 135 in the currency 112B associated with the buyer's cardholder account, the indication 152 of the buyer's willingness to allow transfer of funds, and the seller's transaction-identifier 136 if present in the originating transfer-request message 129. In addition, if currency denomination exchange occurred, the original currency 112S and amount 134 are noted in the transfer-result message 160. The front end program 90 transfers the transaction information, by batch processing, to the back end program 92 which adds the transaction information to a settlement queue 168. The settlement queue 168 is a data file located on the storage device 72 of the back end computer 52.
Referring back to the step shown in Figure 8 where the buyer 20 sends the transfer-response message 150 back to the payment system 10, if the buyer 20 replies "no" in the willingness indicator 152, the front end program 90 sends a transfer-result 160 to the seller 28 with a "no"
indication 152. In addition, a service charge to the buyer 20 may be generated. Information regarding the buyer's "no" reply in the transfer-response 150 is batched from the front end program 90 to the back end program 92 where a service charge may be added to the settlement queue 168 for the buyer 20. Further, if a "no" indication is received more than a certain number of times in a certain number of transactions over a certain time period, then the state 106B of buyer's account 100B will become "suspended". This is to prevent a user from making a practice of ordering and receiving information products without paying for them. If the buyer's account state 106B becomes suspended, this information is also transmitted by batch processing from the front end program 90 to the back end program 92 so io that the cardholder account information on the back end computer 52 conforms to that on the front end computer 50.
Referring again back to the step shown in Figure 8 where the buyer 20 sends the transfer-response message 150 back to the payment system 10, if the buyer 20 indicates "fraud" in the willingness indication 152, the payment system 10 changes the state 106B of the buyer's cardholder account 100B to "invalid". A response of fraud indicates that the buyer 20 never requested the information product 26. The information that the buyer 20 responded "fraud" to the willingness indication 152 is also transmitted by batch processing from the front end program 90 to the back end program 92 so that the cardholder account information on the back end computer 52 conforms to that on the front end computer 50.
Referring back to the step illustrated in Figure 8 where the front end program 90 sends the transfer-query message 140 to the buyer 20, if a period of time elapses and the front end program 90 does not receive a transfer-response message 150 from the buyer 20, the front end program will send the transfer-query message 140 again, i.e. a second notice. The front end program 90 may send the transfer-query message to the buyer 20 several times until a response from the buyer 20 is obtained. If more than a certain number of days elapses, or more than a certain number of transfer-query messages 140 are outstanding for the buyer 20, and the front end program WO 96/08783 219 9 9 4 2 pCTIUS95/11606 does not receive a transfer-response message 150 from the buyer 20, then the front end program 90 causes the buyer's cardholder account 100B to become suspended.
This is done by changing the buyer's cardholder state 106B from "active" to "suspended". However, if a transfer-response 150 is received and/or the number of outstanding transfer-query messages 140 for the buyer 20 drops to less than a certain threshold, the buyer's account 100B may be returned to an "active" state.
Further, any outstanding transfer-query messages 140 may be sent again some time later.
C. Accumulation and Settlement of Transactions 1. Processing Charges to Buyers Processing of the charges and credits between the back end computer 52 and the settlement system 30 is conducted off the Internet using secure communications channels. This isolates the buyer-seller activity which occurs on the Internet from the financial and credit activity which occurs off the Internet.
Referring to Figures 1 and 3, the back end program 92 regularly checks the accumulated purchase transactions for each cardholder in the settlement queue 168 for age and amount. For example, the back end program 92 checks whether the accumulated purchase transactions for a cardholder are either 30 days old or reach a threshold of at least $10.00. When the accumulated purchase transactions for a cardholder reach either the age or amount threshold, the back end program 92 batches the accumulated transactions into a single funds transfer transaction using the buyer's pay-in selection 108B
associated with the buyer's cardholder account 100B.
This is typically accomplished by posting a charge 194 to the buyer's credit card account. To post a charge on the buyer's credit card account, the back end program 92 transmits an accumulated charge 194 to the credit card system network 30 via the acquirer component 34 where the payment system 10 maintains a conventional merchant account. The credit card network includes a component 196 that initially checks the validity of the buyer's credit card number, e.g. pay-in selection 108B, to determine whether the credit card is lost, stolen, expired, overlimit, etc.
If the credit card network 30 refuses to process the buyer's credit card number, e.g. the credit card is lost, stolen, canceled, expired, etc., collection from the buyer is considered failed. The back end program 92 io changes the buyer's cardholder state 106B to "suspended".
The back end program 92 also sends the failure information, by batch processing, to the front end program 90 so that the buyer's cardholder state 106B on the front end computer 50 is also changed to "suspended".
Referring to Figure 9, the front end program,90 then sends a payin-failure-notification message 210 to the buyer 20 over the Internet. As shown in Figure 6H, the payin-failure-notification message 210 contains the notification-identifier 144 associated with the pay-in method 108, the transfer amount 134, and the currency 112S.
In addition, for each transaction associated with the payin-failure-notification message 210, the front end program 90 also sends a collection-failure-notification message 211 to the seller 28 over the Internet. As shown in Figure 61, this collection-failure-notification message 211 contains the server's transaction-identifier 138, and the amount 134 and currency 112 associated with the transaction.
Referring back to the step where the back end program 92 transmits the accumulated charge 194 to the credit card network 30, if the credit card network 30 accepts the buyer's card, the acquirer 34 then processes the accumulated charge 194 in the credit card system 30 to post the charge to the buyer's credit card in the usual manner by sending the appropriate information to the buyer's credit card issuer 32. The buyer's credit card issuer 32 sends the buyer 20 a credit card bill 190, typically via the postal system. The credit card bill 190 lists the accumulated charge 194 as an item on the user's credit card bill. Since accumulated charges 194 for a cardholder are sent to the acquirer 34 when they reach a certain threshold amount, more than one accumulated charge may be listed on the credit card bill sent to the buyer 20 by the buyer's credit card issuer 32.
io The description previously set forth explains how the payment system can process a charge to the user using the conventional, commercially available credit card system. There are variations on and modifications of the previously set forth arrangement that may be utilized.
is For example, the issuer 32 may process a debit to a bank account of the buyer 20 instead of sending a credit card bill. Alternately, the issuer 32 may send the buyer a bill (other than a credit card bill) for the accumulated charges.
20 Referring back to the step where the back end program 92 sends the accumulated charge 194 to the credit card system 30, if the credit card system 30 accepts the buyer's credit card number, the back end program 92 sends indication of this acceptance, by batch processing, to 25 the front end program 90. The front end program 90 sends a payin-notification message 212 to the buyer 20 via the Internet, as shown in Figure 10. As shown in Figure 6J, the payin-notification message 212 contains the cardnumber 102, the pay-in amount 134 in the currency 112 30 associated with the buyer's account, the notification-identifier 144 associated with the pay-in method 108, a list of accumulated transactions 146, and, optionally, a service charge 148.
2. Processing Payments to Sellers 35 Referring to Figure 10, if the credit card system 30 accepts the accumulated transaction 194 from the back end program 92, the back end program 92 treats the payment as made by the buyer. The back end program 92 calculates fees associated with the transaction. For example, the back end program will subtract the charge applied by the credit card system 30 from the amount paid by the buyer.
The back end program 92 will also subtract a service charge for the payment system 10. The back end program 92 will then calculate a net settlement to the seller for the transaction. The net settlement will be posted to the settlement queue 168 for the seller 28 located on the io back end computer 52.
The back end program 92 periodically checks the settlement queue 168 to see if payments have accumulated for the seller 28. Regularly, the back end program 92 will batch the accumulated payment transactions into a single off-Internet transaction, using the pay-out method 110S associated with the seller's account 100S.
In a preferred embodiment, transactions that have accumulated for a seller may be retained for a period of time before the single off-Internet payment transaction to the seller is made. This period of time may vary depending on the payment history of the seller. For example, a payment that is received from the credit card system 30 may be held for a period of 60 days before it is combined with other accumulated transactions and paid to the seller by means of the seller's indicated off-Internet payment method.
One way that a payment may be made to the seller is by direct deposit to a checking account maintained by the seller. The back end program 92 transmits information 197 to the settlement system 30 to make a direct deposit 198 to the seller's checking account 199. If the acquirer component 34 is a commercial bank, the back end component 92 may use the acquirer 34 to transmit the direct deposit information from the acquirer-bank to the seller's bank for direct deposit to the seller's checking account 199.
In addition to sending the information to the WO 96/08783 PCT"NS95/11606 settlement system 30 to effect payment to the seller, e.g. by making a direct deposit to the seller's checking account, the back end program 92 also sends information, by batch processing, to the front end program 90 that an accumulated payment to the seller has been initiated.
The front end program 90 then sends a message via the Internet informing a seller 28 that payment has been made to the seller's account. The front end program 90 sends a payout-notification message 214 to the e-mail address 104S associated with the seller's cardholder account. As shown in Figure 6K, the payout-notification message 214 contains the cardnumber 102S, the pay-out amount 150 in the currency 112 associated with the cardholder's account, the notification-identifier 152 associated with the pay-out method 110, the list of accumulated transactions 146, and, optionally, a service charge 149.
D. Chargeback Transactions A chargeback transaction occurs when a funds transfer associated with a previous payin-notification message results in a chargeback. Typically, this occurs when a buyer 20, whose pay-in method 108B is a credit card, disputes a charge on his credit card statement.
Figure 11 shows the message flow for a chargeback transaction having the following steps:
The front end program 90 sends a payin-chargeback-notification message 220 to the buyer 20 over the Internet. As shown in Figure 6L, the payin-chargeback-notification message 220 contains the notification-identifier 144 associated with the pay-in method 108, and, the pay-in amount 134 in the currency 112 associated with the buyer's account 100.
Also as shown in Figure 11, for each accumulated transaction associated with this chargeback, the front end program 90 also sends a payout-chargeback-notification message 222 to the seller 28 over the Internet. As shown in Figure 6M, the payout-chargeback-notification message 222 contains the server's WO 96/08783 ~ y- PGT/US95/11606 219994 2"' transaction-identifier 138, the amount 134, and the currency 112 charged back to the buyer 20.
E. Payment system capability transaction A payment system capability transaction occurs when a user wishes to ascertain the capabilities of a payment system 10. Figure 12 shows the message flow for a payment system capability transaction having the following steps:
A user 14 uses the Internet 12 to send a capabilities-request message 224 to the payment system 90. As shown in Figure 6N, the capabilities-request message 224 has no specific attributes, i.e. it contains no specific information fields, it may be only a query.
The payment system 90 sends a capabilities-result message 3.5 226 to the user 14. As shown in Figure 60, the capabilities-result message 226 contains a list of supported transaction types and parameters 156, a list of supported currencies 158, and a list of supported languages 159.

F. Cardholder aRplication A cardholder application transaction occurs when an Internet user 14 wishes to establish a cardholder account 100. Figure 13 shows the steps for the application process for a cardholder application.
The user 14 sends an application-request message 227 over the Internet 12 to the payment system 90. This request may be sent by either electronic mail or using an interactive protocol. The payment system 90 sends an application-result message 228 to the user 14. As shown in Figure 6P, the application-result message 228 is essentially a blank form into which the user enters information for the following: the applicant's name, address, phone number, Internet e-mail address 104, and the currency preference 112, language, and preferred account identifier ID.
The user 14 fills in parameters from the ~N~95/1~60~
PWO 96/08783 2199942.
t.: . . .
application-result message 228, and sends a newacct-request message 230 to the payment system 10. The payment system 10 sends the user 14 a newacct-result message 232. As shown in Figure 6Q, the newacct-result message 232 contains the status 106 of the application, and if the application is approved, the cardnumber 102 assigned to the user 14.
It is noted that credit card numbers or other sensitive information relating to financial transaction are not sent over the Internet. The user who wishes to open a cardholder account sends only part of the required cardholder information over the Internet in the newacct-request message. In order to complete the cardholder application process, the user 14 provides his credit card information, checking account information, or other financial information to the payment system 10 through non-Internet channels. This credit card information, checking account information, or other financial information is maintained on the back end computer 52 of the payment system 10 in the secure data file 114. The user 14 calls a telephone number 280. This may be an 800 number in the U.S. or a toll number for foreign calls.
The user 14 is prompted to enter his the credit card information 282 by touch tone entry. Thus, the user's credit card information is not transmitted over the Internet at any time thereby contributing to the security of the system.
IV. ADVANTAGES OF THE PAYMENT SYSTEM
In the embodiment of the invention described above, there is provided a new model for Internet commerce in which an information seller 28 carries the risk of non-payment. By shifting the risk of non-payment, the embodiment of the present invention avoids the necessity of guarantees of credit worthiness for sellers. This allows every participating Internet user to be both a buyer and a seller of information on the Internet.
However, it is noted that various aspects of the model (e.g., buyer confirmation, limitations on buyers' refusals to pay, etc.) minimize a seller's risk to the point where it is offset by the expanded commerce base created.
Buyers of information products often cannot make a purchase decision unless the product in hand. Given that there is virtually no cost for manufacturing and distribution, unwanted information products need not be "returned"; it is less costly merely to delete the io unwanted information product. Buyers of information products pay only for the information that they can use, thereby avoiding the frustration of returning unwanted goods and asking for a refund as they would in a conventional marketplace Cardnumbers are bi-directional, i.e., a cardholder may engage in commerce as either a buyer or a seller.
Hence, the terms "seller" and "buyer" are merely role-descriptors with respect to a given transaction, e.g., the cardnumber acting as a buyer in one transaction might be used in the merchant role for another transaction.
Further, the term seller and buyer are generic in that they refer only to the direction of the funds transfer for a transaction. Hence, if a cardholder makes a charitable contribution to a non-profit organization, the cardholder is still referred to as the buyer and to the non-profit as the seller even though no actual "sale" is occurring.
Another advantage of the payment system is that it enables anyone with an information product to sell to have an available market. There is no age limit on information sellers.
The payment system described above is particularly advantageous for use on networks that do not have a centralized management authority, such as the Internet.
Other such systems include FIDOnet and UUCP/Usenet, although it is recognized that these systems are considered by some to part of or associated with the WO 96/08783 2 j 9 9 9 4 2 rcTrUS95/11606 Internet. The payment system described above could also be used on future versions, generations, etc., of the Internet. The payment system could also be used on centrally managed computer systems, such as America Online, Prodigy, etc.
Another aspect of the payment system described above is that it enables users to buy and sell information products over a quasi-public network, such as the Internet, regardless of where the users are located or where the payment system is located. Either the buyer or the seller may be located in the U.S. or outside the U.S.
Also, some or all of the payment system components, such as the front end computer or the back end computer, may be located either in the U.S. or outside the U.S.
is The foregoing detailed description should be regarded as illustrative rather than limiting and the appended claims including all equivalents are intended to define the scope of the invention.

Claims

WHAT IS CLAIMED IS:

1. A system to enable Internet network users to make payments to other Internet network users using an Internet network, the system comprising:
a computer system having stored thereon user accounts for Internet network users, the user accounts including Internet network address information and financial information;
programming code on a computer readable storage medium of the computer system, responsive to receipt of a transaction request from a second Internet network user to request payment from a first Internet network user, to inquire, of the first Internet network user, whether the first Internet network user wishes to authorize a payment associated with a transaction, the transaction request to identify the second Internet network user from a plurality of Internet network users and the transaction; and programming code on a computer readable storage medium of the computer system to process the payment from the first Internet network user using the financial information responsive to notification by the first Internet network user to authorize the payment, the computer system comprising a front end computer and a back end computer.

2. The system of claim 1, wherein the financial information is maintained on the back end computer and the Internet network address information is maintained on the front end computer.

3. The system of claim 2, wherein the back end and the front end communicate by batch processing.

4. The system of claim 1, wherein the computer system includes a program on a computer readable storage medium for communicating with Internet network users, the computer system includes credit card processing information for Internet network users stored thereon, the computer system to connect to a financial transaction system.

5. A system operated by a first party on behalf of a third party for facilitating transactions on an Internet network with a second party, wherein the second party has an address on the Internet network, the system comprising:

a front end computer operated by the first party and connected to the Internet network;
a database on a computer readable storage medium of the front end computer that associates the address of the second party with a transaction identifier, wherein the transaction identifier relates to a potential transaction between the second party and the third party; and a program on a computer readable storage medium of the front end computer that sends and receives messages over the Internet network, the program comprising:
first programming code responsive to receipt of a transaction request from the third party to request payment from the second party automatically prepares and sends a first message over the Internet network to the address of the second party, wherein the first message includes an inquiry of the second party including a presentation of at least one choice to which the second party can make a selection regarding the potential transaction, and further wherein the first message includes the transaction identifier and a second address, and further wherein the transaction request identifies the third party from a plurality of parties and the potential transaction; and second programming code that automatically receives messages over the Internet network sent to the second address, the second programming code adapted to initiate processing of the transaction between the second party and the third party on a back end computer upon a receipt of a second message from the second party directed to the second address and including the transaction identifier and an indication of a selection by the second party from the presentation of at least one choice.

6. The system of claim 5, wherein the program further comprises:
third programming code that automatically prepares and sends a third message over the Internet network to the third party upon receipt of the second message, wherein the third message indicates the selection of second party.

7. A system to facilitate a transaction processed by a payment system, the system including:
a front end computer that is connected to an Internet network;
a database that is connected to the front end computer, the database to associate a transaction identifier with the transaction and information associated with the transaction; and a database that is connected to the front end computer, the database to associate a transaction identifier with the transaction and information associated with the transaction; and a program to operate on the server to send and receive messages over the Internet network, the program comprising:
a first programming code to receive a first message via the Internet network from a first party that includes the transaction identifier that identifies the transaction between the first party and the second party, the first message further including an authorization by the first party to transfer funds from the first party to the second party;
a second programming code to associate the transaction identifier with the transaction and information associated with the transaction;
a third programming code to initiate the transaction on a back end computer on behalf of the second party utilizing the information associated with the transaction to transfer funds from an account associated with the first party to an account associated with the second party;
and prior to receipt of the first message from the first party, a fourth programming code to receive a second message from the second party that is utilized to identify the second party from a plurality of parties and the transaction thereby to trigger the front end computer to communicate a third message to the first party to request the first party to authorize a transfer of funds from the first party to the second party.

8. A computer readable medium storing a set of instructions that, when executed by a front end computer, enable the front end computer to:
receive a transaction request from a second party to request payment from a first party, the transaction request to identify the second party from a plurality of parties and a transaction;
responsive to receipt of the transaction request, inquire, of the first party, whether the first party wishes to authorize a payment associated with the transaction;
receive a first message from the first party that includes a transaction identifier that is associated with the transaction and identifies the transaction between the first party and the second party, the message further including an authorization by the first party to transfer funds from the first party to the second party;

associate the transaction identifier with the transaction and information associated with the transaction; and initiate the transaction on a back end computer on behalf of the second party utilizing the information associated with the transaction to transfer funds from an account associated with the first party to an account associated with the second party, wherein the account associated with the second party includes a currency preference that specifies the type of currency for paying into the account associated with the second party.

9. A machine readable medium storing a set of instructions that, when executed by a front end computer of a first party, enable the front end computer to:
respond to receipt of a transaction request from a third party to request payment from a second party, the response including to send a first message to an address of the second party wherein the first message includes a unique transaction identifier that is associated with a transaction, and further wherein the first message includes a message to provide at least one choice from which the second party can make a selection regarding the transaction, and further wherein the transaction request identifies the third party from a plurality of parties and the transaction;
receive a second message from the second party directed to a reply address, the second message including the unique transaction identifier and a selection of the second party; and initiate processing of the transaction on a back end computer based upon the selection by the second party.

10. A machine readable medium storing a set of instructions that, when executed by a front end computer, enable the front end computer to:
receive a request via the Internet network from a second user to process a payment of money from a first user to the second user, the request to include information provided by the first user to the second user, wherein the request identifies the second user from a plurality of users and a transaction;
utilize the information in the request to prepare a message for the first user;

send the message to inquire, of the first user via the Internet network, whether the first user wishes to authorize a payment of money to the second user, the payment of money associated with the transaction; and process the payment of money from the first user on a back end computer if the first user authorizes the payment of money via the Internet network responsive to the inquiry message sent to the first user.

11. A machine readable medium storing a set of instructions that, when executed by a front end computer, enable the front end computer to:
inquire via an Internet network of a first user whether the first user wishes to pay a second user, the inquiry responsive to receipt of transaction request from the second user, the transaction request to identify the second Internet network user from a plurality of Internet network users and a transaction;
inform the second user, via the Internet network, whether the first user wishes to pay the second user; and process a payment of money from the first user to the second user on a back end computer if the first user wishes to pay the second user.

12. A machine readable medium storing a set of instructions that, when executed by a back end computer, enable the back end computer to:
maintain accounts for users of an Internet network, the accounts to include:
payment processing information for the users; and payment histories of the users;
receive requests from some users to process payments from other users, wherein each request identifies a first user from the some users and a transaction,wherein the respective requests are responsive to a front end computer to:
inquire of the other users whether the other users wish to authorize the payments requested to be processed by the some users;
receive responses from at least a portion of the other users; and process payments from those users of the portion of other users that authorize payment responsive to the inquires using the payment processing information.

13. A machine readable medium storing a set of instructions that, when executed by a front end computer, enable the front end computer to:
receive a first message over an Internet network from the merchant, the first message to identify the merchant from a plurality of merchants and a transaction;
look up, in a database participant information associated with message information included in the first message;
send a second message to the buyer to inquire of the buyer whether the buyer wishes to authorize payment associated with the transaction;
receive a third message from the buyer to authorize payment;
send a fourth message to the merchant that indicates receipt of authorization;
request a back end computer to transfer a first amount of funds from the buyer to the back end computer;
send a pay-in notification to the buyer;
request the back end computer to transfer a second amount of funds from the back end computer to the merchant; and send a payout notification to the merchant.

14. A machine readable medium storing a set of instructions that, when executed by a front end computer, enable the front end computer to:
receive a first message over an Internet network from a first user, the first message to identify the first user from a plurality of users and a transaction between the first user and a second user, the transaction to involve a payment from the second user to the first user;
send a second message over the Internet network to the second user, the second message to inquire of the second user whether the second user wishes to authorize a payment of money to the first user; and receive a third message over the Internet network from the second user, the third message to indicate whether the second user authorizes the payment of money to the first user, the payment of money to be processed on a back end computer.

15. The system of claim 14, wherein the second message includes a sender's address.

16. The system of claim 14, wherein the second message is at least one of an e-mail message and an HTTP message.

17. The system of claim 14, wherein the first message is at least one of an email message and an HTTP message.

18. The system of claim 14, wherein the second message includes user information.

19. The system of claim 14, wherein the first message further includes an identification of the transaction and a money amount of the transaction.

20. The system of claim 14, wherein the first message includes a first user's identification number.

21. The system of claim 14, wherein the first message includes a buyer cardnumber and a seller cardnumber.

22. A machine readable medium storing a set of instructions that, when executed by a front end computer, enable the a front end computer to:
receive a first message over an Internet network from a first user wherein the first message identifies the first user from a plurality of users and a transaction between the first user and a second user;
send a second message over the Internet network to the second user, the second message to inquire of the second user whether the second user wishes to authorize a payment of money associated with the identified transaction with the first user; and receive a third message over the Internet network from the second user, the third message to indicate whether the second user authorizes a payment of money associated with the identified transaction, the payment of money to be processed on a back end computer.

23. A machine readable medium storing a set of instructions that, when executed by a front end computer, enable the front end computer to:

receive a first message over the Internet network from a first user, the first message to identify the first user from a plurality of users and a transaction between the first user and a second user and to include message information;
associate the message information received with the first message with user information;
send a second message over the Internet network to a second user's address, the second message to inquire of the second user whether the second user wishes to authorize a payment associated with the transaction with the first user; and responsive to receipt of a third message over the Internet network from the second user to indicate authorization of the payment associated with the transaction, send an indication of such authorization to a back end computer off the Internet network to process the payment associated with the transaction.

24. The system of claim 23, wherein the user information includes a first user's Internet network address.

25. The system of claim 23, wherein the user information includes a buyer name and a seller name.

26. A system to enable a seller to receive a payment that is authorized by a buyer, the system including:
a front end program on a front end computer, responsive to receipt of a transaction request from a seller to request payment from a buyer, to inquire, of the buyer, whether the buyer wishes to authorize a payment associated with a transaction, the transaction request to identify the seller from a plurality of users and the transaction, the front end program to receive a message from the buyer, over a Internet network, wherein the message includes a transaction identifier that is associated with the transaction and an authorization from the buyer for the payment, the front end program to associate the transaction identifier with the buyer, wherein a credit card account that is associated with the buyer is administered by a credit card company that requires a merchant account to receive the payment, and wherein the seller does not have the merchant account to receive the payment; and a back end program on a back end computer to post a charge to a settlement system that causes the settlement system to transfer the payment from the credit card account associated with the buyer to the merchant account of a third party; the back end program to further transmit information to the settlement system that causes the settlement system to transfer the payment from the merchant account of the third party to an account associated with the seller.

27. The system of claim 26, wherein the merchant account includes an Internet network merchant account.

28. The system of claim 26, wherein the back end program suspends buyer activity if payment cannot be made from the credit card account associated with the buyer.

29. The system of claim 28, further including the front end program to send a notice to the buyer if payment cannot be made from the credit card account associated with the buyer.

30. The system of claim 29, wherein the notice includes an email message.

31. The system of claim 26, further including the front end program to send a notice to the buyer that payment was successfully made from the credit card account associated with the buyer.

32. The system of claim 31, wherein the notice includes an email message.

33. The system of claim 26, wherein the account associated with the seller includes a checking account.

34. The system of claim 26, further including the front end program to send a notice to the seller that payment has been successfully made to the account associated with the seller.

35. The system of claim 26, further including the front end program to send a first notice to the seller and a second notice to the buyer responsive to a detection of a chargeback transaction.

36. A machine readable medium storing a set of instructions that, when executed by a front end computer, enable the front end computer to:
receive a transaction request from a seller to request payment from a buyer, the transaction request to identify the seller from a plurality of users and a transaction;
responsive to receipt of the transaction request, to inquire, of the buyer, whether the buyer wishes to authorize a payment associated with the transaction;
receive a message from the buyer, over a Internet network, wherein the message includes a transaction identifier associated with the transaction and an authorization from the buyer for the payment; and send the authorization to a back end computer to:
associate the transaction identifier with the buyer, wherein a credit card account that is associated with the buyer is administered by a credit card company that requires a merchant account to receive the payment, and wherein the seller does not have the merchant account to receive the payment, post a charge to a settlement system that causes the settlement system to transfer the payment from the credit account associated with the buyer to the merchant account of a third party, transmit information to the settlement system that causes the settlement system to transfer the payment from the merchant account of the third party to an account associated with the seller.