U.S. patent application number 12/616440 was filed with the patent office on 2010-03-04 for digital active advertising.
This patent application is currently assigned to Soverain Software LLC. Invention is credited to David K. Gifford.
Application Number | 20100057561 12/616440 |
Document ID | / |
Family ID | 22611825 |
Filed Date | 2010-03-04 |
United States Patent
Application |
20100057561 |
Kind Code |
A1 |
Gifford; David K. |
March 4, 2010 |
Digital Active Advertising
Abstract
A complete system for the purchasing of goods or information
over a computer network is presented. Merchant computers on the
network maintain databases of digital advertisements that are
accessed by buyer computers. In response to user inquiries, buyer
computers retrieve and display digital advertisements from merchant
computers. A digital advertisement can further include a program
that is interpreted by a buyer's computer. The buyer computers
include a means for a user to purchase the product described by a
digital advertisement. If a user has not specified a means of
payment at the time of purchase, it can be requested after a
purchase transaction is initiated. A network payment system
performs payment order authorization in a network with untrusted
switching, transmission, and host components. Payment orders are
backed by accounts in an external financial system network, and the
payment system obtains account authorizations from this external
network in real-time. Payment orders are signed with authenticators
that can be based on any combination of a secret function of the
payment order parameters, a single-use transaction identifier, or a
specified network address.
Inventors: |
Gifford; David K.; (Weston,
MA) |
Correspondence
Address: |
PATENT GROUP 2N;JONES DAY
NORTH POINT, 901 LAKESIDE AVENUE
CLEVELAND
OH
44114
US
|
Assignee: |
Soverain Software LLC
|
Family ID: |
22611825 |
Appl. No.: |
12/616440 |
Filed: |
November 11, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09711511 |
Nov 14, 2000 |
|
|
|
12616440 |
|
|
|
|
09033143 |
Mar 2, 1998 |
6195649 |
|
|
09711511 |
|
|
|
|
08563745 |
Nov 29, 1995 |
5724424 |
|
|
09033143 |
|
|
|
|
08168519 |
Dec 16, 1993 |
|
|
|
08563745 |
|
|
|
|
Current U.S.
Class: |
705/14.49 ;
705/14.73 |
Current CPC
Class: |
G06Q 20/023 20130101;
G06Q 20/12 20130101; G06Q 30/0601 20130101; G06Q 20/027 20130101;
G06Q 30/0253 20130101; G06Q 30/0277 20130101; G06Q 30/0251
20130101; G06Q 20/385 20130101; G06Q 30/06 20130101; G06Q 30/02
20130101; G06Q 20/04 20130101; G06Q 20/02 20130101; G06Q 20/401
20130101; G06Q 30/0609 20130101; G06Q 10/087 20130101; G07F 7/00
20130101; G06Q 20/085 20130101; G06Q 20/10 20130101 |
Class at
Publication: |
705/14.49 ;
705/14.73 |
International
Class: |
G06Q 30/00 20060101
G06Q030/00; G06Q 20/00 20060101 G06Q020/00 |
Claims
1. A network sales system comprising a plurality of buyer computers
and at least one merchant computer interconnected by a
communications network, means at each merchant computer for
maintaining and providing a database of digital advertisements
comprising means for storing said digital advertisements, each
digital advertisement including a product abstract, means for
communicating a digital advertisement to a buyer computer over said
network in response to a network request from said buyer computer,
means at each buyer computer for requesting, displaying, and
responding to digital advertisements comprising means responsive to
a user inquiry for selecting a merchant computer and obtaining a
digital advertisement for a product from said database of
advertisements at said merchant computer, display means for
displaying said advertisement, purchase means responsive to a user
request for communicating a purchase message to said merchant
computer, account identification means for transmitting the user's
account information to said merchant computer, means, at said
merchant computer, comprising authorization means to authorize said
purchase message by sending messages into a financial system
network, fulfillment means to send said product to user conditional
on approval of said authorization means.
2. The network sales system of claim 1 further wherein said
authorization means at said merchant computer comprises means for
communicating a missing payment information request message to said
buyer computer to obtain missing payment information, means for
receiving said missing payment information from said buyer
computer, means for authorizing said purchase message by sending
messages into a financial system network, and said account
identification means at said buyer computer comprises means
responsive to said missing payment information request message to
query the user for additional payment information, means to send
said additional payment information to said merchant computer.
3. The network sales system of claim 1 further wherein said account
identification means comprises means for assembling a payment
order, means for sending said payment order to a network payment
system for authorization, and wherein said authorization means
comprises means for verifying that said payment order has been
previously authorized by said payment system.
4. An electronic sales system comprising means for storing a
database of digital advertisements, each digital advertisement for
a product including a program, means for communicating a digital
advertisement to a buyer computer, means at said buyer computer for
displaying and responding to said digital advertisement comprising
display means for displaying said digital advertisement by
executing a portion of said advertisement as a program and
performing actions as specified by said program, purchase means
responsive to a user request for communicating a purchase message
to a merchant computer, means, at said merchant computer,
comprising fulfillment means to send said product to user.
5. An electronic sales system comprising means for storing a
database of digital advertisements, each digital advertisement for
a product including a program, packet-switched means for
communicating a digital advertisement to a buyer computer, means at
said buyer computer for displaying and responding to said digital
advertisement via packet-switched network, comprising display means
for displaying said digital advertisement by executing a portion of
said advertisement as a program and performing actions as specified
by said program, purchase means responsive to a user request for
communicating a purchase message to a merchant computer over a
packet-switched network, means, at said merchant computer,
comprising fulfillment means to send said product to user.
Description
[0001] This application is a continuation of U.S. patent
application Ser. No. 09/711,511, filed on Nov. 14, 2000, and
entitled "Digital Active Advertising," which is a continuation of
U.S. patent application Ser. No. 09/033,143, filed on Mar. 2, 1998,
now U.S. Pat. No. 6,195,649, entitled "Digital Active Advertising,"
which is a continuation of U.S. patent application Ser. No.
08/563,745, filed on Nov. 29, 1995, now U.S. Pat. No. 5,724,424,
entitled "Digital Active Advertising," which is a continuation of
U.S. patent application Ser. No. 08/168,519, filed on Dec. 16,
1993, entitled "Digital Active Advertising," the entirety of each
of which is herein incorporated by reference.
BACKGROUND
[0002] The recent rapid growth of information applications on
international public packet-switched computer networks such as the
Internet suggests that public computer networks have the potential
to establish a new kind of open marketplace for goods and services.
Such a marketplace could be created with a network sales system
that comprises a plurality of buyer and merchant computers, means
for the users of the buyer computers to display digital
advertisements from the merchant computers, and means for the users
to purchase products described by the advertisements.
[0003] A network based sales system will need to allow users to
preview products at little or no cost, and will need to make a
large number of product advertisements available in a convenient
manner. In addition, the shopping system will need to include
easy-to-use facilities for a user to purchase desired products
using a merchant independent payment method. In addition the
network sales will need to allow new buyers and merchants to enter
the market.
[0004] A central requirement for a marketplace is a payment
mechanism, but at present no merchant independent payment mechanism
is available for computer networks that permits users to utilize
conventional financial instruments such as credit cards, debit
cards, and demand deposit account balances. We expect that both
retail payment and wholesale payment mechanisms will be required
for networks, with consumers using the retail mechanism for modest
size purchases, and institutions using the wholesale mechanism for
performing settlement between trading partners. For wide acceptance
the retail mechanism will need to be a logical evolution of
existing credit-card, debit-card, and Automated Clearing House
facilities, while for acceptance the wholesale mechanism will need
to be an evolved version of corporate electronic funds
transfer.
[0005] These problems of have been approached in the past by
network based sales systems wherein, for example, each merchant
maintains an account for each user. A user must establish an
account with each merchant in advance in order to be able to
utilize the merchant. The prior art network based sales systems are
not designed to allow users to use their existing credit card and
demand deposit accounts for payment, nor are they designed to allow
for programs to be included in digital advertisements.
[0006] According, therefore, it is a primary objective of this
invention to provide a user interactive network sales system in
which the user can freely use any merchant of choice and utilize
existing financial instruments for payment. Other objects include a
network sales system which provides a high-quality user interface,
which provides users with a wide variety and large volume of
advertisements, which is easily extensible to new services, and
which is easily expanded to new applications within the existing
infrastructure of the system.
[0007] Still other objects of the invention are to provide a
network payment system that will authorize payment orders and
remove part of the risk of fraud from merchants.
[0008] An unavoidable property of public computer networks is that
they are comprised of switching, transmission, and host computer
components controlled by many individuals and organizations. Thus
it is impossible for a network payment system to depend upon a
specified minimum required degree of software, hardware, and
physical security for all of the components in a public network.
For example, secret keys stored in a given user's personal computer
can be compromised, switches can be tampered with to redirect
traffic, and transmission facilities can be intercepted and
manipulated.
[0009] The risk of performing retail payment in a public network is
compounded by statutes that make a payment system operator in part
liable for the security lapses of its users. Existing Federal
statutes in the United States, including the Electronic Funds
Transfer Act and the Consumer Credit Protection Act, require the
operator of a payment mechanism to limit consumer liability in many
cases. Payment system operators may have other fiduciary
responsibilities for wholesale transactions. Similar
responsibilities exist in other countries for retail and wholesale
transactions.
[0010] In existing credit card payment systems, a credit card's
issuing bank takes on the fraud risk associated with misuse of the
card when a merchant follows established card acceptance protocols.
Acceptance protocols can include verifying a card holder's
signature on the back of their card and obtaining authorization for
payments over a certain value. However, in network based commerce a
merchant can not physically examine a purchasers credit card, and
thus the fraud risk may revert to the merchant in so called "card
not present" transactions. Many merchants can not qualify to take
this risk because of their limited financial resources. Thus the
invention is important to allow many merchants to participate in
network based commerce.
[0011] Other objects of the invention include utilizing existing
financial instruments such as credit cards, debit cards, and demand
deposit accounts for merchant payments.
[0012] Existing network payment systems do not connect to the
financial system for authorization and are not compatible with
conventional financial instruments. Existing network payment
systems include the Simple Network Payment Protocol [Dukach, S.,
SNPP: A Simple Network Payment Protocol, MIT Laboratory for
Computer Science, Cambridge, Mass., 1993.], Sirbu's Internet
Billing Server [Sirbu, M. A., Internet Billing Service Design and
Prototype Implementation, Information Networking Program,
Carnegie-Mellon University, 1993], and NetCash [Medvinsy, G., and
Newman, B. C., NetCash: A Design for Practical Electronic Currency
on the Internet, Proc. 1st ACM Conf. on Comp. and Comm. Security,
November, 1993].
[0013] A further object of the invention is to allow users in an
untrusted network environment to use conventional financial
instruments without requiring modification to existing financial
system networks.
[0014] The following definitions apply to the present invention. A
principal is a person, company, institution, or other entity that
is authorized to transact business as part of a network payment
system. A payment order describes the identity of a sender, a
payment amount, a beneficiary, and a sender unique once. A sender
is a principal making a payment. A beneficiary is a principal to be
paid by the payment system. A sender unique nonce is an identifier
that is used only once by a given sender. An example of sender
unique nonces are unique timestamps. An external account is an
account that can be used to settle a payment order for either a
sender or a beneficiary in the external financial system. Examples
of external accounts include demand deposit accounts and credit
card accounts. An external device is a physical object that is kept
in the possession of a user for the purpose of identifying the
user.
[0015] A network payment system is a service that authorizes and
executes digital payment orders that are backed by external
accounts. A payment system authenticates a payment order, checks
for sufficient funds or credit, and then originates funds transfer
transactions to carry out the payment order. A payment system
acknowledges acceptance or rejection of a payment order. More than
one payment system may exist on a given network, and a given
payment system may operate on more than one host to increase its
reliability, availability, and performance. An authenticator is a
digital value that is appended to a payment order and becomes part
of the payment order that authenticates the payment order as
genuine.
SUMMARY
[0016] The invention relates to a network sales system for enabling
users to purchase products using a plurality of buyer computers
that communicate over a network with a plurality of merchant
computers. Each merchant computer has a database of digital
advertisements. Each digital advertisement includes a price and a
product abstract. Buyer computers request, display, and respond to
digital advertisements from merchant computers. Users can purchase
products with their buyer computers after they have specified an
account to pay for the purchase. A network payment service is used
to authorize the purchase before merchant fulfillment is
performed.
[0017] In a particular aspect of the invention, the merchant
computer can request account information when it is not provided by
the buyer computer. In another aspect of the invention, the buyer
computer can present to a merchant a pre-authorized payment order
that is obtained from a network payment system.
[0018] In another aspect of the invention, an electronic sales
system contains digital advertisements that include programs. The
programs are executed on behalf of a user by a buyer computer, and
can lead to a purchase request directed to a merchant computer that
performs product fulfillment.
[0019] In another aspect of the invention a network payment system
executes payment orders. A payment order includes a sender, a
beneficiary, a payment amount, and a nonce identifier. A payment
order is signed by a client computer with an authenticator that is
checked by the payment system. Payment orders are backed by
accounts in the banking system, and are authorized by the network
payment system by sending messages into a financial authorization
network that knows the status of these accounts. The payment system
accomplishes settlement by sending messages into an existing
financial system network.
[0020] In another aspect, payment orders are authenticated based on
the delivery address they specify. In another aspect, the payment
system will specify in its authorization legal delivery addresses.
In another aspect, authenticators for payment orders are based on
one-time transaction identifiers that are known only to the user
and the payment system. In another aspect, payment orders for a
given sender are only accepted from certain client computer network
addresses. In another aspect, the network payment system sends
messages into a financial authorization system in real-time before
the network payment system will authorize a payment order.
BRIEF DESCRIPTION OF THE DRAWINGS
[0021] Other objects, features, and advantages of the invention
will appear from the following description taken together with the
drawings in which:
[0022] FIG. 1 is a block diagram of a typical network sales system
in accordance with the invention;
[0023] FIG. 2 is a screen snapshot of a buyer computer display of
an overview page from a merchant computer;
[0024] FIG. 3 is a screen snapshot of a buyer computer display of a
page of digital advertisements from a merchant computer;
[0025] FIG. 4 is a screen snapshot of a buyer computer display of
an account query page;
[0026] FIG. 5 is a screen snapshot of a buyer computer display of a
fulfillment page;
[0027] FIG. 6 is a flow chart illustrating the processing of a sale
between a buyer computer and a merchant computer;
[0028] FIG. 7 is a flow chart illustrating the alternate processing
of payment order means for obtaining missing payment
information;
[0029] FIG. 8 is a screen snapshot of a buyer computer display of
an overview page from a merchant computer that contains a query
input by the user;
[0030] FIG. 9 is a screen snapshot of a buyer computer display of
digital advertisements in response to a user's query;
[0031] FIG. 10 is a screen snapshot of a buyer computer screen of a
purchase confirmation;
[0032] FIG. 11 is a screen snapshot of a buyer display of a
fulfillment page like FIG. 5;
[0033] FIG. 12 is a flow chart illustrating an alternate processing
of a sale between a buyer computer and a merchant computer where a
payment order is pre-authorized;
[0034] FIG. 13 is a block diagram of a typical network payment
system in accordance with the invention;
[0035] FIG. 14 is a flow chart illustrating the authentication,
authorization, and settlement of a payment order;
[0036] FIG. 15 is a flow chart illustrating an alternate processing
of the authentication and verification of a payment order where
transaction identifiers are used; and
[0037] FIG. 16 is a flow chart illustrating an alternate processing
of the authorization of a payment order where real-time approval
from the financial authorization network may not be obtained.
DESCRIPTION OF A PARTICULAR PREFERRED EMBODIMENT
[0038] A network sales system 200 as shown in FIG. 1 employs a
network 67 to interconnect a plurality of buyer computers 61 and
62, merchant computers 63 and 64, each merchant computer with
respective digital advertisement databases 65 and 66, and a payment
computer 68. A user of the system employs a buyer computer to
retrieve advertisements from the merchant computers, and to
purchase goods of interest. A payment computer is used to authorize
a purchase transaction.
[0039] A digital advertisement includes a product description and a
price. In digital advertisement database 65 prices and descriptions
may be stored separately, and one price may apply to many product
descriptions.
[0040] In an alternate embodiment, the network sales system further
includes external devices that are kept in the possession of users
so that the users can authenticate themselves when they use a buyer
computer.
[0041] The software architecture underlying the particular
preferred embodiment is based upon the hypertext conventions of the
World Wide Web. Appendix A describes the Hypertext Markup Language
(HTML) document format used to represent digital advertisements,
Appendix B describes the HTML forms fill out support in Mosaic 2.0,
Appendix C is a description of the Hypertext Transfer Protocol
(HTTP) between buyer and merchant computers, and Appendix D
describes how documents are named with Uniform Resource Locators
(URLs) in the network of computers. A document is defined to be any
type of digital data broadly construed, such as multimedia
documents that include text, audio, and video, and documents that
contain programs.
[0042] FIG. 2 shows an overview screen that has been retrieved from
a merchant computer by a buyer computer and displayed by the buyer
computer. It includes links 1, 2, and 3 that when activated by a
user cause the buyer's computer to take specified actions. In the
case of link 1, the document shown in FIG. 3 is retrieved from a
merchant computer and displayed. In the case of link 2, a short
audio segment is retrieved from a merchant computer and played. In
the case of link 3, the query that can be entered into the query
dialog box 4 is sent to a merchant computer, and a document is
retrieved from the merchant computer and displayed.
[0043] FIG. 3 shows a document that contains three digital
advertisements. The digital advertisements have been retrieved from
the merchant computer after the activation of link 3. The merchant
computer may set the prices contained in the advertisements based
on the on the identity of the user as determined, for example, by
the network address of the requesting buyer computer. The document
includes links 5, 6, and 7 that are used to purchase the products
described by the advertisements. For example, if link 5 is
activated the missing payment information document shown in FIG. 4
is retrieved from the merchant computer and displayed.
[0044] FIG. 4 is a missing payment information document that is
used to gather user account information for the requested purchase
in an HTML form. Radio buttons 8, 9, 10, 11, 12 are used to select
a means of payment, dialog box 13 is used to enter an account
number, dialog box 14 is used to enter an optional authenticator
for the account, purchase button 15 is used to send the account
information to the merchant computer and proceed with the purchase,
link 16 is used to abort the purchase and return to the document
shown in FIG. 2, and dialog box 17 is used to enter optional user
information that is associated with the purchase and ultimately
used by a financial institution as part of a textual billing
identifier for the purchase transaction. If provided, this
additional information is included in the payment order for the
purchase.
[0045] FIG. 5 is a fulfillment document 18 that is produced once
valid account information is provided to the missing payment
information document in FIG. 4 and purchase button 15 is
activated.
[0046] FIG. 6 is a flowchart that more fully describes the
information flow in the purchase transaction shown in FIGS. 2 to 5.
An initial user inquiry 19 from activating link 1 results in the
HTTP request 20 for a specific document with a specified URL. The
URL specifies the name of the merchant computer. The merchant
computer retrieves the document given the URL at 21, and returns it
to the buyer computer at 22. The buyer computer displays the
resulting HTML document at 23. When the user activates link 5, an
HTTP request 25 is sent to the merchant computer requesting the
document.
[0047] In an alternate embodiment, document 22 is executed at 23 as
a program. A program is defined as a set of instructions that can
exhibit conditional behavior based upon user actions or the
environment of the buyer computer. As is known to those skilled in
the art, there are many techniques for representing programs as
data. The program can be interpreted or it can be directly executed
by the buyer computer. The program when executed will cause the
buyer computer to interact with the user leading to the user
purchase request 24, and the purchase message 25.
[0048] The merchant computer then attempts to construct a payment
order at 26 using the information it has gathered about the user.
The buyer computer may have previously supplied certain credentials
using fill out forms or other account identification means such as
providing the network address of the buyer computer in the normal
course of communication. If the buyer computer is able to construct
a complete payment order at 26 the payment order is sent to a
payment computer for authorization at 27. If a payment order can be
constructed, processing continues at 28.
[0049] Alternatively, the buyer computer may construct the payment
order at 24 and send it to the merchant computer at 25. In this
case, the payment order assembly steps at 26, at the merchant
computer, may only need to forward the payment order from the buyer
computer.
[0050] A payment order includes user account information, merchant
account information, an amount, and a nonce identifier that has not
been previously used for the same user account. Variations of
payment orders can be constructed, including payment orders that
specify user or merchant identifiers in place of account
information, payment orders that specify a valid time period,
payment orders that specify foreign currencies, and payment orders
that include comment strings. Part of the process of constructing a
payment order is creating a corresponding authenticator using one
of the authenticator methods described below.
[0051] In the illustrated embodiment of FIGS. 3 and 4, the merchant
computer does not have sufficient information to construct a
payment order at 26 and thus at 33 (FIG. 7) constructs and returns
a missing payment information document in response to request 25.
Operation 33 includes in the constructed document appropriate form
fields based on what information the merchant computer has already
collected from the user. The document is returned to the buyer
computer at 34 and is displayed at 35. When the user presses the
purchase button 15, the contents of the form are transmitted to the
merchant computer, at 36, to a specific URL name, using an HTTP
request. Based on the supplied form fields, the merchant computer
constructs a complete payment order. Alternatively, the buyer
computer may construct the payment order at 35 and send it to the
merchant computer as part of step 36. In this case, the payment
order assembly steps 37 at the merchant computer simply passes on
the payment order from the buyer computer. The payment order is
sent to the payment computer in a message at 38.
[0052] In either case, the flowchart continues in FIG. 6 where the
payment computer checks the authorization of the payment order at
28. If the payment system authorizes the request, an authorization
message at 29 is returned to the buyer computer, and the merchant
computer checks at 30 that the authorization message came from the
payment computer using the authenticator mechanism described below.
Assuming that the authorization message is valid, the merchant
computer performs fulfillment at 30, returning the purchased
product in response at 31. In our example in FIG. 5 the response at
31 is document 18 that was the logical target of link 5. If the
payment system does not authorize the payment order then response
31 is a rejection of the user's purchase request.
[0053] In an alternate embodiment, step 30 can encrypt the document
using a key that is known to the buyer computer. As is known to
those skilled in the art, the key can be communicated to the
merchant computer using convention key distribution protocols. In
this manner the document will be protected from disclosure to other
users.
[0054] The fulfillment step at 30 can alternatively schedule a
physical product to be shipped via ordinary mail or other means.
This can be accomplished by updating a fulfillment request database
or by sending a message to a shipping system. In this case the
response at 31 is a confirmation that the product has been
scheduled to ship. In this way the network sales system can
implement an electronic mail order system.
[0055] FIGS. 8, 9, 10, and 11 show a second example that uses query
based access to digital advertisements. It is assumed that the
previous example was used by the user immediately before at the
same buyer computer.
[0056] FIG. 8 shows the overview screen where the query "movie
review" has been entered into dialog box 39. When the user
activates process button 40, the merchant searches databases as
described by the URL attached to button 40, and creates a response
document as shown in FIG. 9.
[0057] FIG. 9 shows digital advertisements 39, 40, 41, 42, 43, and
44 that were found in response to the query initiated by button 40.
A scroll bar 45 shows that there are additional digital
advertisements that are not shown. When link 46 is activated, the
missing account information document shown in FIG. 10 is returned
by the merchant computer.
[0058] FIG. 10 shows that the merchant computer has partial
information on the buyer's account. Message 47 shows that the
merchant computer already knows the buyer's account number.
Purchase button 48 will send the optional user reference string in
dialog box 50 to the merchant computer described by the URL behind
button 48 and purchase the product corresponding to digital
advertisement 39. Cancel link 49 will return the user to the
document shown in FIG. 2.
[0059] When purchase button 48 is activated, a document 51 is sent
by the merchant computer and displayed by the buyer computer as
shown in FIG. 11.
[0060] FIG. 12 shows an alternative method of processing a sales
transaction. In this method when the user requests a purchase at
52, the buyer computer constructs a payment order at 53 and sends
it for approval to the payment computer at 54. The payment computer
authorizes the payment order at 55; and when the payment order is
authorized, returns an unforgable certificate at 56 that the
payment order is valid. Means of creating such unforgable
certificates are described in authenticator method number one
below. If at step 55 the payment order is not authorized, a
rejection message is sent at 56 and the sales transaction is
terminated.
[0061] The buyer computer then proceeds at 57 to send a
pre-authorized purchase request to the merchant computer. The
unforgable certificate 56 is included in a purchase message at 57
that is sent at 58 to the merchant computer. Based upon the
pre-authorized payment order the merchant computer performs
fulfillment at 59 and returns the product at 60. In a variation,
the merchant computer at 59 checks to ensure the payment order has
not been previously used. This can be accomplished by checking with
a payment computer or maintaining a merchant computer database of
previously accepted payment orders. The unforgable certificate
created at step 56 does not need to include the user account
information. This variation is useful if the user wishes to make
purchases and remain anonymous to the merchant.
[0062] A Network Payment System
[0063] A network payment system 300 as shown in FIG. 13, employs a
public packet-switched network 69 to interconnect a plurality of
client computers 70 and 71, and a plurality of payment computers
such as 72, each payment computer having an account database 73, a
settlement database 74, an authorized address database 75, a sender
credential database 76, a financial system interface 77, and a
real-time authorization interface 78. The interfaces 77 and 78 may
be implemented by a single communications line.
[0064] In an alternate embodiment, the network payment system
further includes external devices that are kept in the possession
of users so that the users can authenticate themselves when they
use a buyer computer.
[0065] Account database 73 maintains temporal spending amounts,
such as the amount spent in the current day, and also maintains
temporal spending limits. The account database may also maintain a
translation between principal identifiers and external account
identifiers. Settlement database 74 records committed payment
orders along with any authorization information for the orders that
was obtained from interface 78. Address database 75 maintains for
each sender a list of authorized buyer computer and delivery
addresses. Credential database 76 maintains a list of credentials
for principals and information that can be used to authenticate
principals.
[0066] FIG. 14 is a flowchart that describes the operation of the
payment system. A client computer 71 constructs a payment order at
79, and computes and adds an authenticator to the payment order at
80. The payment order is sent at 81 to a payment computer, where
the authenticator is verified at 82 to ensure that the payment
order was originated by the sender it describes. Below we present
different means of implementing 80 and 82.
[0067] If the payment order is authentic and address restrictions
are desired, at 83, either or both of the client computer address
or the specified delivery address can be checked against address
database 75. If address restrictions are desired and if the
addresses in the payment order are not in the database, the payment
computer sends a rejection message to the client computer. Address
database 75 specifies, for each principal, acceptable client
computer addresses and delivery addresses. A delivery address can
be a network address, or a street address for packaged goods. As is
known in the art, database 75 can include wild-card specifications
and similar techniques to reduce its size. For example, database 75
could contain an entry for principal identifier "*@acme.com"
restricting legal delivery addresses to "computer: *.com",
"computer: cmu.edu", and "surface: *, 34 Main Street, Anytown,
U.S.A.", indicating that any user at the company Acme can order
products to be delivered to the network address at Acme or the
university CMU, or to anyone at 34 Main Street, Anytown, U.S.A.
[0068] If payment order address restrictions are not desired or
have been checked, processing continues at 84 where the payment
order is checked for replay and temporal spending limits. Replay is
checked for by making sure that the sender did not previously
present a payment order with the same nonce by checking an index of
committed payment orders by nonce in settlement database 74. If
nonces are based on time, then a payment order that is older than
an administratively determined value can be rejected out of hand.
Time based nonces or sequential nonces permit old nonces to be
removed from the settlement database 74. If a payment order has
been previously processed or its nonce is too old, the payment
order computer sends a rejection message to the client.
[0069] After the payment order passes the replay check, temporal
spending limits are checked in account database 73. These spending
limits can be applied on a per sender, per group of senders, and
per payment system basis to limit fraud risk. The limits can be
applied to any duration of time, for example a maximum spending
amount per hour or per day. If the payment order would violate a
spending limit, the payment computer sends a rejection message to
the client.
[0070] Once the payment order passes the temporal spending check at
84, a message is constructed at 85 to check that the external
account that backs the sender's payment system account has adequate
funds or credit. If the sender identifier in the payment order is
not already an account number in the external financial system, it
is translated into a corresponding account number in the external
financial system using account database 73. A real-time
authorization request message is sent at 86 to the external
financial system over interface 78. If the external financial
system approves authorization request 86, an authorization message
is returned at 87. If request 86 is not approved, the payment
computer sends a rejection message to the client at 87.
[0071] In a variation of the above described approach, processing
continues at 95 after 84. At 95 real-time authorization is only
obtained when the total of a sender's payments since the last
real-time authorization reaches a preset value, or the payment
order is over a preset amount. These preset values can be
optionally recorded on a per principal basis in database 73 or can
be administratively determined for all principals. In this manner,
the number of messages to the external financial system can be
reduced. In addition, the payment system can avoid making real-time
authorization requests for small payments when the risk is
acceptable to the payment system operator. If real-time
authorization is necessary, processing continues at 85 after 95. If
real-time authorization is not necessary for a request, at 100 the
payment order amount is added to the sender's total of payments
since the last real-time authorization in database 73, and
processing continues at 88.
[0072] In another variation after 100 a check is made at 101 in
database 73 to see if a background authorization process should be
scheduled. A background authorization process permits the payment
computer to continue its normal processing while it checks with the
financial authorization network on the sender's account. This
mechanism can be used to limit payment system risk. If the
background authorization fails, the account is suspended by so
updating database 73. If the sender's total of payments since last
authorization is over a preset value stored in 73 then a background
authorization process is scheduled at 102. Otherwise processing
continues at 88.
[0073] In another variation, at 95 and 101 authorizations are
obtained based on the amount spent since last authorization and
time since last authorization.
[0074] At 88 the payment order is committed to execution and is
recorded in settlement database 74. Recorded with the payment order
in database 74 are portions of authentication message 87 that show
that the payment computer contacted the remote financial system.
The amount of the payment order is added to running temporal
spending records in database 73, and an authorization message is
sent to the client computer at 90. The authorization message
includes the payment order. In an alternate embodiment, at 90 the
authorization message contains a truncated payment order that
includes at least the payment order's sender and the payment
order's unique nonce.
[0075] In an alternate embodiment, the authorization message sent
to the client at 90 includes at least one legal delivery addresses
for the sender as determined from database 75.
[0076] Authorization message 90 must be transmitted in such a way
that the client computer can be sure that it came from the payment
computer. At 89 a payment system specific authenticator is added
payment order. At 91 this authenticator is checked by the client
computer. The steps at 89 are a dual of step 80, and the steps at
91 are a dual of step 82. The authentication means for steps 89 and
91 are described below.
[0077] Finally, settlement is performed at 92 in the external
financial system 77 between external accounts that correspond to
the sender and the beneficiary. If settlement is accomplished as
part of real-time authorization at steps 86 and 87, as may occur in
a real-time debit network, then no other steps need to be taken. If
settlement is not accomplished as part of the authorization
process, then financial system messages are sent to interface 77 to
effect settlement. Depending on the external accounts involved,
these messages may include electronic funds transfer messages or
automated clearinghouse messages.
[0078] In an alternate embodiment, at 92 settlement messages are
sent to reconcile net transfer balances between principles on a
temporal basis, for example once a day. In this embodiment the
number of settlement messages can be less than the number of
payment orders.
[0079] Authenticators may be created and checked using one of the
following methods. The payment computer can use any of the first
four methods, and the client computer can use any of the methods
described.
[0080] In a first method for authenticators, at steps 80 or 89, a
digest of the payment order is signed by the sending computer using
a public-key cryptographic system such as RSA. This signature is
used as the authenticator. As is well known in the art, the signing
can be accomplished using a private key created from a public-key
pair, where the signing key is only known by the signer, and the
other public key is known to the receiving computer. At the payment
computer the public key corresponding to each sender is kept in
credential database 76. The private key for the payment service is
also kept in database 76. At steps 82 or 91, the signature of the
received message is checked using the public key known to the
receiving computer.
[0081] In a second method for authenticators, at steps 80 or 89, a
digest of the payment order is signed by the sending computer with
a private key cryptosystem such as DES. This signature is used as
the authenticator. At the payment computer, the private key
corresponding to each sender is kept in credential database 76. At
step 80, a digest of the payment order is signed by the client
computer, and at step 89 a digest of the payment order with an
added approval code is signed by the payment computer using the
same private key. At steps 82 or 91, the signature of the received
message is checked using the shared private key.
[0082] In a third method for authenticators, at step 80 the
authenticator is computed by a protected device external to the
system such as a Smart-Card. A protected device is specifically
designed to be extremely difficult both to replicate and to
compromise. In this method, the payment order is communicated at 80
to a Smart-Card. The Smart-Card computes and signs a digest of the
payment order, and then communicates the signature back at 80 to be
used as an authenticator. A Smart-Card produced authenticator
uniquely associates a payment order with its creating Smart-Card.
This is accomplished by having the Smart-Card contain a secret key
"K" that is used to create a digital signature of the payment
order. "K" is never released outside of the Smart-card. The
Smart-Card is designed to make it computationally infeasible to
compute "K" even with possession of the device. In this method, at
step 82, a signature checking key from database 76 is used to check
the authenticator. In an alternate embodiment, a user must manually
signal their acceptance of each payment order on an input device
that is part of the external device before the authenticator is
created by the external device.
[0083] In a fourth method for authenticators, at steps 80 or 89, a
network address is used as an authenticator. At steps 82 or 91, a
digest of the payment order is sent back to the specified network
address along with a random password. The computer at the specified
network address must then return the payment order digest along
with the password. If the network guarantees to deliver messages to
the proper network address, this method will guarantee that the
user or computer at the specified network address approves of the
payment order. Assuming that network delivery is trusted, this
method can be used to authenticate a sender computer's network
address in a payment order. Alternatively, electronic mail can be
used to send such confirmation messages between a user and the
payment system.
[0084] In a fifth method for authenticators, at step 80, the
authenticator is produced by an external device that produces a
sequence of non-predicable transaction identifiers that are device
specific. The authenticator is entered by the user into the client
computer by reading its display. One such device is described in
U.S. Pat. No. 4,856,062. According to this method, at step 91, the
authenticator can be checked using the sender specific fixed code
of the device which is kept in database 76. This sequence of steps
is also shown in FIG. 15 at steps 93 and 94.
[0085] In a sixth method for authenticators, at step 80, the
authenticator is obtained by querying the user for a transaction
identifier that is the next string from a physical list of one-time
authorization strings. Such as list could be produced on a card,
and the user can cross off authorization strings as they are used.
According to this method, at step 91, the authenticator is checked
against the next expected string from the sender using database 76.
Database 76 can hold for each sender a list of random authorization
strings, or can hold a sender specific secret key that was used to
generate the list of authentication strings along with how many
strings have been used so far. This sequence of steps is also shown
in FIG. 15 at 93 and 94.
[0086] In a seventh method for authenticators, at step 80 the
authenticator is a previously obtained personal identification
number (PIN) for the user. In this method in 91 the authenticator
is checked against the expected PIN for the sender using database
76.
[0087] As will be obvious to one skilled in the art, any of the
methods for creating authenticators can be used together to
increase system security. For example, authenticator method six can
be used to create an authenticator based on a transaction
identifier, and then a payment order including a transaction
identifier can be given a further authenticator using authenticator
method one. In this example the resulting authenticators would be
checked with their respective methods.
[0088] A digest of a payment order can be created with an algorithm
such as MD5 [R. Rivest, The MD5 Message-Digest Algorithm, MIT
Laboratory for Computer Science, Network Working Group Request for
Comments 1321]. Alternatively, a digest can be the entire payment
order or other functions of the payment order's component
parts.
[0089] In addition in both the sales and payment systems alternate
authenticator techniques can be used such as those described by
Voydock and Kent in "Security Mechanisms in High-level Network
Protocols", Computing Surveys Vol. 15, No. 2, June 1983. As will be
appreciated by those skilled in the art, two-way authenticated
byte-stream or remote procedure call interface connections that
protect against replay can replace our message based
authenticators.
[0090] Additions, subtractions, deletions, and other modifications
of the described embodiment will be apparent to those practiced in
the art and are within the scope of the following claims.
* * * * *