WO2001035304A9

WO2001035304A9 - On-line payment system

Info

Publication number: WO2001035304A9
Application number: PCT/US2000/030995
Authority: WO
Inventors: Serge M Krasnyansky
Original assignee: Serge M Krasnyansky
Priority date: 1999-11-10
Filing date: 2000-11-09
Publication date: 2002-05-23
Also published as: WO2001035304A1; AU1598101A

Abstract

A method for conducting financial transactions is disclosed. The method includes providing a payserver (130) coupled to a network (150), and a wallet (110) comprising a program code executable using a computing deviced (140), and data on a tangible medium. The financial transaction is made using the wallet (110) by executing the code on a payer computing device (140) to provide a payer identifier and a purchase amount to the payserver (130).

Description

ON-LINE PAYMENT SYSTEM

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims priority from U.S. provisional patent application number 60/164,510, filed November 10, 1999, which is incorporated by reference.

BACKGROUND OF THE INVENTION

The present invention relates to a payment system for electronic commercial transactions, specifically a system which can be used to pay on-line for goods and services purchased from a Web site, as well as to receive payments from Web sites, or to transfer money between two Internet users.

On-line electronic commerce has rapidly become one of the most important sales channels in our marketplace today. Consumers can use the Web to purchase everything from crafts made by artists, to cars and network servers from multi-national corporations. On any given day, millions of people use the Internet to shop for, and purchase goods and services. Currently, most of these transactions must be completed using a credit card. Embodiments of the present invention may be used as an alternative to credit cards in these e- commerce transactions.

Most purchases over the Internet are completed using a credit card. Either the credit card number is entered on the seller's Web site, or a separate phone call is placed where the information is given verbally. Once the credit card data is stored by the seller, a "cookie" may be placed on the buyer's computer, or a password given, such that the buyer does not have to re-enter the credit card information for later transactions.

But this is not always a desirable way of doing business, particularly for the buyer. Specifically, buyers are apprehensive about giving out credit card numbers over an electronic forum. Fear of credit and identity theft is keeping many customers away. Liabilities may be limited by statute or agreement, but the concern of potentially huge losses is palpable. Also, even though, as its name implies, the World- Wide- Web spans the globe, banking and other supporting commercial infrastructures do not. In many countries credit is not available in the simple and reliable manner as in the United States. This means that whole populations are disenfranchised from the electronic retail revolution, and are unavailable as customers. Even where credit is available, many people cannot obtain it. Persons under the age of eighteen, recent or illegal immigrants, and those with poor or insufficient credit history may be denied.

Also, many individuals forgo providing personal information over the Web to protect their privacy. Often, it is desired to remain anonymous to prevent embarrassment or political prosecution. The concern may be that a visit to health sites specializing in cancer treatment may effect the availability of insurance coverage later in life. Celebrities and those from societies with strict cultural or religious rules, place a premium on privacy.

But "plastic" is not without its advantages. It is easy to carry around on a daily basis. It can be used on third party computers, such as those at places of employment, schools, and libraries, without the installation of software programs.

What is needed is a substitute for credit cards for use in on-line transactions. The replacement should be useful in areas of the world where the banking systems are weak or nonexistent. It should enable users to remain anonymous, as well as limit any potential liabilities for unauthorized use. Optimally, the convenience and practicality of credit cards should be retained. And to ensure maximum usefulness, it should not be necessary to load a program onto a host computer.

SUMMARY OF THE INVENTION

The present invention provides a system for on-line payment and transfer of funds. The system includes one or more Payservers connected through a network to payers and payees. Examples of payees include vendors and service providers. Examples of payers include consumers. In the system, payers use a Wallet to access an account on a Payserver, which will perform all or part of the desired financial transaction. The Wallet is typically a readable and writeable medium, which is transportable by a user. In one implementation, the Wallet is a 3.5-inch floppy disk. The Wallet provides security features such as including both data and a program on the medium.

In one aspect, the present invention provides a method for conducting financial transactions. The method includes providing a Payserver coupled to a network, and a Wallet comprising a program code executable using a computing device, and data on a tangible medium. The financial transaction is made using the Wallet by executing the code on a payer computing device to provide a payer identifier and a purchase amount to the Payserver. The network may be the Internet. The program code may include encryption

1 software, which is used to encrypt information sent to the Payserver and decrypt information received from the Payserver.

Embodiments of the present invention allows Internet users to pay for goods and services they buy from Web sites. Users may also receive payments from Web sites or transfer money between themselves and other Internet users. Users may check their account balances using any computer that is coupled to the Internet and able to read the Wallet application.

Embodiments of the present invention allow Internet users to buy goods while remaining anonymous. No credit application needs to be completed, and no personal information needs to be given out over the Web. The Wallets may simply be purchased using cash, and redeemed as such over the Internet. Since they may be purchased with cash, they are available for use by persons where there is no credit available due to a lack of banking infrastructure, or by persons whose poor or lack of credit history makes credit an unavailable option to them. Also, since they may be purchased for cash, the Wallet buyer's name and address need not placed electronically or otherwise on the Wallet, or otherwise associated with the Wallet.

A further aspect of the present invention provides a system for financial transactions. The system includes a Payserver coupled to a network, where the Payserver receives instructions through the network, and when the Payserver receives a transfer instruction, the Payserver effects transfer of funds from a first Wallet's account to a second Wallet's account. The Payserver includes an account database containing account numbers and accompanying account fund balances, a router database containing a first Payserver network location identification for the first account and a second Payserver network location identification for the second account, and a transaction database to store transitions handled by the Payserver. Optional refinements include encrypting data transfers between the Wallet application and the Payserver and encrypting data stored on the Wallet medium. The system may further include a second Payserver having a similar or same design as the first Payserver. The ease of use the Wallet purchase is enhanced by a system architecture which makes a network of more than one Payserver appear to be one Payserver. This is accomplished by the use of a routing database and software on each Payserver, which can couple Wallet applications to different Payservers as needed to complete financial transactions without requiring assistance from the user.

Yet another aspect of the present invention provides an apparatus for conducting financial transactions. This apparatus comprises a tangible transportable medium which is readable using a first computing device, an executable code portion stored on the tangible medium; and a data portion stored on the tangible medium. The programmable code portion comprises an executable program, and the data portion comprises a first security identifier for credit transactions, and a second security identifier for debit transactions. A better understanding of the nature and advantages of the present invention may be gained with reference to the following detailed description and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 A illustrates the major components of a system for transferring payments between a user and a Web site;

Figure IB illustrates the interaction between the major components of a system during a transfer between two users;

Figure 2 shows the information transfers for a user-to-Web-site payment transaction;

Figure 3 is a flow chart for a user-to-Web-site payment transaction; Figure 4 shows the information transfers for a Web-site-to-user payment transaction;

Figure 5 is a flow chart for a Web-site-to-user payment transaction; Figure 6 depicts the information transfers for a simplified user interface for one embodiment of the present invention;

Figure 7 is a block diagram of a Web site used in managing a system in accordance with one embodiment of the present invention;

Figure 8 illustrates a block diagram for a multi-Payserver architecture; Figures 9A to 9E show the input and output parameters at various points in different transactions; and

Figures 10A and 10B illustrate the major components in transactions performed in accordance with the present invention.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

Figure 1A illustrates the major components of an exemplary embodiment of the present invention. The components include a user 100, Wallet 110, seller's Web site 120, Payserver 130, personal computer 140, and Internet 150. The Wallet is a stand alone application on a 3.5 inch (90 millimeters) or other size diskette. This diskette may also be referred to as a floppy disk, a magnetic disk, or a micro floppy disk. These types of floppy disks use magnetic media to store data, and are typically written to and read from using a computer floppy drive. The disk is usually formatted before it is used. One format is commonly referred to as IBM-compatible format. The disks may be single or double sided and can be low or high density formatted. A 3.5 inch double sided, high density disk holds up to approximately 1.44 megabytes of data. The disks usually have a write protected tab; when the tab is in a first position, the disk is writeable and readable. When the tab is in a second position, the disk is not writeable, but is readable. Alternately, the Wallet may reside on a read/writeable compact disk (CD), read/write digital video disk (DND), memory, flash memory, palmtop device, laptop computer, desktop computer, or any other device capable of electronic transfer and storage.

The Wallet 110 is implemented as an HTTP (Hyper-Text-Transfer Protocol) client, communicating to the Payserver 130 via SSL (Secure Socket Layer). The Payserver 130 is implemented with HTTP server as a front-end that accepts connections to Wallets and routes them to back-end transaction processing software. The Wallet component in the seller-site is implemented as a set of CGI/IS API (Common Gateway Interface / Internet Server Application Program Interface) scripts that are invoked by the Payserver 130 via SSL- encrypted HTTP. Local companies can distribute the Wallet applications on diskettes or other tangible media in different countries in exchange to local currency. Floppy disks provide an excellent medium since they are durable and have a low manufacturing cost. Wallets can be pre-packaged for fixed initial amounts of money and sold by retailers. Much like phone calling cards, pre-packaged Wallet diskettes can be sold virtually everywhere, in any retail outlet, including convenience and drug stores, gasoline stations, supermarkets, and the like. These Wallets can be a great gift or incentive item. Wallets are transportable in that they may be carried similar to cash or a palmtop or handheld computer, as opposed to carrying a desktop or laptop computer.

They can also be produced one by one for each customer for a requested amount of money. In this case, the selling company preferably has an Internet connection and personal computer. A local Internet Service Provider (ISP) would be a suitable type of company to perform this type of Wallet sales and distribution. Such distributors can receive an incentive for each distributed Wallet, which will also provide them with a unique opportunity to be a part of rapidly growing Internet commerce. Each distributor may also

S place advertising on the surface of the case holding the diskette or other tangible media. As the user spends the money from one Wallet, he can either purchase a new Wallet, or receive some money into the existing one from an online bank, where he has an account. The user can move any amount from one of his Wallets to another. This provides for easy consolidation of funds from all user's Wallets into one.

The user 100 is the user of the Wallet 110 who wishes to purchase something from the seller's Web site 120. Payserver 130 stores account information, passwords, transactional information, and the like, and passes information between the Wallet 110 and seller's Web site. An application similar to the Wallet program is also present as a part of the seller-site 120. Commercial- Web-site owners can be provided with software that can be integrated into the site, so that accounting and authorization of payment transactions is fully automated. An automated online administration system is also provided in some embodiments of the present invention. This helps the Web site owners analyze recent payment activity information, as well as customize parameters of interaction of their Web site with the payment system. Most Web site owners practicing online commerce will find participation in this system very attractive, because it will bring them a large number of new customers, which they would not be able to reach otherwise.

Payserver 130 may be a server, computer, desktop computer, notebook or laptop computer, palmtop computer, mainframe computer, or any other appropriate computational device. Payserver 130 is the third party that stands between the payee and the payer in each transaction and actually performs it. Payserver 130 is a computer server system, independent of any seller-site, to which the Wallet application and seller-site connect via Internet. During each transaction the Payserver 130 receives data from the paying party and, at that party's request, transfers funds from the paying party's account to another account. All data about accounts is kept in a database. Each account is associated either with a Wallet or with a seller-site, or a particular set of goods and services in the seller-site.

The personal computer 140 runs the Wallet application. Personal computer 140 may be a desktop computer, notebook or laptop computer, palmtop computer, mainframe computer, server, or any other computational device capable of running an application. The personal computer 140, Payserver 130 and seller's Web site 120 are coupled to the Internet 150 by connections 145, 135, and 125. There may be Internet service providers between these connections and Internet 150. Internet 150 may be the World Wide Web, an intranet, or an ISP domain. Connections 145, 135, and 125 can be wired, twisted pair, RJ-45, optical, wireless, or any other data connection. The personal computer 140, Payserver 130, and seller-site 120 are said to be networked together.

The process of making a payment is quite simple. The user opens a Wallet program off the diskette sometime before he enters the "check out" section of an online store. The user selects this system from among the accepted payment methods and presses one button on the Web form. Following that, the user confirms the purchase with the Wallet application, which results in processing of the payment transaction. The transaction takes several seconds, and can be almost immediate if the user's Internet connection speed is high, for example, if a broadband connection such as Tl, cable, satellite, or DSL is used. After that, the user obtains the purchase from the selling Web site.

Specifically, the user 100 logs on to the Internet 150 through connection 145, using the personal computer 140, and visits the seller's Web site 120, which is connected to the Internet 150 by connection 125. The user 100 will typically use a browser interface residing on the personal computer 140 to view the Web pages on seller's site 120. Browsers which may be used include Microsoft Internet Explorer and Netscape Navigator. The user 100 shops and browses at the sellers Web site 120, choosing goods or services for purchase. When the selection has been made, the user 100 proceeds to what is typically a check-out portion of the seller's Web site 120. In one embodiment of the present invention, an option to use a Wallet 110 is provided on the seller's Web site 120. The user selects that option, and is given the seller's Web site's nickname, or payeelD, along with the purchase price, by the seller's Web site 120, and is instructed to start the Wallet application.

If the Wallet program resides on a diskette, the user 100 starts the application by inserting the Wallet 110 into the appropriate drive, typically the "A" drive, on the personal computer 140, and instructing an operating system residing on the personal computer 140 to run the Wallet application. Examples of such operating systems include Microsoft Windows 95, 98, Me, and NT, as well as Linux, Sun OS, and Unix. The program will begin by starting a Wallet graphic interface on the personal computer 140, and asking the user 100 for a password. User 100 enters the password, and the Wallet application sends the password, along with other account information over connection 145 through the Internet 150, and to the Payserver 130, which is connected to the Internet 150 over connection 135.

The Payserver 130 receives this information, locates the account balance, and sends it back through the path described above, to the Wallet application. The Wallet application, through the Wallet graphic interface, asks the user to enter the seller's Web site's nickname, as well as the payable amount. Once entered, this, and other information, is sent through connection 145 to the Internet 150, connection 135 to Payserver 130.

Upon this data reception, the Payserver can check the information. Appropriate common gateway interface information can be sent to the seller's Web site 120, where a form can be brought up for viewing by the user in the browser interface running on the personal computer 140. This form is completed by the user to complete the purchase, and the records in the Payserver 130 and Wallet 110 are updated.

In one embodiment of the present invention, a user 100 can check the account balance for a Wallet 110 by inserting it into an Internet connected personal computer 140, or other computing device. For example, if the Wallet 110 is on a diskette, the user 100 inserts the Wallet 110 into a floppy disk drive on the computer, typically the "A" drive, and the application starts. The application requests the password, and provides the account balance. The application finds the account balance by coupling through the Internet to a Payserver at an Internet address stored in the Wallet. The Payserver finds the Payserver which owns the account. If the Payserver which owns the account is also the Payserver coupled to the application, the Payserver determines the balance, and sends it to the application for display to the user.

If the Payserver which owns the account, and the Payserver coupled to the application are different, the Payserver coupled to the application instructs the application to couple to the Payserver which owns the account. The application then couples through the internet to the Payserver which owns the account, and the balance is determined, and sent to the application for display to the user.

It is also possible to make payments from one Wallet to another or from a Web site to a Wallet. Thus, the system can provide a way of sending small amounts of money from one place to another, or it can be used to withdraw money from an Internet bank. Figure IB shows the components and interconnections for one embodiment of the present invention used in transferring money from a first user to a second user. Included are a first user 100, who in the example below will be sending money to a second user 160. The two users may be separate individuals, or may be the same person, for example when that person wants to transfer money from one account to another, say to consolidate funds. Also included is a first Wallet 110, a second Wallet 170, a first personal computer 140, a second personal computer 180, and a Payserver 130. The first personal computer 140, the second personal computer 180, and the Payserver 130, are connected to the Internet via connections 145, 185, and 135. The personal computers 140 and 180 may be one machine, for example

% when one user 100 wants to transfer money from one account to another, or two users 100 and 160 want to share a computer for a transfer between themselves. The process of payment from one Wallet to another is the same as from a Wallet to a seller-site, except that the Payee ID is the identifier of the Wallet to which funds are being sent. Therefore, the owner of the receiving Wallet must give that identifier to the owner of the sending Wallet. After transaction is performed, both Wallets' balances will increase and decrease respectively. Such user to user transactions are simple to perform using embodiments of the present invention. This compares well to credit card and debit card systems, where payments go from individual to store, but not from individual to individual. In Wallet to seller-site transactions, both the Wallet and the seller-site must present a unique identifier to the Payserver. These identifier are the key to all accounts in the Payserver' s database. Accordingly, each account has a pair of identifiers, both uniquely identifying the account in the database. But the system prevents the discovery of one identifier by using the other. One of the two identifiers is used in all account-debiting operations where money is withdrawn from the account, and the other one is only used in debiting operations, where money is deposited on the account. They are called debitlD and creditlD, respectively. The payment transaction from a Wallet to a seller-site requires the debitlD of the Wallet and the creditlD of the site. Accordingly, the payment transaction from a Web site to a Wallet requires that site's debitlD and the Wallet's creditlD. The system prevents the withdrawal of money from an account using a creditlD. The system also prevents the deposit of money to an account using a debitlD. For added security, in some embodiments of the present invention a Web site will have no debitlD.

Of the two account IDs, the most sensitive one is the debitlD. For security reasons, all transactions require sending any debitlD in encrypted form only, while a creditlD does not have to be encrypted and can be used publicly. The creditlD and debitlD are tied to the Wallet itself, rather than the user as an individual. This arrangement ensures that it is not necessary for the identity of the user to be known to the other parties in the transaction. In this way the privacy and anonymity of the user is protected. Also, one user may own several Wallets, and may thus appear to have a number of alter-egos. As with all financial transactions, security and accuracy are of concern.

Accordingly, special attention is given to the way the Wallet (as well as in-site Wallet component) authenticates to the Payserver. The authentication consists of several types of data including constant account credentials such as user's password, and account debitlD. Also, per-transaction account credentials such as last transactionlD, SSL-level authentication data, and SSL client certificate can be used.

As an additional measure of security, the debit accountlD is stored by the Wallet in encrypted form that is produced by a full strength cryptographic algorithm, such as triple-DES (Data Encryption Standard) with 168-bit key. Optionally, the Wallet application does not use the standard way to access the files on the diskette, but rather it uses low-level access to disk clusters to establish its own encrypted formatting of the disk. One embodiment of the present invention uses DES-3, in combination with a public and private key pair such as in RSA or Diffle-Helman algorithms. These algorithms are used when communicating via SSL between a Wallet and a Payserver, or between two Payservers within a multi-Payserver network.

When the Wallet is first issued, it is assigned a pair of debit and credit accounts and an SSL client certificate; these are permanent credentials that exist throughout the life of this Wallet. The third credential that is sent by the Wallet along with the first two with all types of requests to the Payserver is the transaction identification, or receipt code, of the last successful payment transaction in which this Wallet was the payer. This third credential ensures that only one copy of a Wallet may be used. If a card is somehow copied, and the password is known, only the Wallet used next, either the original or copy, can be subsequently used. If the original is used first, the copy is no good. If the copy is used first, the owner of the original will become aware of the existence of the copy on the next attempted use of the original Wallet, and can put an end to subsequent uses of the copy. Credit cards and debit cards can continue to be used after unauthorized transactions, and the owner is typically not aware until a bill for payment is received.

This authentication scheme has several advantages. Access to the Wallet is protected with a user password, that is, if a Wallet is physically stolen, lost or copied, it is useless without a password for a person who finds, steals, or copies it. Also, the debit accountlD is kept encrypted such that in an unlikely event of a pirate attack on the Payserver, the intruders won't know the accountlD of their Wallet and will not be able to access that account's data. This highlights an advantage of systems consistent with the present invention as compared to the prior art such as smart cards. In some, if not all, smart card systems, the funds associated with the card are placed electronically as "micro-coins" on the card itself. This poses the potential for an attack on the card itself being sufficient to change account balances. Also, the account cannot be credited unless the smart card is connected to the system. For example the smart card may have to be in a PCMCIA (Personal Computer Memory Card International Association) slot in a computer which is connected to a banking system. In various embodiments of the present invention, the account balances are kept on the Payserver which owns the account. This means that an attack on a Wallet itself is not sufficient to change the account balance. Also, a Wallet account can be credited without the Wallet being in a computer. Furthermore, smart cards require preloaded software to reside on the personal computer which is being used. A Wallet does not require a software application on the computer, rather it comes self-contained with the application on the diskette or other medium. Currently smart cards are not designed as a payment system, rather as a means of identification for cell phones and the like.

Since the Wallet sends an SSL client certificate, the Payserver will only establish SSL connections with an application that identifies itself as Wallet by presenting the client certificate that was issued by the Payserver at the Wallet's creation time. Also, only the Wallet program that can present the correct last transactionlD to the Payserver is usable at any given time. Each Wallet stores all data in non-standard, encrypted disk format. This makes it difficult to duplicate the files stored on the disk using most standard file-copying means.

The Wallet has two portions, a program portion and a data portion. The program portion can be in the form of a .exe, or executable program. The program includes encryption software such as a full strength cryptographic algorithm like the triple-DES (Data Encryption Software) with 168-bit key as mentioned above. The RSA The data part includes the identifiers creditlD and debitlD, as well as the last transaction identity.

Figure 2 shows the transactions for a purchase by a user consistent with one embodiment of the present invention. All transactions take place through the Internet, an intranet, an Internet service provider, or similar information transfer apparatus. The user 100 logs on to the Internet 150 using a browser interface, and visits the seller-site 120. The user 100 shops and browses the seller-site 120, choosing the products or services for purchase. When the selection has been made, the user 100 proceeds to what is typically a check-out portion of the seller-site 120. In one embodiment of the present invention, an option to use a Wallet 110 is provided on the seller's Web site 120. The user selects that option, and in transaction 200 is given a nickname (payeelD), or other identifying alpha-numeric sequence, along with the purchase price, by the seller's Web site 120, and is instructed to start the Wallet application.

A\ If the Wallet application resides on a diskette, the user 100 starts the application on the personal computer 140 in act 205. The application will begin by starting a Wallet graphic interface on the personal computer 140, and asking the user 100 for a password, typically a unique alpha-numeric sequence, in act 215. User 100 enters the password, and the Wallet application sends the password, a last transaction identification, and account identification to the Payserver 130 in transaction 210.

The Payserver 130 receives this information, locates the account balance in its database in act 225, and sends it back to the Wallet application in transaction 220. The Wallet application, through its graphic interface, asks the user to enter the seller's Web site's nickname, as well as the payable amount in act 235. Once entered, the account identity, last transaction identity, password, payable amount, and site nickname are sent to the Payserver 130 in transaction 230.

Upon this data reception, the Payserver 130 checks the account identification, last transaction identification, and creates a transaction record in act 245. Also, the seller- site's common-gateway-interface call information is retrieved, and a new transaction identification is generated. This new transaction identification, along with the amount, and site nickname is sent from the Payserver 130 to the seller-site in transaction 240. The seller- site 120 checks the amount, and nickname, and saves the new transaction identification in a file or database in act 135. Transaction 250 is an error status indication sent by the seller-site 120 to the Payserver 130.

At this point, the Payserver 130 can update the account balances for the seller- site 120 and user 100, and save them into a transaction record. The Payserver 130 can provide the new transaction identification and updated user account balance to the user in transaction 260. The Wallet graphic interface displays this information in act 275. The user sends the new transaction identification to the seller-site 120 in transaction 270 to complete the purchase.

To perform the payment, the Wallet establishes connection to the Payserver via TCP/IP (Transmission Control Protocol / Internet Protocol) using Secure Socket Layer (SSL) to encrypt and sign all transferred data using a standard public key encryption scheme, as well as to authenticate the paying Wallet and the Payserver to each other using digital certificates.

As seen in the above description, the Wallet needs to exchange data with the Payserver at the Wallet program start-up in order to find out the current balance on the Wallet's account, which is then displayed to the user, and when the "PAY" button is pressed

1 by the user requesting a payment transaction. The Wallet also needs to exchange data with the Payserver when the user wishes to change the Wallet password.

At start up, the sequence of data exchange with Payserver is as follows. First there is handshaking and authentication of parties in the SSL layer. Second the Wallet sends its debitlD, last transactionlD and user's password, and third the Payserver sends back the current balance in the Wallet. Note that the current balance is a sensitive information, and its retrieval requires the Wallet to provide the private key, that is the debitlD. These data transfers are shown in Figure 9A. All CGI (Common Gateway Interface) function parameters are sent via POST HTTP request; and the data format for all output parameters is "field_name: value."

When the user presses "PAY" in the GUI (Graphical User Interface) window, the following sequence is initiated: first there is SSL-layer handshaking and authentication, second the Wallet sends its debitlD, the creditlD of the seller-site, the amount of payment, password, and the last transactionlD (creditlD is entered into the GUI window by the user). Third, having received the data, the Payserver performs the transaction itself and sends the new transactionlD to the seller-site, as well as to the user's Wallet. Fourth, the Wallet GUI displays and saves the new transactionlD. These data transfers are shown in Figure 9B.

Having received the payment request from the Wallet, the Payserver does the following: performs database update that reflects the balance transfer between account and registers this action under a new transactionlD; initiates connection with Wallet component in the seller-site via HTTP-SSL, and sends to it the new transactionlD. This is done by invoking a well-known URI (Uniform Resource Identifier) on the seller-site and sending it a POST request. The Payserver then receives a return code of the CGI script, showing whether the transactionlD is accepted and saved by the seller-site successfully (in case of an error return, the payment transaction must be canceled by the Payserver); and exchanges data with the user's Wallet as described above. This is shown in Figure 9C.

Figure 3 is a flow chart illustrating the acts in a payment from a user to a seller's Web site in accordance with one embodiment of the present invention. The process is considered from the point of view of actions that need to be taken by the buyer and the seller- site. Initially, a fixed amount of money is prerecorded on each Wallet application. For example, there can be Wallet-diskettes of $5, $10, $20, $50 or $100 value, or any other desired amount. Alternately, the amounts may be in other currencies. In the process of using a Wallet to pay or receive funds, the amount of money in it changes accordingly.

1* Since the Wallets are purchased ahead of using them, there is no credit being given out, and no credit check needs to be done to protect the issuer. Therefore, persons with no or poor credit history, or those who simply wish to keep their credit information private, can purchase these anonymously, and without a credit check. Debit cards do not require the granting of credit either, but use account numbers which are tied to an individual such that anonymity is lost. Embodiments of the present system use creditlDs and debitlDs which are tied to a Wallet, not the user, thereby protecting the user's identity. Also, since funds are placed in the account ahead of time, there is no "credit limit" on the amount of money that can be sent to another account. In act 300, the buyer browses a Web site to select goods or services that he wishes to buy. This part of the online shopping process completely depends on the organization of each particular site and is beyond the scope of this document. Having selected a list of goods, the buyer is also likely to have to choose among several methods of payment that this site accepts, such as credit cards or a payment method consistent with an embodiment of the present invention. It is assumed that the buyer chooses the latter payment method in act 310.

The buyer enters a page of the Web page devoted to payments from a Wallet application provided by the Web site in act 310. In act 320 the buyer sees a list of selected goods, the total amount due and instructions to insert a Wallet diskette and start the Wallet program from it. The user then starts the program, typically by entering the Wallet in the "A" drive of a personal computer, and entering a password when prompted. The program shows up on the screen as a separate window, and in act 330 the buyer enters, according to the instructions provided on the Web site's page, the Payee ID, which is a word consisting of letters, numbers, or symbols that uniquely identifies the site and selected goods, as well as the amount of payment.

In act 340 the buyer presses the "PAY" button in the Wallet program window. In a few seconds, the Wallet program displays a transaction confirmation number ("receipt" No.). This is a unique number that identifies the payment transaction accomplished on request of the buyer. It is equivalent to a purchase receipt issued by a cash register in a regular store in that it confirms that the person, who possesses the receipt, has paid in full and is eligible to receive the merchandise.

Following the instructions of the Web site, in act 350 the buyer enters the transaction confirmation code into a form on the Web page and submits that form. Submission of the form may be done by pressing the enter or return key on a keyboard, or

If selecting an on-screen button on the Web page. This results in the transaction code being sent to the Web site where it is then verified, and the Web site releases and delivers the goods or services purchased by the buyer. The process of delivering the merchandise fully depends on its nature and on organization of each Web site, and is outside of the scope of this document.

The Wallet program can also function in an automatic data entry mode, where payment information that would otherwise be manually entered by the buyer is instead automatically sent to the Wallet from the Web browser, and the receipt (i.e. transaction) code is then received back. In this mode, the user only has to press two buttons, one on the Web form in order to initiate the payment, and another one in the Wallet window to confirm payment information.

Figure 4 shows the transactions between, and acts by, the user, Payserver, and a debit-site in a transfer of funds from the debit-site to user, performed by one embodiment of the present invention. The user 100 initiates contact with a debit-site 400 using browser software on a personal computer 140. At the debit-site 400, the user 100 requests for an amount of money to be transferred from the debit-site 400 to the user 100. In transaction 410, the user selects a method of payment, which uses an embodiment of the present invention.

The debit-site 400 generates a HTML page with a hyper-link or form button linked to the Payserver 130, and in transaction 420 passes a site nickname, a comment, and a return URL (Uniform Resource Locator) to the Wallet application running on the user's 100 personal computer 140. The Wallet application directs the site nickname, comment and return URL to the Payserver 130 in transaction 430. In transaction 440, the Payserver 130 provides an HTML form for viewing on the Web browser running on the personal computer 140. The HTML form shows the comment, and asks the user to enter a password or Wallet nickname.

The user enters the password or Wallet nickname, and the Wallet application forwards the password along with the site nickname, and return URL to the Payserver 130; transaction 450. In act 435 the Payserver 130 retrieves the common gateway interface and client certificate, and connects to the debit-site 400. Once connected, in transaction 460 the Payserver 130 sends the site nickname, client certificate, and return URL to the debit-site 400.

Upon reception of this data, the debit-site 400 retrieves the transaction parameters including the account identification, amount to be transferred, and the last

⁽5 transaction identification from a file or database in act 465, and sends this data to Payserver 130 in transaction 470. The Payserver 130 performs act 475, which is to check the account identification and last transaction identification, and create a transaction record, including the generation of a new transaction identification. Payserver 130 further retrieves the sites common gateway interface call information, and sends the new transaction identification, amount, site nickname, along with an instruction that the payment is to be completed to debit- site 400. Debit-site 400 stores this information to a file or database, act 485, and informs the Payserver 130 whether there was an error in transaction 490. Payserver 130 updates the debit-site 400 and Wallet 110 account balances, and saves the balances into a transaction record, and sends the new transaction identification to the user in transaction 497.

In one embodiment of the present invention, the Wallet program is not used during the crediting transaction from seller-site to such a Wallet. The algorithm used is as follows. First, the user enters a Wallet creditlD in an HTML form in the seller-site and presses a button to submit it. The same form can contain site and merchandise-specific form fields (as "hidden" ones). The site's creditlD is one such required parameter. Submission of the form by the user sends a POST request to the Payserver to initiate the crediting transaction. This transaction is shown in Figure 9D. The Payserver initiates an HTTP-SSL request back to the seller-site, invoking a URI that accepts site's creditlD and a password. In various embodiments, an SSL-level client certificate may be alternately used, or used in combination with the above. The seller-site returns its debit-CD, amount of payment, and the last transactionlD. The URI, password and client certificate (if applicable) are stored in the Payserver' s database and retrieved by creditlD of the seller-site. This particular transaction is shown in Figure 9E.

The Payserver validates the data received from the seller-site and commits the transaction in the database by changing balances of the site's and the Wallet's accounts. The new transaction is then registered in the database under a new transactionlD. The Payserver calls another URI of the in-site Wallet component via HTTP-SSL. This URI is also stored in the Payserver's database and is retrieved by the site's debitlD. Using the URI, the Payserver sends the new transactionlD to the seller-site and receives an error code indicating whether the site has successfully received the new transactionlD. In case of an error, the Payserver cancels the payment transaction. The processing of payMoneyFromSite.cgi request (see Figure 9D) finishes and redirects client's Web browser to a new URI that was passed as a parameter.

lb Figure 5 is a flow chart of a Wallet application receiving funds from a crediting Web site consistent with one embodiment of the present invention. This process is referred to as crediting transaction. A crediting transaction is a process where the Web site is the paying party, and the Wallet user is the receiving party. It is assumed that the client has already selected a service that includes crediting money to his Wallet. For example, the Web site may be an Internet bank where the Wallet user keeps his checking account. The user enters the Web site in act 500, and identifies himself, if such identification is necessary. In a method according to one embodiment of the present invention, the user makes a request to have money be credited the Wallet account in act 510, and the client enters a Web page devoted to crediting money to Wallet accounts in act 520.

In act 530 this page instructs the user to enter the identifier of the Wallet- diskette into a Web form on the page and then submit it. A Wallet identifier is a number printed on the diskette's label and also displayed in the Wallet program's window. This Wallet identifier is the Wallet's creditED. The user is not required to launch the Wallet program for this type of transaction. Submission of the Wallet's identifier, or creditlD, into the Web form is the only action the client is asked to perform. The rest of the transaction is performed by the crediting site. In particular, with help of a software program that is functionally analogous to the Wallet application, the Web site performs a payment to the user's Wallet using the Wallet identifier that the user has submitted in act 540. In act 550 the site then receives a transaction code confirming its payment and displays it to the user as a confirmation of the crediting transaction.

In the case of a Wallet - to - Web site payment, an additional component can be used by Web sites to make the payment process easier for the user. In essence, this component automates the job of entering payeelD, or site nickname, and payment amount information into the Wallet window, as well as copying or typing the resulting transaction identification back into the Web browser's window. With this component, the whole payment process consists of pressing just two buttons - the "PAY" button and the confirmation button, and does not require any typing from the user.

The component is a combination of a Java applet and a JavaScript code, which are embedded in the HTML page of the seller Web site that handles payments. The applet uses parameters of payment (site creditlD/merchandiselD, amount of payment) that are supplied to it by the JavaScript calling code, which in turn receives them as a part of the HTML code produced by the server-side script. The user interacts with the applet by simply pressing a "PAY" button on the Web page. This makes the applet connect to the user's Wallet, and requests a payment transaction. The Wallet application requests user's confirmation in the form of a "Yes/No" dialog box, and if user agrees, it automatically initiates a payment transaction with the Payserver via a secure connection and receives a transaction receipt identification, which it then passes back to the applet. The applet returns the transaction ID to the JavaScript code that automatically HTTP-POSTs this transaction identification to the seller-site, where it is then verified by the server-side script that enables delivery of the merchandise to the user. Figure 6 shows the acts performed by, and transactions between, the applet 600, Wallet application 610, and Payserver 310, used to simplify payment transactions in one embodiment of the present invention. The sequence is initiated by the user clicking the pay button on the Web page in act 615. The helper applet 600 contacts the Wallet application 610 with the site nickname, or payee identification, and the amount to be paid in transaction 620. If the information is correct, the user clicks "yes" on a confirmation dialog box in act 630. The Wallet application 610 requests the new transaction identification from the Payserver 130, and receives it in transaction 650. The Wallet application 610 passes the new transaction identification to the helper applet 600, which returns it to the seller-site via HTTP POST in act 665.

Figure 7 is a block diagram of a system Web site used in managing a system in accordance with one embodiment of the present invention. This system Web site is part the Provider Network. The Provider Network serves as an agent between the parties in a payment transaction. It consists of a number of mutually interconnected Payservers operating at sites of various Transaction Processing Providers (TPP), that have licensed the use of the technology, the software and the hardware. Typically, a TPP is a bank, an ISP, or a telecommunications company. Each Payserver, owned by a TPP, can be used to manufacture Wallets or in-site Wallet components and process payment transactions initiated by these Wallets. The fees charged per each transaction are shared by a pair of TPPs in case the Wallet originating the payment and the Wallet receiving the payment belong to two different TPPs. This system Web site will be useful to three different entities, or participants in systems designed and operated according to embodiments of the present invention. These three are the owner of the Payservers or TPPs, the owners of the Web sites which accept Wallets for payment or debit purposes, and the users of the Wallets. This system Web site can provide the ability for each of these three to manage their respective activities in the system. TPPs can create new Wallets on-line in block 797, and manage or monitor their activity, and the activity of their entire Payserver. The Web site owners can configure aspects of how their Web site automatically sends data to and receives data from the Payserver, and can manage the monetary accounts associated with their in-site Wallet component with block 780. Users can use block 790 in the system Web-site of Figure 7 to check the history of their recent transactions.

The Web site is has two areas, the open area 700 and the password protected area 710. The open are 700 has a page or group of pages 720 which provide overview of the system and its use 740, along with sample Wallet program 750, and a directory of Web sites accepting or distribute Wallets 760. A portion 730 of the open area 700 is for Web site administrators. These pages 770 provide instructions and demonstrations on how to set up a site so that it is able to accept payments from Wallet users. In a password-protected area 710, Web site administrators are provided in block 780 with an account configuration and revenue tracking Web application that keeps track of each transaction for an account, as well as allows to set up and modify parameters of interaction between Payserver and the seller-site's CGI programs. Also, in password-protected area 710, users are provided with a payment tracking Web application that allows the user to display a history of recent transactions for one or more of the user's Wallets in block 790. In block 797, distributors have access to an application that allows manufacturing a new Wallet off the Web site for sale to a potential user. Through the same application, Wallet distributors can be provided with the ability to track their sales.

Figure 8 represents the main aspects of a multi -homed Payserver architecture, where Wallet A and Wallet B possibly belong to different Payservers (PS-Y and PS-Z). The network of Payservers is dynamic and is capable of relocating existing domains of Wallet accounts from one Payserver to another without interrupting the service, as well as in-service insertion and removal of Payservers. The same physical Payserver host is capable of hosting a number of Wallet Account Domains (WAD). The information about current location of each WAD is kept by the Payserver Routing engine, a part of each Payserver responsible for routing Wallets' and other Payservers' requests. At first, the Wallet requesting a payment transaction is dynamically routed to the Payserver that is hosting the domain of accounts to which this Wallet belongs. This Payserver will take care of the actual payment transaction. In the case where the receiving party's Wallet also belongs to the same domain, or a different domain but hosted by the same Payserver, the entire transaction is done by that Payserver. Otherwise, the host of the receiving party's Wallet is contacted to confirm and finish the crediting part of the transaction.

Figure 8 shows the major components, acts, and transactions involved in an owner of Wallet "A" 800 sending $10 to the owner of Wallet "B" 810, where the accounts for A and B are held on different Payservers. Alternately Wallet B 810 may be a seller's Web site. Also included are a Dynamic DNS (Domain Name System) 820, router PS X (Payserver X) 830, owner of account "A" PS Y 840, and owner of account "B" PS Z 850. PS X, PS Y, and PS Z can be routers, servers, computers, desktop computers, laptop computers, mainframes, and any other appropriate computing device. The transfer of funds begins with the Wallet application on Wallet A 800 going on line and finding the router's IP or address from the dynamic DNS 820 in act 852. The Wallet then connects to the router, and requests the address of the owner of Wallet A in act 854. This information is not necessarily known to the Wallet application, since the account may have been sold or transferred, for example to a different owner on PS Y, or on a different Payserver, such as PS Z. The term owner is used in this context to indicate the file storing the account information. Payserver X looks up the owner of account A in its router database 833, and in this case determines that it is PS Y. The Wallet application on Wallet A 800 connects to Payserver Y, and instructs it to pay $10 to B in act 858. In act 862, $10 is subtracted from A's account in the account database 847 on PS Y 840, and the transaction is registered in transaction database 849 in act 864.

Payserver Y 840 looks up the owner of account B in its Payserver router database 843 in act 866, and in this case determines it to be PS Z 850. The router database in each Payserver should be identical to one another. An instruction to pay the $10 to B is sent from Payserver Y 840 to PS Z 850 in transaction 868, and the $10 is added to B's account in the account database 857 of Payserver Z 850 in act 872. This crediting transaction is stored in the transaction database 859 of Payserver Z 850 in act 874, and a receipt code is sent to Wallet B 810 if Wallet B 810 is a seller's Web site, and to Wallet A 800 otherwise.

One advantage of this architecture are that Wallet account domains (WADs) are easily transferable. For example, a bank may sell a WAD, in which case part or all of an account database is moved, or the Payserver simply changes hands. Also, a single computer or server may also own more than one Payserver, that is more than one WAD

Each account may be an individual user, or one may be a user and the other a Web site, or they may both be Web sites. The payment transaction may be handled by one Payserver if both accounts are held on the same Payserver. Alternately, the transaction may lo be handled by two Payservers, for example if the payer account is held by one Payserver, and the payee account is held by a different Payserver. Alternately, the transaction maybe handled by three or more Payservers, for example if an account is sold and moved to a new Payserver, an original Payserver may need to redirect a payment request to the new Payserver, and the other account in the transaction may be held in yet a different Payserver. Each of the transactions described may involve one Payserver, two Payservers, three Payservers, or more.

Each Payserver in one embodiment of the present invention includes payment processing software, and a database for storing a number of Wallet identifications or WADs, or a cluster of Wallet identifications. A single provider, or TPP may own more than one Payserver, a the processing software may operate on more than one cluster of Wallet identifications. Each of the transactions described above may involve one, two, three, or more Payservers. Again, in financial transactions involving two Wallet applications, both may be owned by one Payserver, or they may be owned by two separate Payservers. The Wallet applications may be owned by an individual, say on a floppy disk, or it may be an in site application on a Web site which accepts Wallet payments, or credits Wallet accounts.

From the point of view of a user, and the Wallet program being used, the entire Payserver network acts as a single entity. In other words, the network of Payservers appears as one Payserver. For example, at the time of manufacture, a Wallet is programmed with the routing ID of the Payserver which owns the Wallet account. (In alternate embodiments, a centralized Payserver router, or other computing device's address may be used.) The Wallet account may be subsequently sold, or otherwise moved to a new Payserver. But when the Wallet application is run, and the original owner Payserver is reached, the application is routed to the Payserver to which the account was sold. This is transparent to the user; the application and Payserver handle the routing. If the transfer of funds is to yet a third Payserver, the connections and data transfers are again unseen by the user. In this manner, the Payserver network appears as one Payserver to the user.

The exemplary embodiments of the present invention are illustrative and not limiting. The invention is not limited by the exact configuration shown in any of the figures. Other variations of the present invention are obvious in light of the above, and will be apparent to those skilled in the art. For example, the Wallet application may be written on other media such as CDs and DVDs without departing from the spirit and scope of the present invention. These equivalents and alternatives, along with obvious changes and modifications, are intended to fall within the scope of the appended claims.

U Further embodiments of the present invention may be made consistent with the following DotCoin™ - Online Cash Payment System Draft Specification.

0. Background. One of the key advantages of DotCoin™ over the existing electronic payment systems is its independence of credit card and bank financial networks. It is a well-known fact that banking systems in all countries are quite conservative and it takes them long time to switch to a new technology. This is why the existing online payment systems have had trouble spreading into countries and regions where no banking system support is available. However, unlike other technologies, DotCoin™ does not require to be supported by banks or credit card associations and therefore, can easily function in regions where no such support exists. This will allow DotCoin™ to take advantage of the new market with virtually no competition from any other known systems.

0.1 DotCoin™ online payment service description.

DotCoin™ is a system that Internet users can use to pay online for any product or service that they purchase from a Web site. In essence, this system will be delivering payments between commercial Web sites and their customers.

Internet users will be provided with a software program stored on a regular 3.5" diskette, which they will use every time they want to make a payment. Such a program, carried on a diskette, is called DotCoin™ Wallet. The key benefits for the users are: DotCoin™ Wallets are compact and can be carried in a pocket; they can be used on virtually any Internet-connected personal computer with no pre-installation required - this is especially useful in case when a person often uses computers in public places, such as libraries, schools; DotCoin™ Wallets will be available for purchase from a local distributor and can be sold to anyone, in exchange to local currency; and they provide much better security and protection from fraud than credit cards.

The process of making a payment is quite simple. The user opens an DotCoin™ Wallet program off the diskette sometime before he enters the "check out" section of an online store. Further, the user selects DotCoin™ among the accepted payment methods and presses one button on the Web form. Following that, he/she confirms the purchase with the DotCoin™ Wallet, which results in processing of the payment transaction. The transaction takes several seconds (it can be almost immediate if the user's Internet connection speed is high), after which the user obtains the purchase from the selling Web site.

X It is also possible to make payments from one DotCoin™ Wallet to another or from a Web site to an DotCoin™ Wallet. Thus, the system can provide a way of sending small amounts of money from one place to another, or it can be used to withdraw money from an Internet bank. A user can have and use one or more DotCoin™ Wallet diskettes at the same time. The information stored on the diskette and exchanged through the network is protected using modern strong data encryption technologies as well as additional unique methods of protection, developed by the inventor.

Local companies will distribute DotCoin™ Wallet diskettes in each region in exchange to local currency. DotCoin™ Wallets can be pre-packaged for fixed initial amounts of money and sold by retailers. Much like phone calling cards, pre-packaged DotCoin™ Wallet diskettes can be sold virtually everywhere, in any retail outlet, including convenience and drug stores, gasoline stations, supermarkets, etc. A DotCoin™ Wallet can be a great gift or incentive item. They can also be produced one by one for each customer for a requested amount of money - in this case, the selling company must have Internet connection and personal computer. A local Internet Service Provider (ISP) would be a suitable type of company to perform this type of DotCoin™ Wallet distribution.

DotCoin™ Wallet distributors will receive an incentive for each distributed Wallet, which will also provide them with a unique opportunity to be a part of rapidly growing Internet commerce.

As the user spends the money from one DotCoin™ Wallet, he can either purchase a new Wallet, or receive some money into the existing one from an online bank, where he has an account. He also can move any amount from one of his Wallets to another one (this provides for easy "consolidation" of funds from all user's Wallets into one). Commercial Web site owners will be provided with software that can be easily integrated into the site, so that accounting and authorization of DotCoin™ payment transactions is fully automated. They will also be provided with an account in the DotCoin™' s automated online administration system, which will help the Web site owners to analyze recent payment activity information, as well as customize parameters of interaction of their Web site with the DotCoin™ system. Most Web site owners practicing online commerce will find participation in the DotCoin™ system very attractive, because it will bring them a large number of new customers, which they wouldn't be able to reach otherwise. The following table attempts to analyze features and associated benefits of the system.

X3 Table 2.2-1. Features and Benefits of the DotCoin™ system.

At this point in time, all main components of DotCoin™ online payment system have been fully built and are now undergoing final testing for reliability and performance. The business model testing has been planned and will take place soon after the technical optimization is finished.

0.2 Competitors. The DotCoin™ service is targeted to a new market, where most of the existing online payment services have rather weak influence. A number of key features of the DotCoin™ system make it virtually inaccessible for direct competition by the existing systems.

However, this section attempts to analyze the possible sources of competition and their advantages and disadvantages, compared to DotCoin™. As mentioned before, DotCoin™ is a service provided to two categories of clients: commercial Web sites and their users. Therefore, there are two corresponding categories of competition sources: Alternative ways for customers to pay online - the choices available to Internet users when they need to make a payment to a Web site. Most sites offer one or two out of all payment methods. These methods are:

1. A direct payment with a credit card, when the customer provides the credit card number, name, address and other personal information directly to the selling site.

The selling site uses transaction-processing software (such as CyberCash) to charge the card and ships the merchandise to the customer. This requires the customer to have one of the major credit cards, such as Visa, MasterCard, and American Express. The advantage is that the customer uses a regular credit card and does not have to obtain anything else to make purchases online. The disadvantages are: customer's personal information is revealed to the seller; a good credit record is required to obtain a credit card; credit cards are available in a limited number of locations worldwide, and only to people with certain level of income or assets and a good credit history.

2. An indirect credit card payment, when the customer enters his credit card information into a third party Web site. Such Web site usually performs "online billing" services for a number of online stores or other types of commercial Web sites. However, from the user's point of view it is similar to a direct credit card payment and has the same advantages and disadvantages. We analyze this type of payment in more detail in the next section. Example of such third party service is Internet Billing Company (www.ibill.com). 3. A payment using a handle or password, which is also done through an intermediate third party Web site. The user first creates an account with that Web site, submits his credit card or bank account information and receives a password in the form of a string of characters. He can then repeatedly use the password to make online to any commercial Web site that supports this type of payment. The advantage is that the password is all a user has to carry with him - no credit cards, diskettes, cash, etc. Among disadvantages are at least two types of quite serious security risk: a password can be guessed - especially because inexperienced users tend to use easy-to-guess phrases; a "pirate" Web site can obtain the user's password by "faking" the look of the Web pages where the user usually enters his password. Another disadvantage - all existing systems of this type still require possession of a credit card or a bank account in an affiliated bank (in order to register), and are unusable where a credit card or a bank account cannot be obtained.

4. A payment using smartcard or special software. Smartcards or

PCMCIA cards are a recent technology achievement and are essentially pocket size plastic cards with a microprocessor inside. A card like that can be inserted into a special PCMCIA slot in a personal computer and interact with the main computer processor. A Netherlands company DigiCash (www.digicash.com) has suggested a technology of using a smartcard for electronic payments. The intended application of smartcard was similar to that of an DotCoin™ Wallet diskette - a user can carry it around and use to make online payments with a personal computer or special electronic device connected to the Internet. The system has been called eCash. Another variant of usage of the system was with a computer program instead of a smartcard. The program had to be pre-installed on the user's personal computer and could communicate with the bank the same way as a smartcard would. The advantages of the system are - it provides higher level of anonymity than all above-mentioned systems, and also a higher level of security. It may not require credit history verification and be interchangeable with local currency. However, it is known that eCash requires that a local bank in the customer's area would support the system. Another disadvantage is that while payments transactions have full anonymity, the customer is still required to reveal his personal information to the bank where he obtains the smartcard or eCash computer software, and have a personal account in that bank. Moreover, use of smartcards or eCash software has its drawbacks. For a smartcard to interact with a personal computer, the computer needs to have a PCMCIA interface and a pre-installed driver - while the PCMCIA interface is present in most laptops, today's desktop PCs are rarely manufactured with it. As to eCash software, as the online documentation indicates, it needs to be pre-installed by the bank on the customer's computer, which is inconvenient when the customer needs to use somebody's PC (or one in a public place). Due to these limitations, the system is currently known to be supported only by a few banks in Western Europe and possibly USA, and is not widely used.

5. A payment by calling a 900 number - some Web sites ask the customer to call a 900 number in order to pay for a purchase. The charge then appears on a regular phone bill. While some of commercial Web sites rent a 900 number by themselves, there exist third party payment services, which provide simplified and automated usage of 900 lines by commercial Web sites. Internet Billing Company (www.ibill.com) is an example of such service. Although paying for online services by calling a 900 number is easy, it is usually unavailable to users outside the US. For those users inside the US, it is usable only when they are browsing the Web from home.

From online shoppers' point of view, the DotCoin™ system will have a number of advantages over all of the above-mentioned systems, including its availability to everyone regardless of credit history, income level, age or location (given its proper

---.--> distribution), usability with any Internet-connected personal computer, ultimate ease of use, complete security and anonymity.

Alternative payment processing systems for Web site owners. Just like there are choices of payment methods for Web sites' customers, there are ones for Web sites' owners. Much of the list below will look similar to the one in the section above, but here the approach is to compare various online payment systems with DotCoin™ from the point of view of Web site owners, as opposed to their customers.

1. Credit card processing. Direct processing of credit cards requires the

Web site owner to use quite complicated software to connect the site with the automatic credit card processing network (to which all regular in-store POS terminals are connected). While the software itself is free - like the one provided by CyberCash - it requires experience and substantial amount of work to install, integrate and support the system. Additionally, direct credit card processing software is less available to Web site owners outside of the US due to export restrictions that US laws place on data encryption technologies, which are used in such software. However, there are currently many companies that specialize in handing these technical issues and providing Web site owners with easy integration of credit card processing into their Web sites. Besides technical complexity, direct credit card processing requires the site owner to have a credit card merchant account with a bank - the problem is that such a merchant account can be very hard to obtain for startup businesses, or ones with a certain profile. In such cases, third party credit card processing services are the only way for a Web site owner to be able to charge customers' credit cards online. For Web site owners who do not have their own merchant account, an average third party's fee is 15% of the transaction amount. Credit card payments today cover probably 90% of Internet commerce, and being able to accept them is crucial for any Web-based business, in order to attract most of online buyers. However, current statistics show that only one-third of all Internet users make online purchases. This can be very well attributed to the fact that the rest two-third of users (67.9 millions, as of 1998 year's end) simply do not have access to any of existing online payment methods - credit cards, bank accounts in Internet-enabled banks or 900 numbers. From the point of view of Web-based business owners, the DotCoin™ online payment system will provide them a way to reach the part of Internet public, to which they had no access through accepting credit cards. Besides, as opposed to credit card processing software, the DotCoin™ system will be easy-to-integrate into their site, with the price per transaction lower than that of a third-party credit card processor, as well as the same or faster processing speed. 2. Bank account transfers. This is usually handled by third party online payment processing companies, offering their services to Web site owners. Often, the same company would offer both credit card and bank account processing. The customer is, however, required to have an account in a bank that has a special support for online services. Example of such service is CyberCoin, offered by the CyberCash company

(www.cybercash.com). Since availability of banks which support this or other such systems is limited, so is the interest of Web site owners to use it, especially because it covers mostly the same segment of the Internet buyers market as is already covered by credit cards. The requirement that the system be supported by a local bank is the main factor that slows down its distribution in the World, and this situation is not likely to change in any near future.

3. 900 numbers. It is usually fairly expensive for a single business to rent its own 900 line and integrate it into its Web site, for charging buyers online. Therefore, most Web-based businesses use third party services, which provide shared usage of the 900 lines for several businesses, as well as easy integration of this billing solution into a Web site. Example: WEB900 service, provided by Internet Billing Company (www.ibill.com). While 900 numbers are a way for Web-based businesses to reach certain categories of buyers, they have a few disadvantages. As mentioned before, such services are usually available only to Web sites and their users inside the US. The cost is also high: third party companies like IBill charge Web site owners as much as 20% per transaction. For both 900 number and bank account services the main problem remains the same: limited availability to worldwide buyers.

0.2.1 Target clients. The target end-clients for the DotCoin™ services are the Internet users of the World who do not have convenient access to credit cards, bank accounts in Internet-enabled banks and/or 900 number calling. These client categories are listed below. 1. Most Internet users in developing countries, such as Mexico, Brazil,

Indonesia, China, Russia, etc. where bank infrastructure or credit card services haven't developed yet to support Internet standards and be available to everyone. According to a number of statistical sources reproduced online by www.headcount.com, the current population of Internet users in these countries is 11.9 millions, which is about 12% of worldwide population. Of those users, only approximately every 10th person makes purchases online, compared to every 3rd person worldwide, mainly because of unavailability of online payment methods to people in developing countries.

2. Internet users in well-developed countries, who cannot obtain a credit card or a bank account: most children and teenagers under 18, recent or illegal immigrants, n people with bad or insufficient credit history. It is estimated by IDC Research that in 1998, teenagers of the age 12 to 17 constituted as much as 40% of all home Internet users in the US, which is more than a quarter of the total Internet population of the United States.

3. Internet users anywhere, who do not wish to reveal their personal information when making purchases online. Among them there are most of celebrities, people from societies with strict cultural or religious rules, as well as anyone concerned about privacy of online transactions.

All these end-users will have access to the DotCoin™ payment system through the use of DotCoin™ Wallets. It is intended to use two main ways to distribute DotCoin™ Wallets:

1. Through local Internet Service Provider (ISP) companies. End-users will be able to purchase DotCoin™ Wallets at the office of a local ISP, where the Wallet program will be downloaded by the ISP staff from the DotCoin™ Web site and recorded onto a diskette. The amount of money the user paid to ISP, less applicable fees, will be stored in the Wallet and will be available for online purchases from any participating Web site. Generally, any company with an Internet-connected personal computer can be a Wallet distributor. However, local ISP is the most suitable type of a distributing company: its staff possesses enough technical experience, it has usually a higher speed of Internet connection and quality of computer hardware, and is located in the middle of areas with high density of Internet users.

2. Another way of distribution is retail. DotCoin™ Wallets will be available in stores, kiosks or even by a mail order, much like phone calling cards. DotCoin™ Wallet diskettes will be pre-recorded for fixed amounts of money and packaged in a special wrap. The manufacturing of diskettes will take place inside each country to avoid paying import duties in case of international distribution scheme.

Each diskette will be sold to the end-user for its nominal value, plus up to 8% of it (plus an applicable local sales tax). In both methods of distribution, distributor's incentive will be 10% of the nominal value. ISPs will be allowed to charge additional flat fee per diskette, for example, $0.50. It is expected to be an acceptable profit margin for distributing companies, because their costs of such distribution will be insignificant. It is not intended to use intermediate distribution channels and will be establishing direct relationships with local end-user distributors.

1. Purpose and functional principle of the system.

*9 1.1 Purpose. The purpose of the system "DotCoin™" is to perform money transfer via Internet between Web sites and Internet users. DotCoin™ helps Internet users to pay for goods and services that they buy from Web sites, as well as to receive payments from Web sites or to transfer money between themselves and other Internet users. 1.2 Users of the system. The DotCoin™ system serves as a mediator between Web sites and their clients. Therefore, both Web sites and their clients are considered to be users of the DotCoin™ system.

1.3 DotCoin™ Wallet. A Web site's client (further referred to as "buyer" or "client") uses a special software program for conducting any money transfer operation with a Web site. Copies of the program are distributed on standard 3.5-inch diskettes and are referred to as "Wallet-diskette", "Wallet-program" or just "Wallet" throughout the document. Each copy of the Wallet-program carries unique set of data that allows determining current amount of money in the Wallet. Money that can be kept in such a Wallet are always accounted in U.S. dollars, regardless of the country where the Wallet is being used. Initially, each Wallet-diskette is pre-recorded a fixed amount of money, similar to dollar bills: for example, there can be Wallet-diskettes of $5, $10, $20, $50 or $100 value, etc. Additionally, custom amounts can be "recorded" on a Wallet-diskette at the time the diskette is being manufactured and sold individually to a customer by a DotCoin™ Wallet distributor. In the process of using a Wallet (paying or receiving funds), the amount of money in it changes accordingly.

1.4. The payment process from DotCoin™ Wallet to Web site. This chapter describes the process of transferring money from a buyer to a Web site ("seller-site" further in the document). The process is considered from the point of view of actions that need to be taken by the buyer and the seller-site. 1.4.1. Launching of the payment transaction by the buyer. First, the buyer browses a Web site to select goods and/or services that he wishes to buy. This part of the online shopping process completely depends on organization of each particular site and is not discussed in this document). Having selected a list of goods, the buyer is also likely to have to choose among several methods of payment that this site accepts, such as credit cards, personal checks, etc., as well as the DotCoin™ payment method. We assume that the buyer chooses the DotCoin™ payment method.

Further, the buyer enters a page of the Web site devoted to DotCoin™ payments. Here the buyer sees a list of goods he/she selected, total amount due and instructions to insert a DotCoin™ Wallet diskette and start the Wallet program from it. The

So program shows up on the screen as a separate window, in which the buyer enters the following data, according to the instructions provided on the Web site's page: Payee ID - a word consisting of letters, numbers and/or symbols that uniquely identifies the site and the set of goods in it that the user selected to buy; and amount of payment. 1.4.2. Transaction confirmation. Further, the buyer presses the "PAY" button in the Wallet program window. In a few seconds, the Wallet program displays a transaction confirmation number ("receipt" No.). This is a unique number that identifies the payment transaction accomplished on request of the buyer. It is equivalent to a purchase receipt issued by a cash register in a regular store in that it confirms that the person, who possesses the receipt, has paid in full and is eligible to receive the merchandise.

1.4.3. Claiming purchased goods with transaction No. Following the instructions of the Web site, the buyer enters the transaction confirmation code into a form on the Web page and submits that form. This results in the transaction code being sent to the Web site where it is then verified, and the Web site releases and delivers the goods and/or services purchased by the buyer. The process of delivering the merchandise fully depends on its nature and on organization of each Web site, and is outside of the scope of this document.

1.4.4. Automatic data entry mode. The DotCoin™ Wallet program can also function in automatic data entry mode, where payment information that would otherwise be manually entered by the buyer is instead automatically sent to the Wallet from the Web browser, and the receipt (i.e. transaction) code is then received back. In this mode, the user only has to press two buttons: one on the Web form, in order to initiate the payment, and another one - in the Wallet window, to confirm payment information.

1.5. Receiving money into a DotCoin™ Wallet. This process is referred to as "crediting" transaction further in the document. Crediting transaction is a process where the Web site comes as the paying party, and its client - as the receiving party. It is opposite to the payment transaction by effect and flow.

1.5.1. Launching of the crediting transaction by the client. Regardless of the fact that the client and the Web site change roles, crediting transactions, like payment transactions, are also initiated by Web site clients. Technical and logical reasons are that both transferring to and from a DotCoin™ Wallet are services that the Web site performs on request of the client, and only when the client so desires.

In order to receive money from the Web site, the client enters a section of the Web site devoted to crediting money to DotCoin™ Wallets. It is assumed that prior to that, the client has already selected a service that includes crediting money to his Wallet and has

3/ identified himself to the Web site, if such identification is necessary (for example, in case the Web site is an Internet bank where the client keeps his checking account and where he came to withdraw some amount into his DotCoin™ Wallet). It is also assumed that by the time the client enters the DotCoin™ crediting page of the Web site, he/she and the site have negotiated the amount of money to be credited to the Wallet.

The page of the Web site devoted to DotCoin™ crediting transactions instructs the client to enter the identifier of the Wallet-diskette into the Web form and then submit it. Wallet identifier is a number printed on the diskette's label and also displayed in the Wallet program's window. The client is not required to launch the DotCoin™ Wallet program for this type of transaction.

1.5.2. Crediting of funds into the Wallet by the seller-site. Submission of the Wallet's identifier into the Web form is the only action the client is asked to perform. The rest of the transaction is performed by the seller-site. In particular, with help of a software program that is functionally analogous to the DotCoin™ Wallet, the Web site performs a "payment" to the client's Wallet using the Wallet identifier that the client has submitted. The site then receives a transaction code confirming its payment. This number is then displayed to the user as a confirmation of the crediting transaction.

1.6. Money transfers between two DotCoin™ Wallets. It is also possible to send money from one DotCoin™ Wallet to another. The process of payment from a DotCoin™ Wallet to another DotCoin™ Wallet is the same as described in 1.4.1, except that the Payee ID is the identifier of the other DotCoin™ Wallet to which funds are being sent. Therefore, the owner of the receiving Wallet must tell his/her Wallet's identifier to the owner of the sending Wallet. After transaction is performed, both Wallets' balances will increase and decrease respectively. 1.7. The DotCoin™ Payserver and its role in the system. The DotCoin™

Payserver is the third party that stands between the payee and the payer in each DotCoin™ transaction and actually performs it. The Payserver is a computer server system, independent on any seller-site, to which DotCoin™ Wallets and seller-sites connect via Internet. During each transaction the Payserver receives data from the paying party and, at that party's request, transfers funds from the paying party's account to another account. All data about accounts is kept in a database. Each account is associated either with a DotCoin™ Wallet or with a seller-site (or a particular set of goods/services in the seller-site).

1.8. DotCoin™ provider network. The DotCoin™ Provider Network serves as an agent between the parties in a payment transaction. It consists of a number of mutually interconnected DotCoin™ Payservers operating at sites of various DotCoin™ Transaction Processing Providers (TPP), that have licensed the use of the technology, the software and the hardware from DotCoin™. Typically, a TPP is a bank, an ISP or a tele- or data communications carrier company, since these are the types of companies most experienced in maintaining highly available and secure computer-based services in 24/7 mode of operation. Each Payserver, owned by a TPP, can be used to manufacture DotCoin™ Wallets (and/or in-site Wallet components) and process payment transactions initiated by these Wallets. The fees charged per each transaction are shared by a pair of TPPs in case the Wallet originating the payment and the Wallet receiving the payment belong to two different TPPs.

1.9. The account tracking and administration system. The DotCoin™ system will have its own Web site (www.DotCoin.com) which will serve the following purposes:

1. Provide overview of the system and its use, along with sample DotCoin™ Wallet program;

2. Provide a directory of Web sites accepting DotCoin™ payment and a directory of DotCoin™ Wallet distributors;

3. Provide instructions and demonstrations to Web site administrators on how to set up their site so that it is able to accept payments from DotCoin™ Wallet users. 4. In a password-protected area, provide Web site administrators with account configuration and revenue tracking Web application that keeps track of each transaction for an DotCoin™ account, as well as allows to set up and modify parameters of interaction between DotCoin™ Payserver and the seller-site's CGI programs.

5. In a password-protected area, provide DotCoin™ Wallet users with a payment tracking Web application that allows one to display a history of recent transactions for a particular Wallet;

6. In a password-protected area, provide DotCoin™ Wallet distributors with an application that allows "manufacturing" a new DotCoin™ Wallet off the Web site in order to sell it to a potential user. Through the same application, provide Wallet distributors with ability to track their sales.

2. Analysis of requirements and features.

Currently, there exists a number of methods/systems of online payment. The following requirements are dictated by the experience acquired in using of these existing systems, as well as the necessity for the DotCoin™ online payment system to provide highly competitive payment services that eliminate some of the drawbacks of the existing methods. 2.1 Ease of use. The system must be easy to use for online buyers, as well as to be easy to integrate into a Web site that wants to accept DotCoin™ payments. This requirement is satisfied, if:

1. The DotCoin™ Wallet program has an easy-to-use user interface and does not require the user to enter a lot of data manually when launching a payment transaction.

2. The DotCoin™ Wallet program is compact, is stored on a single diskette and can be launched directly from the diskette without the necessity to install or copy the program to a hard disk. Compactness of the program code also simplifies its downloading from the Internet for ease of version upgrades and electronic distribution.

3. The application program interface between the Payserver and the seller-site must be simple and comprehensive, targeted for entry-level of experience of Web site developers who will be integrating DotCoin™ payment method into their Web sites.

There must be precise instructions and sample CGI programs and HTML pages provided for downloading from the DotCoin™ Web site.

4. All the complexities of the system must be encapsulated inside the Payserver and the DotCoin™ Wallet software. 2.2 High availability. The key point of popularity of the DotCoin™ system is its high availability to the general public of Internet users in all countries of the world.

This requirement is satisfied, if:

1. The Wallet program is distributed on a universally used, portable and physically compact electronic storage of most popular type, which is currently the standard

3.5" floppy diskette. It's main distinction from a credit card or any other "pocket-type" money equivalent is that there is a 3.5" floppy diskette drive in almost every personal computer and hence such a diskette is most suitable as DotCoin™ Wallet program's storage.

2. There must be a large number of commercial Web sites that accept DotCoin™ as a means of online payment. The potential number of Web sites who would be willing to join the DotCoin™ network depends on how robust, fast and reliable is the system, how much extra buyers it will bring to the Web site and how simple is integration of DotCoin™ payment software into the Web site.

3 2.3 Anonymity. All payments through the DotCoin™ system must be completely anonymous and do not involve personal information of the payer. This is the key competitive advantage over all of the existing online payment methods.

This requirement is satisfied, if: 1. The buyer has to tell his personal information neither at the time he/she purchases the DotCoin™ diskette, nor when making payments from it.

2. The seller-site owner does have to tell his personal data neither when registering with the DotCoin™ Web site, nor when his/her site accepts or makes payments through the DotCoin™ system. 3. Note that the DotCoin™ system is built such that personal information is not known or stored anywhere in the DotCoin™ databases thus guaranteeing absolute anonymity of users, as opposed to any other system where such information would be stored, but its owners would "promise" the users not to release it.

2.4 Reliability and security. DotCoin™ is a system of financial transactions, and as such, it must:

1. Ensure safety and integrity of all user account data at all times.

2. The DotCoin™ Payserver must be "highly available", i.e. be ready to process any number of transactions and stay functional 99.99% of time, as well as to be able to sustain heavy work load at periods of peak usage. 3. Be able to self-restore from software, network and hardware failures and outages.

4. Provide adequate protection from unauthorized access and counterfeit.

5. Be free of software errors.

This is provided by using redundant clustered server architecture with load balancing and self-monitoring, as well as redundant data storage, network connection and power supply. Data protection is provided by use of industry-standard public key encryption algorithms in communication (SSL), as well as in data storage, password-protected access to the DotCoin™ Wallet program and parts of the DotCoin™ Web site.

2.5 Fast service. The speed of payment transactions must be comparable to the common "speed of Internet" from the point of view of the DotCoin™ Wallet user. I.e. the time between pressing of the "PAY" button to launch a payment transaction and receiving the transaction code must be not more than a few seconds.

To satisfy this requirement, the DotCoin™ Payserver must be implemented on fast and high-capacity hardware, as well as be connected through a fast network line, such as

3$ Tl or T3. All software components must be designed and optimized on high performance and speed of communication.

3. Architecture details.

3.1 Interaction of components. The following diagram (Figure 10A) demonstrates interoperation of DotCoin™ components during a payment transaction from a DotCoin™ Wallet to a seller-site and from a seller-site to a DotCoin™ Wallet.

The three major components are shown on the diagram above(Figure 10A). Wallet is the standalone application on a 3.5" diskette that the user must be running on his computer in order to be able to make payments (the Wallet does not have to be running in order for user to receive payments). An application similar to the Wallet is also present as a part of the Seller-site. As shown on diagrams below, the user initiates both payment and crediting transactions, however, the Payserver is contacted first by the Wallet of party that wishes to pay.

As described later in more detail, the DotCoin™ Wallet is implemented as an HTTP client, communicating to the Payserver via SSL. The Payserver is implemented with HTTP server as a front-end that accepts connections from DotCoin™ Wallets and routes them to back-end transaction processing software. The Wallet component in the seller-site is implemented as a set of CGI/IS API scripts that are invoked by the Payserver via SSL- encrypted HTTP. The diagram above (Figure 10B) represents interaction of components in a payment transaction between two DotCoin™ Wallets. The Wallets can be possessed by different users, in which case such a transaction is, in essence, a money transfer between these users, and can be helpful in any situation where there is a need for payment or funds transfer from one individual to another (as opposed to a payment from an individual to a seller Web site). Alternatively, these DotCoin™ Wallets can be possessed by the same user, who can use this type of transaction in order to consolidate funds from several of his Wallets into a single one.

3.2 Public and private account keys (creditlD and debitlD). As mentioned above, both the Wallet and the seller-site must present a unique identifier to the Payserver at the time of transaction. This identifier is the key to their account in the Payserver' s database, regardless if it's a Web site or an individual Wallet.

Actually, each account has a pair of identifiers, both uniquely identifying the account in the database. However, there is no way to find out one identifier using the other. One of the two identifiers is used in all account-debiting operations where money is withdrawn from the account, and the other one is only used in debiting operations, where money is deposited on the account. They are called debitlD and creditlD, respectively. The payment transaction from a DotCoin™ Wallet to a seller-site requires the debitlD of the Wallet and the creditlD of the site. And vice versa: the payment transaction from a Web site to a DotCoin™ Wallet requires that site's debitlD and the Wallet's creditlD. There is no way to withdraw money from an account using a creditlD. There is also no way to deposit money on an account using a debitlD.

Thus, of the two account IDs, the most sensitive one is the debitlD. For security reasons, all transactions require sending any debitlD in encrypted form only, while a creditlD does not have to be encrypted and can be used publicly.

3.3 DotCoin™ Wallet authentication. Special attention needs to be given to the way the Wallet (as well as in-site Wallet component) authenticates to the Payserver. The authentication consists of several types of data: 1. Constant account credentials: user's password, account debitlD;

2. Per-transaction account credentials: last transactionlD;

3. SSL-level authentication data: SSL client certificate.

As an additional measure of security, the following means are used for protection of sensitive data stored on the Wallet diskette: 1. The debit accountlD is stored by the Wallet in encrypted form that's produced by a full strength cryptographic algorithm (such as triple-DES with 168 bit key); 2. Optionally, the Wallet application does not use the standard way to access the files on the diskette, but rather it uses low-level access to disk clusters to establish its own (encrypted) formatting of the disk. When the Wallet is issued from the DotCoin™ system, it is assigned a pair of debit and credit accountlDs and an SSL client certificate - these are permanent credentials that exist throughout the life of this Wallet. The third credential that is sent by the Wallet along with the first two with all types of requests to the Payserver is the transactionlD (i.e. receipt code) of the last successful payment transaction, in which this Wallet was the payer. This authentication scheme has the following features:

1. Access to the Wallet is protected with a user password: if a Wallet is physically stolen, lost or copied, it is useless without a password for a person who finds, steals or copies it. 2. Debit accountlD is kept encrypted: in an unlikely event of a pirate attack on the Payserver, the intruders won't know the accountlD of their Wallet hence will not be able to access that account's data.

3. Wallet sends an SSL client certificate: Payserver will only establish SSL connections with an application that identifies itself as a DotCoin™ Wallet by presenting the client certificate that was issued by the Payserver at this Wallet's creation time.

4. Wallet sends the last transactionlD: only one copy of the Wallet program is usable at any given time - the one that can present the correct last transactionlD to the Payserver.

5. Wallet stores all data in non-standard, encrypted disk format: this makes it difficult to duplicate the files stored on the disk using most standard file-copying means.

3.4 DotCoin™ Wallet payment transaction algorithm and API. 3.4.1 Data exchange between DotCoin™ Wallet and Payserver. To perform the payment transaction, the Wallet establishes connection to the Payserver via TCP/IP using Secure Socket Layer (SSL) to encrypt and sign all transferred data using a standard public key encryption scheme, as well as to authenticate the paying Wallet and the Payserver to each other using digital certificates. Additionally, the transaction ID is used in authentication as a seed data element that changes between transactions, so that next transaction can only be accomplished if the result of previous transaction is known to the Wallet application.

The Wallet needs to exchange data with the Payserver in three cases: a. At the Wallet program start-up, in order to find out the current balance on the Wallet's account, which is then displayed to the user. b. When the "PAY" button is pressed by the user requesting a payment transaction. c. When the user wishes to change Wallet password.

In case (a), the scenario of data exchange with Payserver is the following:

1. Handshaking and authentication of parties in the SSL layer; 2. The Wallet sends its debitlD, last transactionlD and user's password;

3. The Payserver sends back the current balance in the Wallet.

(Current balance is a sensitive information, and its retrieval requires the Wallet to provide the private key - debitlD)

Payserver interface:

3«

(Here and further in the document: All CGI function parameters are sent only via POST HTTP request; and the data format for all output parameters is "field_name:value")

In case (b), communication begins when the user presses "PAY" in the GUI window, which results in the following scenario: 1. SSL-layer handshaking and authentication;

2. Wallet sends its debitlD, the creditlD of the seller-site, the amount of payment, password and the last transactionlD (creditlD is entered into the GUI window by the user);

3. Having received the data, the Payserver performs the transaction itself and sends the new transactionlD to the seller-site (by invoking in-site Wallet CGI interface described in 3.4.2.), as well as to the user's Wallet;

4. Wallet GUI displays and saves the new transactionlD. Payserver interface:

Note that in both cases the connection is initiated by the Wallet. 3.4.2 Data exchange between Payserver and seller-site. Having received the payment request from the Wallet, the Payserver does the following:

1. performs database update that reflects the balance transfer between account and registers this action under a new transactionlD;

2. initiates connection with Wallet component in the seller-site via HTTP-SSL and sends to it the new transactionlD. This is done by invoking a well-known

URI on the seller site and sending a POST request to it;

3. receives a return code of the CGI script, showing whether the transactionlD is accepted and saved by the seller-site successfully (in case of an error return, the payment transaction must be canceled by the Payserver); 4. exchan ^goe^s data with the user's Wallet as defined in 3.4.1.

3? Seller-site interface:

(Angle brackets around URI denote that the real URI is the choice of the site's administrator.)

3.5 Algorithm and API of DotCoin™ Crediting transaction, site to Wallet. The DotCoin™ Wallet program is not used during the crediting transaction from seller-site to such a Wallet.

The algorithm is as follows: a. As mentioned in 1.5.1., the user enters his/her Wallet creditlD in an HTML form in the seller-site and presses a button to submit it. The same form can contain site- and/or merchandise-specific form fields (as "hidden" ones). One such parameter is required: site's creditlD. b. Submission of the form by the user sends a POST request to the Payserver to initiate the crediting transaction. c. The Payserver initiates an HTTP-SSL request back to the seller-site, invoking a URI that accepts site's creditlD and a password and/or SSL-level client certificate.

The seller-site returns its debitlD, amount of payment, and the last transactionlD. The URI, the password and the client certificate are stored in the Payserver's database and retrieved by creditlD of the seller-site. d. The Payserver validates the data received from the seller-site and commits the transaction in the database by changing balances of the corresponding two accounts (the site's and the Wallet's). The new transaction is then registered in the database under a new transactionlD. e. The Payserver calls another URI of the in-site Wallet component via HTTP-SSL. This URI is also stored in the Payserver's database and is retrieved by the site's debitlD. Using the URI, the Payserver sends the new transactionlD to the seller-site and receives an error code indicating whether the site has successfully received the new transactionlD. In case of an error, the Payserver cancels the payment transaction.

-o f. The processing of payMoneyFromSite.cgi request finishes and redirects client's Web browser to a new URI that was passed as a parameter.

The following are interfaces of the Payserver and the seller-site: Payserver interface (see (b)):

3.6. Helper-applet component. In the case of a DotCoin™ Wallet - to - Web site payment, an additional component can be used by Web sites to make the payment process easier for the user. In essence, this component automates the job of entering payeelD and payment amount into the Wallet window, as well as copying or typing the resulting transaction ID back into the Web browser's window. With this component, the whole payment process consists of pressing just two buttons - the "PAY" button and the confirmation button, and does not require any typing from the user.

The component is a combination of a Java applet and a JavaScript code, which are embedded in the HTML page of the seller Web site that handles DotCoin™ payments. The applet uses parameters of payment (site creditlD/merchandiselD, amount of payment) that are supplied to it by the JavaScript calling code, which in turn receives them as a part of the HTML code produced by the server-side script.

As mentioned earlier, the user interacts with the applet by simply pressing a "PAY" button on the Web page. This makes the applet connect to the user's DotCoin™ Wallet (the Wallet program must already be running), and requests a payment transaction. The Wallet requests user's confirmation in the form of a "Yes/No" dialog box, and if user agrees, it automatically initiates a payment transaction with the Payserver via a secure connection (see 1.4 and 3.4.1) and receives a transaction receipt ID, which it then passes back to the applet. The applet returns the transaction ID to the JavaScript code that automatically HTTP-POSTs this transaction ID to the seller-site, where it is then verified by the server-side script that enables delivery of the merchandise to the user.

¥1 The following diagram illustrates the above description (Figure 6). 3.7 Multi-Payserver architecture. The following diagram (Figure 8) represents the main aspects of the multi-homed Payserver architecture, where WalletA and WalletB possibly belong to different Payservers (PS-Y and PS-Z). The network of Payservers is dynamic and is capable of relocating existing domains of Wallet accounts from one Payserver to another without interrupting the service, as well as in-service insertion and removal of Payservers. The same physical Payserver host is capable of hosting a number of Wallet Account Domains (WAD). The information about current location of each WAD is kept by the Payserver Routing engine, a part of each Payserver responsible for routing Wallets' and other Payservers' requests. At first, the Wallet requesting a payment transaction is dynamically routed to the Payserver that is hosting the domain of accounts where this Wallet belong to. This Payserver will take care of the actual payment transaction. In case the receiving party's Wallet also belongs to the same domain, or a different domain but hosted by the same Payserver, the entire transaction is done by that Payserver. Otherwise, the host of the receiving party's Wallet is contacted to confirm and finish the crediting part of the transaction.

tf9-

Claims

WHAT IS CLAIMED IS: L A method for conducting financial transactions comprising: providing a payserver coupled to a network; providing a wallet comprising a program code executable using a computing device, and data on a tangible medium; and making a financial transaction using the wallet by executing the code on a payer computing device to provide a payer identifier and a purchase amount to the payserver.

2. The method of claim 1 where computing device is coupled to the network, and the network is the Internet.

3. The method of claim 2 wherein the program code comprises encryption software executed on the computing device to encrypt information sent to the payserver, and decrypt information received from the payserver.

4. The method of claim 2 wherein the payer identifier and purchase amounts are entered by a payer using the computing device.

5. The method of claim 4 wherein the payer has a name, and the name is not stored in the payserver or the wallet.

6. The method of claim 2 wherein the payer identifier and purchase amounts are entered by the program code.

7. A system for financial transactions comprising: a first payserver coupled to a network, wherein the payserver receives instructions through the network, and when the payserver receives a transfer instruction, the payserver effects transfer of funds from a first account having a first account number and accompanying first account fund balance, to a second account having a second account number and accompanying second account fund balance, and wherein the first payserver comprises: a first account database comprising account numbers and accompanying account fund balances; a first router database comprising a first payserver network location identification for the first account and a second payserver network location identification for the second account; and a first transaction database to store transactions handled by the first payserver.

8. The system of claim 7 wherein the first payserver further comprises payment processing software.

9. The system of claim 8 wherein the first payserver network location is on the first payserver, and the second payserver network location is on the first payserver.

10. The system of claim 9 wherein the payment processing software is used to debit the first account fund balance.

11. The system of claim 8 wherein the first payserver network location is on the first payserver, and the second payserver network location is on a second payserver coupled to the network, and the second payserver comprises: a second account database comprising account numbers and accompanying account fund balances; a second router database comprising the first payserver network location identification for the first account and the second payserver network location identification for the second account; and a second transaction database to store transactions handled by the second payserver.

12. The system of claim 11 further comprising a computing device coupled to the network, and wherein the transfer instruction is received from the computing device under direction of a user.

13. The system of claim 12 wherein the network is the Internet.

14. The system of claim 12 wherein the first payserver and the second payserver are coupled over the Internet in such a way as to appear as one payserver to the user.

15. The system of claim 8 wherein the account numbers identify a wallet apparatus comprising: an executable code portion stored on a tangible medium; and a data portion stored on the tangible medium.

16. The system of claim 11 wherein the wallet apparatus is owned by an individual having a name and an address, and the account data base excludes the name and the address.

17. An apparatus for conducting financial transactions comprising: a tangible transportable medium which is readable using a first computing device; a programmable code portion stored on the tangible medium; and a data portion stored on the tangible medium, wherein the programmable code portion comprises an executable program, and the data portion comprises a first security identifier for credit transactions, and a second security identifier for debit transactions.

18. The method of claim 17 wherein the executable code comprises encryption software which executes on the computing device to encrypt information entered by a user on the first computing device.

19. The method of claim 17 wherein the data further comprises a last transaction identification, wherein the last transaction identification identifies the last financial transaction conducted with the tangible medium.

20. The method of claim 19 further comprising a second computing device having an account database for storing account information for a plurality of accounts, wherein the first identifier and second identifier identify one of the plurality of accounts.

21. The method of claim 20 wherein the first computing device and the second computing device are coupled together over the internet.

S