SYSTEMS AND METHODS OF PAYING FOR COMMERCIAL TRANSACTIONS Field of the Inv ention
The invention relates generally to the field of commerce and more particularh . to -> stems 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 rapidK being accepted as the future m.arketplace 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 pa ing sales people. While many merchants are only adding to their physical stores by opening irtual stores (e.g.. web sites) on the Internet, other merchants such as EggHead Software ι 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.
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 purcr ser 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.
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 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 tr.ansaction 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.
Fig I illustrates an embodiment of the present invention The illustrated sv stem mav 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 an 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 ol l/O device
The s stem includes a financial persona server 50 (persona server 50) and a payment server 40 The persona server 50 may be a stand alone computer (preferred), an adjunct to the payment ser er 40, or one or more software program(s) running on the payment server 40 The payment serv er 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 pπvate 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
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 Ebayr 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 Tl 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
programmed into sottvvare used to access the persona server 50 it can be entered into the software by the purchaser, it can be preprogrammed into the software, it can be keved in b\ 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 mav be allowed to use a variety of terminals
Atter the purchaser connects to the persona server 50 he/she 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 pavment option add a payment option or update a payment option It is also considered within the scope ot 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 numbeπng 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 1 10 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
merchant server 20 to the payment server 40 could be via a secure or unsecured route (e g . it could be v ia 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 his/her 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., credit/debit 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 authoπzation 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
prov ided 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 50 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 50. 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 will 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.
It is also to be understood that the following claims are intended to cover all ot the generic and specific features ot the invention as described herein, and all statements ot the scope of the invention which, as a matter ot language, might be said to fall therebetween
Hav ing described the invention, what is claimed as new and secured bv Letters Patent is