Note: Descriptions are shown in the official language in which they were submitted.
CA 02263777 1999-03-O1
1
SYSTEMS AND METHODS OF PAYING FOR COMMERCIAL TRANSACTIONS
Field of the Invention
The invention relates generally to the field of commerce and more
particularly, to systems
and methods for facilitating a secure method of payment for a commercial
transaction which took
place in a secure or unsecured environment.
Background of the Invention
Shared networks such as the Internet and smaller shared networks are rapidly
being
accepted as the future marketplace for goods and services. Many merchants are
discovering that
it is cheaper and more effective to offer their goods and services over the
Internet rather than
opening physical stores and paying sales people. While many merchants are only
adding to their
physical stores by opening virtual stores (e.g., web sites) on the Internet,
other merchants such
as EggHead SoftwareT'" etc. have closed all of their physical stores and
replaced them with a
virtual store on the Internet, while still others such as Amazon.com'~"'' etc.
are starting new
companies on the Internet without ever opening a physical store.
An aspect of the Internet which is preventing it from completely taking over
as the world
marketplace is that consumers are still leery about transmitting their credit
card numbers or any
other payment information over the Internet or any unsecured medium. Many
consumers are
afraid that dubious people will intercept their transmission and use their
credit cards or other
payment information for unauthorized purchases.
Accordingly there exists the need for a system which provides the ability to
make
purchases over a secure or unsecured channel of commerce (e.g. the Internet, a
crowded store,
the Public Switched Telephone Network (PSTN) etc.) without the need to provide
a credit card
number or other information, which is directly linked to a payment method,
over the channel of
commerce.
There also exists the need for a system which enables a purchaser to select a
payment
method and authorize all payments made.
It is accordingly an object of the present invention to provide a system which
enables
consumers to make purchases over a secure or unsecured channel of commerce
without the need
to provide a credit card number or any other information, which is directly
linked to a payment
method, over the channel of commerce.
CA 02263777 1999-03-O1
7
It is another object of the invention to provide such a system which enables a
purchaser
to select a payment method and to authorize all payments made.
These and other objects of the invention will become apparent to those skilled
in the art
from the following description thereof.
Summary of the Invention
It has now been discovered that these and other objects may be accomplished by
the
present system to facilitate a secure method of payment for a commercial
transaction between
a purchaser and a merchant. An embodiment of the invention includes a
financial persona server
configured to store information related to a purchaser, wherein the
information includes a set of
payment options. The financial persona server is accessible to the purchaser
for selecting one
of the payment options. The embodiment also includes a payment server
selectively connected
to the financial persona server and configured (I) to receive transaction
information about the
commercial transaction, (ii) to request one of the payment options from the
financial persona
server, and (iii) to receive the payment option selected and process that
payment option.
In another embodiment, the invention includes a storage device for storing
purchaser
payment options; and, a payment requesting device for requesting a payment
option and an
authorization from the storing device to pay for the commercial transaction.
In yet another embodiment, the invention includes a method for enabling a
purchaser to
select a method of payment, and authorize a commercial transaction, between
the purchaser and
a merchant. The method includes providing the purchaser with an account on a
financial persona
server, and providing the purchaser with an account number representing the
account. The
method further includes providing the purchaser with a secure connection to
the financial persona
server and enabling a set of payment options to be stored in the account. The
payment server
receives a message identifying the commercial transaction and the account
number, and
communicates the message to the financial persona server. The financial
persona server requests
an authorization and a payment choice from the purchaser. After the purchaser
makes the choice,
the financial persona server communicates the choice to the payment server
over a secure link.
The payment server receives the payment choice and forwards it over a secure
link to a financial
institution for further authorization.
CA 02263777 1999-03-O1
Another embodiment of the invention includes a method for enabling a purchaser
to
select a method of payment) and authorize a commercial transaction between the
purchaser and
a merchant. The method includes providing the purchaser with an account on a
financial persona
server and providing the purchaser with an account number representing the
account. The
S method enables the purchaser to input, over a secure connection, a set of
payment options into
the account. The payment server receives a message identifying the commercial
transaction and
the account number and communicates the message to the financial persona
server. The financial
persona server requests an authorization and a payment choice from the
purchaser. When the
financial persona server receives a denial of the authorization from the
purchaser, the financial
persona server communicates the denial of authorization to the payment server
which receives
the denial of authorization and forwards it to the merchant.
The invention will next be described in connection with certain illustrated
embodiments;
however, it should be clear to those skilled in the art that various
modifications, additions and
subtractions can be made without departing from the spirit or scope of the
claims.
Brief Description of the Drawings
For a fuller understanding of the nature and objects of the invention,
reference should be
made to the following detailed description and accompanying drawings, in
which:
Fig. 1 depicts a schematic diagram of an electronic transaction system in
accordance with
the invention.
Detailed Description of the Invention
The present invention discloses systems and methods for enabling a purchaser
to select
a method of payment, and authorize a commercial transaction without the need
to provide a
merchant with the actual payment method. The present invention is particularly
suited for
electronic commerce over the Internet as it enables a purchaser to pay for the
commercial
transaction in a secure manner even though the transaction may have occurred
over a channel of
commerce which is not secure (i.e., the Internet). However, it is also
applicable to other forms
of commerce (e.g., mail order, telephone orders, in person transactions,
paying for telephone
calls, transactions over shared networks, etc). It is also applicable to
secure transactions, in
which case it merely adds another level of security to the transaction.
CA 02263777 1999-03-O1
Fig. 1 illustrates an embodiment of the present invention. The illustrated
system may
include a user/purchaser terminal 10 (terminal 10) which may be a computer
terminal, an Internet
compatible television, a pager. a cellular telephone, a personal digital
assistant (PDA) or any
other similar terminal 10. The terminal 10 may include a monitor. a
conventional card reader
(not shown) for reading conventional credit, debit and/or smart cards (also
not shown) and some
form of IJO device.
The system includes a financial persona server ~0 (persona server 50) and a
payment
server 40. The persona server 50 may be a stand alone computer (preferred}, an
adjunct to the
payment server 40, or one or more software programs) running on the payment
server 40. The
payment server 40 may be a conventional payment server 40 currently used to
process bank cards
such as Visa, American Express, Master Card) Discover or the like and may be a
part of the
Interchange network 30. Those skilled in the art will recognize that a private
or shared computer
server could also be used as the payment server 50 without departing from the
scope of the
invention.
A purchaser is provided an account on the payment server 40 and an account
number.
The account may be used by the purchaser to store one or more credit/debit
card numbers, bank
account numbers, line of credit account numbers, or the like. These payment
options may be the
purchaser's accounts, a third party's accounts or a combination thereof.
Further, the purchaser
may have the ability to directly modify the information stored in the account,
although such a
feature is not required. It may also be possible to have a payment option
which allows the
purchaser to input a credit card number or some other payment method, not
already stored, to pay
for a transaction. In the event the purchaser has the ability to edit the
payment options, the
purchaser could be given the option to save this new payment method for future
use. The
account number preferably conforms to current credit card numbering standards
although a
system which provides account number which do not comply therewith would still
fall within
the scope of the present invention.
The merchant server 20 may be a privately owned server which the merchant
operates.
For security purposes, the merchant server 20 could be precluded from access
to the persona
server 50 or the information thereon. The merchant server 20 can be a web site
which the
merchant runs or it could be a web site that a third party operates for the
merchant. It could also
be a mail order business, a telephone order business, a physical store, etc.
Further, the term
CA 02263777 1999-03-O1
J
merchant is not limited to retail sellers of goods. This system could be
employed to purchase
services, or to pay for auctioned goods at an auction site such as EbayT~' or
for almost any
commercial transaction. An interesting use for this invention could be as a
phone card. A
problem with entering current phone card information into a public telephone
is that there are
dubious people who watch people keying their numbers into the public
telephone, then use the
information to pay for unauthorized calls. This invention would prevent such
an occurrence
since the account number entered is not directly tied to a financial source
and thus would be of
no use to an unauthorized user of the account number.
A typical transaction using this invention may occur in the following manner.
A
purchaser contacts a service provider to establish an account. The service
provider furnishes the
purchaser with an account on the persona server, an account number and a
security certificate for
accessing the account. The account number and security certificate could be
provided in any of
a number of ways. For example, they could be provided orally, in a letter, in
an encrypted e-mail
message, on a smart card, on a software package, on a downloadable file or
some combination
thereof.
To access the account, the purchaser "logs in" by using the terminal 10 and
possibly
software loaded thereon to establish a secure link 80 to the persona server 50
which may or may
not require a security certificate. This secure link 80 could be a secure link
via the Internet (e.g.,
a SET encrypted link, etc.), it can be a direct dial up link, it can be a link
via a private or
shared network, or any other secure link, or the purchaser could be provided
an option of one
or more of these connection choices.
If the link 80 is an Internet link, it is possible to concurrently maintain
this link while
contacting the merchant server 20. This may also be possible with the other
options, however
it would probably require additional hardware. Those skilled in the art will
recognize that the
link could be over a standard phone line, an ISDN line, a T1 line, a co-axial
cable, a wireless data
link, etc. or a combination thereof. The system could also operate by the
purchaser logging in
to the persona server 50 and the merchant server 20 at different times.
The purchaser provides the security certificate to the persona server 50 which
identifies
the purchaser and the account. This security certificate, which is preferably
a Public Key
Certificate but not required to be, could be provided to the persona server in
a number of ways.
It could be stored on a smart card then accessed via a card reader
(preferred), it can be
CA 02263777 1999-03-O1
. 6
programmed into software used to access the persona server ~0, it can be
entered into the
software by the purchaser. it can be preprogrammed into the software. it can
be keyed in by the
purchaser or any combination of these methods. Depending upon design choices.
the purchaser
may be limited to a particular terminal for accessing the account, or the
purchaser may be
allowed to use a variety of terminals.
After the purchaser connects to the persona server ~0 helshe may be able to
enter one or
more payment options. Once the options are entered, it is preferable but not
required that the
purchaser be given the ability to modify the options; to either remove a
payment option, add a
payment option or update a payment option. It is also considered within the
scope of the
invention that the purchaser could make an initial selection of payment
options when the
purchaser signs up which would be entered by the service provider. In such a
situation, any
changes to the payment options could be required to be provided to the service
provider and
entered thereby. However, it is also possible to give the purchaser the
ability to directly modify
some or all of the information.
Once the purchaser has an account, he/she may commence with the commercial
transaction. In the embodiment wherein the purchaser logs onto the Internet,
the purchaser may
log onto a merchant server 20 and make a purchase. The purchase could be made
from that
merchant or from a third party who provides goods and/or services from the
merchant server 20.
Once the price is agreed upon for the transaction, either by negotiation or
payment of a listed
price, the purchaser provides the account number to the merchant server 20.
This could be
provided in any number of ways (e.g. via the Internet, telephone, e-mail, the
postal service,
facsimile, etc.).
In the embodiment wherein the account number conforms to the current
credit/debit card
numbering system, the merchant server 20 may treat the sale like it would any
other credit/debit
card purchase. It sends the card number and the amount of the sale to a bank
interchange
network 30 for authorization. It does this via link 110. While currently, Link
110 is a secure
link, it is not necessary since the account number provided to the merchant
does not have any
money linked to it. Thus, even if one were to intercept the account number it
would be to no
avail. Thus, the route from the merchant server 20 to the payment server 40
does not have to
be via the same Interchange network 30 as the Interchange network 30 between
the payment
server 40 and the card issuer 60 and bank 70 (although it preferably will be).
The route from the
CA 02263777 1999-03-O1
merchant server 20 to the payment server 40 could be via a secure or unsecured
route (e.g.. it
could be via the Internet, the bank interchange network, the PSTN, some other
route. or some
combination thereof).
The bank interchange network 30 is a bank card processing network such as
those used
for Visa, MasterCard, etc. which recognizes the banking institution
information contained within
the card number. For example, the first four digits of the card number may
contain the card
issuer bank identification. This information is recognizable by all
conventional systems and
serves to route the transaction to the appropriate payment institution. Thus,
the merchant
server 20 need not know that the card number provided by the purchaser is not
linked to a
financial instrument. The bank interchange network 30 routes the transaction
to the relevant
bank payment server 40. The payment server 40 then hands off the electronic
transaction to
the financial persona server 50. If the purchaser is logged on to the persona
server 50, the
persona server may cause a query screen to be displayed on the terminal 10.
The query screen
could inform the purchaser of the purchase price and request authorization and
a method of
payment. If the purchaser refuses authorization, (e.g. purchaser changed
hislher mind, or the
transaction was fraudulent) either a denial or a denial with a reason is
returned to the payment
server which in turn returns an authorization denial to the merchant server 20
(with or without
a reason).
If the purchaser wishes to allow the transaction and the purchaser's account
has been
configured with different payment options, the purchaser then chooses one of
the options
previously entered. This payment information is returned to the payment server
40 via secure
link 100. It is also possible that one of the payment options is to enter
payment information not
previously entered (e.g., creditldebit card, etc.). Depending upon design
choices, the purchaser
could be required to enter an authorization code in addition to the payment
selection or the
payment choice could also be used as the authorization code. Once the payment
server receives
the payment choice it routes the payment information and the transaction
information to the card
issuer 60 for authorization. If it receives the requested authorization, it
provides an authorization
code to the merchant server 20 and the transaction may be completed by the
merchant. If the
payment method is rejected by the card issuer (either for insufficient funds
or some other reason)
either the merchant server 20 could be provided with the rejection, the
merchant server 20 and
the persona server 50 could be provided with this rejection or the persona
server could be
CA 02263777 1999-03-O1
g
provided with this rejection and the purchaser could be given the opportunity
to choose another
form of payment or cancel the transaction.
It is conceivable that the purchaser is not logged on to the persona server ~0
while the
transaction is taking place. Thus, the purchaser might not be logged on when
the payment server
40 forwards the request to the persona server S0. If this occurs, the persona
server could be
programmed to buffer the request until the purchaser logs on again, it could
be programmed to
locate the purchaser (e.g. through a paging system, a distinctive ring on a
telephone, a call to a
cell phone, e-mail, a short messaging service (SMS) message, etc. or a
combination of these), it
could be programmed to deny any such transaction or accept all such
transactions depending
upon the choices made by the purchaser, or it could be programmed to accept
all such
transactions which are below a predetermined threshold amount and perform one
of the previous
options for all other transactions. The action taken is strictly a design
choice. In the event the
persona server is programmed to locate and notify the purchaser, it is
possible that the purchaser
is given the ability to respond directly to the notification without having to
log on to the server.
It will thus be seen that the invention efficiently attains the objects set
forth above, among
those made apparent from the preceding description. In particular, the
invention provides a
system and method for facilitating a secure payment for a commercial
transaction whether the
transaction occurred over a secure or unsecured channel of commerce. Those
skilled in the art
will appreciate that the configuration depicted in Fig. 1 discloses a system
which allows a
purchaser to make a purchase over a channel of commerce which may or may not
be secure,
provide the merchant with an account number which appears to the merchant as a
regular
credit/debit card account, then choose a payment option and communicate that
option to a
financial institution via a secure network. The level of security offered by
the invention depends
upon the level of security established between the purchaser and the persona
server thereby
removing the requirement of a secure channel of communication between the
purchaser and the
merchant.
It wi 11 be understood that changes may be made in the above construction and
in the
foregoing sequences of operation without departing from the scope of the
invention. It is
accordingly intended that all matter contained in the above description or
shown in the
accompanying drawings be interpreted as illustrative rather than in a limiting
sense.
CA 02263777 1999-03-O1
9
It is also to be understood that the following claims are intended to cover
all of the
generic and specific features of the invention as described herein, and all
statements of the scope
of the invention which. as a matter of language, might be said to fall
therebetween.
Having described the invention. what is claimed as new and secured by Letters
Patent is:
