U.S. patent application number 12/758711 was filed with the patent office on 2011-06-09 for computerized system for facilitating transactions between parties on the internet using e-mail.
Invention is credited to Nathaniel S. Borenstein, Marshall T. Rose, Einar A. Stefferud, Lee H. Stein.
Application Number | 20110137751 12/758711 |
Document ID | / |
Family ID | 23192549 |
Filed Date | 2011-06-09 |
United States Patent
Application |
20110137751 |
Kind Code |
A1 |
Stein; Lee H. ; et
al. |
June 9, 2011 |
COMPUTERIZED SYSTEM FOR FACILITATING TRANSACTIONS BETWEEN PARTIES
ON THE INTERNET USING E-MAIL
Abstract
A payment system and method are disclosed for processing
financial exchanges over a network between a merchant and a buyer.
For example, receiving from a merchant, over the network,
information associated with a financial transaction and
non-financial data relating to a buyer involved in the financial
transaction. Authorizing payment, associated with the financial
transaction, to the merchant on behalf of the buyer using the
non-financial data related to the buyer. A notification of the
authorized payment on behalf of the buyer is sent to the merchant
over the network. Upon notification from the merchant that the
buyer has committed to completing the financial transaction,
processing payment to the merchant on behalf of the buyer.
Inventors: |
Stein; Lee H.; (Rancho Santa
Fe, CA) ; Stefferud; Einar A.; (Huntington Beach,
CA) ; Borenstein; Nathaniel S.; (Morristown, NJ)
; Rose; Marshall T.; (Mountain View, CA) |
Family ID: |
23192549 |
Appl. No.: |
12/758711 |
Filed: |
April 12, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10461604 |
Jun 12, 2003 |
|
|
|
12758711 |
|
|
|
|
09074354 |
May 7, 1998 |
6246996 |
|
|
10461604 |
|
|
|
|
08308101 |
Sep 16, 1994 |
5826241 |
|
|
09074354 |
|
|
|
|
Current U.S.
Class: |
705/26.43 ;
705/26.1; 705/26.41; 705/44 |
Current CPC
Class: |
G06Q 30/0613 20130101;
G06Q 20/40 20130101; G06Q 30/018 20130101; G07F 17/0014 20130101;
G06Q 30/0617 20130101; G06Q 30/00 20130101; G06Q 30/0601 20130101;
G06Q 20/12 20130101; G09B 5/00 20130101; G06Q 20/02 20130101; G06Q
10/00 20130101; G06Q 20/2295 20200501; G06Q 20/10 20130101; G06Q
30/0633 20130101; G07F 17/16 20130101; G06Q 20/04 20130101 |
Class at
Publication: |
705/26.43 ;
705/44; 705/26.41; 705/26.1 |
International
Class: |
G06Q 30/00 20060101
G06Q030/00; G06Q 20/00 20060101 G06Q020/00 |
Claims
1. A method for completing a financial transaction over a network,
the method comprising: receiving a request from a user over the
network to complete a financial transaction; requesting
non-financial user information to be used to complete the financial
transaction; receiving the non-financial user information over the
network; sending the non-financial user information and information
related to the financial transaction to a third-party system;
approving the financial transaction based on receiving
authorization from the third-party system; and receiving payment
from the third-party system on behalf of the user in relation to
the financial transaction.
2. The method of claim 1, wherein the financial transaction
involves the purchase of a good or service from a seller.
3. The method of claim 1, wherein the receiving of the
non-financial user information includes receiving approval from the
user for the third-party system to complete the financial
transaction on behalf of the user.
4. The method of claim 3, wherein the approval from the user for
the third-party system to complete the financial transaction
includes approval from the user to have the third-party system send
a bill to the user for the financial transaction.
5. The method of claim 4, wherein the sending of the bill to the
user is accomplished via conventional mail delivery.
6. The method of claim 1, wherein the receiving of the payment from
the third-party system is accomplished without using the
network.
7. The method of claim 1, wherein the network is the Internet.
8. A method of processing a financial exchange over a network, the
method comprising: receiving from a merchant, over the network,
information associated with a financial transaction and
non-financial data relating to a buyer involved in the financial
transaction with the merchant; using the non-financial data
relating to the buyer to authorize payment to the merchant on
behalf of the buyer in relation to the financial transaction;
sending to the merchant, over the network, a notification of the
authorized payment on behalf of the buyer; and processing payment
to the merchant on behalf of the buyer upon notification from the
merchant that the buyer committed to completing the financial
transaction.
9. The method of claim 8, wherein the processing of the payment to
the merchant includes receiving approval from the buyer regarding
the financial transaction with the merchant.
10. The method of claim 8, wherein the processing or the payment to
the merchant is accomplished without using the network.
11. The method of claim 8, wherein the processing of the payment to
the merchant includes sending a bill to the buyer.
12. The method of claim 11, wherein the sending of the bill to the
buyer is accomplished without using the network.
13. The method of claim 8, wherein the processing of the payment to
the merchant includes charging a service fee.
14. A system for completing a financial transaction over a network,
the system comprising: a payment processing system to process
payments related to financial transactions conducted over the
network using a user-identifying piece of non-financial data
provided in association with the financial transaction; and a
network-based transaction system, connected to the network and the
payment processing system, including: a front-end communications
module to send and receive communications with a user over the
network; and a back-end communications module to send and receive
communications with the payment processing system; wherein: the
front-end communications module is to receive a request from the
user to process a financial transaction, the request including the
user-identifying piece of non-financial data associated with the
request, the back-end communications module is to send the
user-identifying piece of non-financial data and information
related to the financial transaction to the payment processing
system, and the payment processing system is to process a payment
on behalf of the user.
15. The system of claim 14, wherein the financial transaction
involves a purchase of a good or service from the network-based
transaction system.
16. The system of claim 14, wherein the front-end communications
module is further to receive an approval from the user for the
payment processing system to complete the financial transaction on
behalf of the user.
17. The system of claim 16, wherein the approval from the user for
the payment processing system to complete the financial transaction
includes approval from the user to have the payment processing
system send a bill to the user for the financial transaction.
18. The system of claim 17, wherein the payment processing system
is to send the user a bill without using the network.
19. The system of claim 14, wherein the network-based transaction
system is to receive payment from the payment processing system
without using the network.
20. The system of claim 14, wherein the network is the
Internet.
21. The system of claim 20, wherein the network-based system is
connected to the payment processing system over the Internet.
Description
RELATED APPLICATIONS
[0001] This application is a continuation of Reissue Application
No. 10/461,604, filed Jun. 12, 2003, which is a Reissue of U.S.
Pat. No. 6,246,996, issued Jun. 12, 2001, which is a continuation
of U.S. Pat. No. 5,826,241, issued on Oct. 20, 1998, all of which
are incorporated herein by reference in their entirety.
BACKGROUND OF THE INVENTION
[0002] 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.
[0003] 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.
[0004] 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.
[0005] 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 available. Given
that the cost of inventory on the Internet is close to 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.
[0006] 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.
[0007] 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
[0008] According to a first embodiment of the present invention,
there is provided a method and payment system 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 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 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 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
[0009] 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:
[0010] FIG. 1 is a block diagram illustrating the relationship
between a payment system of a first embodiment of the present
invention to a large network.
[0011] FIG. 2 is a block diagram of a hardware configuration for
the payment system of FIG. 1.
[0012] FIG. 3 is a block diagram of the program arrangement of the
payment system of FIG. 1;
[0013] FIG. 4 is a diagram of data for a cardholder account for use
with the payment system of FIG. 1;
[0014] FIG. 5 is a flow chart showing message flow for the initial
steps of a funds transaction using the payment system of FIG.
1;
[0015] FIGS. 6A-6Q are diagrams of data messages used in connection
with the payment system of FIG. 1;
[0016] FIG. 7 is a flow chart showing the message flow for a
cardholder inquiry request using the payment system of FIG. 1;
[0017] FIG. 8 is a flow chart showing the message flow for a
transfer query request and reply using the payment system of FIG.
1;
[0018] FIG. 9 is a flow chart showing the message flow for payment
failure using the payment system of FIG. 1;
[0019] FIG. 10 is a flow chart showing the message flow for payment
notification using the payment system of FIG. 1;
[0020] FIG. 11 is a flow chart showing message flow for a
chargeback process using the payment system of FIG. 1;
[0021] FIG. 12 is a flow chart showing message flow for a
capabilities request process using the payment system of FIG. 1;
and
[0022] FIG. 13 is a message flow diagram showing messages for a new
account transaction between a user and the payment system of FIG.
1.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
I. Overall System
[0023] FIG. 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 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 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 e-mail based systems having a plurality of users.
[0024] In the embodiment of FIG. 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, 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
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 FIG. 1 shows only one information seller 28 and one
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.
[0025] Also shown in FIG. 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
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.
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.
[0026] FIG. 2 is a block diagram illustrating one possible
configuration of hardware components used to implement the payment
system 10 of FIG. 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 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 T1 line 69.
[0027] 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.
[0028] 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 17'' monitors. The front
end and back end tape drives are Python SGB tape drives using 4 mm
tape available from Sony, Inc. The front end disk drive 58 and the
back end disk drive 72 are commercially available Seagate 1.7 GB
disk drives. The host adaptor is a Sun Microsystems SBus host
adaptor. The network server is a commercially available Sun
Microsystems SSarray 101.
[0029] Referring to FIG. 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.
[0030] 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 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.
II. Requirements of a Subscriber
[0031] 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 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.
[0032] Referring to FIG. 4, a cardholder account 100 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.
[0033] 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
financial artifact, such as a credit cardnumber, a checking account
number, nor to any e-mail address.
[0034] The cardholder Internet e-mail address 104 is the e-mail
address of the cardholder that is unique for each user of the
Internet.
[0035] The state 106 is one of "active", "suspended", or,
"invalid".
[0036] 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 from the cardnumber.
[0037] 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 in or directly derivable from the
cardnumber.
[0038] 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.
[0039] Subscriber account information is distributed in the payment
system 10. Referring again to FIG. 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 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 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.
[0040] Specifically with respect to the items of information in a
cardholder account, located on the storage device 58 associated
with the front end computer 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 computer 50
does not contain any of the pay-in 108 or pay-out 110 information,
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
computer 52
[0041] 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 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 various other operating systems.
Listings of code for the front end program 90 and the user
interface program 118 are included at appendices A and B,
repectively. A publication entitled "The application/green-commerce
MIME Content-type" is included at appendix C and 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
[0042] 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 described below.
A. Funds Transfer Transaction
[0043] 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 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.
[0044] 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.
[0045] FIG. 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
("102B"=cardnumber "102"+buyer "B"), as illustrated in FIG. 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
[0046] 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.
[0047] Referring to FIG. 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 FIG.
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 FIG. 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.
[0048] 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)
[0049] Referring again to FIG. 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
transfer-request message 129 may be sent by either e-mail or using
an interactive protocol on the Internet 12. Referring to FIG. 6D,
the transfer-request message 129 contains the following
information: the buyer cardnumber 102B, the seller cardnumber 102S,
a transfer type 130 (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.
[0050] After receiving the transfer-request message 129, 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 FIG. 8. Using the
information 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 FIG. 6E,
the transfer-query message 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 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 transfer 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 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 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.
[0051] The buyer 20 may respond by sending a transfer-response
message 150 to the front end computer 50 via the Internet, as shown
in FIG. 8. As illustrated in FIG. 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 willingness indication
152 is one of "yes", "no", or, "fraud".
[0052] 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 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" 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 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 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, "fraud").
[0053] Referring again to FIG. 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 FIG. 6G, the transfer-result message 160
contains the 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.
[0054] Referring back to the step shown in FIG. 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 that
the cardholder account information on the back end computer 52
conforms to that on the front end computer 50.
[0055] Referring again back to the step shown in FIG. 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.
[0056] Referring back to the step illustrated in FIG. 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 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
[0057] 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.
[0058] Referring to FIGS. 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.
[0059] 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 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".
[0060] Referring to FIG. 9, the front end program 90 then sends a
payin-failure-notification message 210 to the buyer 20 over the
Internet. As shown in FIG. 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.
[0061] 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 FIG. 6I, this
collection-failure-notification message 211 contains the server's
transaction-identifier 138, and the amount 134 and currency 112
associated with the transaction.
[0062] 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.
[0063] 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. 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.
[0064] 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 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 FIG. 10. As shown in FIG. 6J, the
payin-notification message 212 contains the cardnumber 102, the
pay-in amount 134 in the currency 112 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
[0065] Referring to FIG. 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 back end computer 52.
[0066] 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.
[0067] 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.
[0068] In addition to sending the information to the 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 FIG.
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
[0069] 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. FIG. 11 shows the message flow for a chargeback
transaction having the following steps:
[0070] The front end program 90 sends a
payin-chargeback-notification message 220 to the buyer 20 over the
Internet. As shown in FIG. 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.
[0071] Also as shown in FIG. 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 FIG. 6M, the
payout-chargeback-notification message 222 contains the server's
transaction-identifier 138, the amount 134, and the currency 112
charged back to the buyer 20.
E. Payment System Capability Transaction
[0072] A payment system capability transaction occurs when a user
wishes to ascertain the capabilities of a payment system 10. FIG.
12 shows the message flow for a payment system capability
transaction having the following steps:
[0073] A user 14 uses the Internet 12 to send a
capabilities-request message 224 to the payment system 90. As shown
in FIG. 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 226 to the user 14. As shown in FIG. 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 Application
[0074] A cardholder application transaction occurs when an Internet
user 14 wishes to establish a cardholder account 100. FIG. 13 shows
the steps for the application process for a cardholder
application.
[0075] 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 FIG. 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.
[0076] The user 14 fills in parameters from the 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 FIG. 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.
[0077] 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
[0078] 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.
[0079] 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 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
[0080] 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.
[0081] 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.
[0082] 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 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.
[0083] 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.
[0084] 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.
* * * * *