Broker JSPs
register
<>
BrokerAppServer
mairtain Customer
maintain Vendor
*maintain Ecoin
buy.coins/rede em coins
maintain Trsanction History O
transfer Ewallet
Mocate Ewallet
getEwallet Location (Global)
CORBA
Customer Broswer
Vendor 1 JSPS
<>
goto UMLO
searcho
broswer Site Mogin display Content
Vendor1 App Server
<
CORBA
Vendor 2 JSPs
Bank macro Payment
Ecoin Info
*insert Ecoin find Ecoin delete Ecoin
get Ewallet Location get Ewallet pay For Content() verity E coinsQ
get let redeems pending()
Ewallet PecoinID: String touchstone: String “index:int pay words: String
Vhedor2 App Server
Fig. 4. An overview of the Net Pay server-side e-wallet design.
When a customer first clicks the Login&Buy button to purchase e-coins on the browser, JSPs running on the web server handle the request. The Broker application server communicates with macro-payment system to debit money from the customer bank account and then sends the e-coins to the customer’s e-wallet on the customer machine.
A JSP page deals with displaying content when the customer clicks on the title of an article. The vendor application server connects with the e-wallet application and sends the price of the article. The customer’s e-wallet returns with the e-coins and the location of the T&I to the vendor application server. The vendor application server communicates with the broker or previous vendor via CORBA to obtain the T&I, which are used to verify the e-coins. The main client-side Net Pay e-wallet design features are illustrated in Fig. 5.
The cookie-based E-wallet design is an extension to the client-side e-wallet design that uses browser-based cookies as a temporary cache. When the Vendor application server first communicates with the client PC-hosted e-wallet application, it reads the e- coins from the e-wallet and stores them in a browser cookie. The e-wallet updates its database to indicate the e-coins are now cached by the local browser in a cookie file for the vendor. Each subsequent pay-per-click from the same vendor has one or more e-coins from the cookie removed and stored in the vendor’s redemption database. If
Customer Brosur
go to UMLO getallet
Ballet
Pecon ID: String
paywords: String
host: String
port: String
BrokerJSPs
register *logiro *buyEcoin
update Account
Broke App Server
maintain Customer maintain/endo
maintain Transaction History O send Ewalet
buy core/redeem coins
get Touch store &inde
Bark
Vendor1JSPs
*macroPayment
CORBA
searchO *browerSiteO *logro
displayContent
<us##
Vendor 1AppServer
*sendPrice
receiveEcoine
getT
verifyEcoins
Vendor2JSPs
redeem@pending
getTouchstonesande
CORBA
Vnedor2AppServer
Fig. 5. An overview of the NetPay client-side e-wallet design.
the customer moves to another vendor, the first new vendor access to the e-wallet application causes an update of the e-wallet e-coins from the cached cookie file from the previous vendor. This cookie file is then deleted by the client PC-hosted e-wallet.
6 Example Usage
We briefly illustrate the usage of our E-wallet prototypes for a simple E-newspaper system enhanced with NetPay. Fig. 6 shows an example of NetPay in use for this prototype E-newspaper application. The customer first buys e-coins from a broker (1- 2), and these are stored in a client-side E-wallet (3) or requested by a vendor on customer login.
The customer visits a NetPay-enhanced vendor site
(4), and if using a server-side E-wallet logs in providing an E-wallet ID and password generated by the broker. The customer accesses articles on the E-newspaper site, each time their E-wallet being debited
(5). The server-side E-wallet held by the vendor site server is debited and the remaining credit displayed to the user after each article is presented, as shown in (5). The client-side E-wallet is held by an application resident on the customer PC, and its balance can be accessed when desired or displayed periodically, as shown in
(3). The contacts the previous vendor to get the e-coin touchstone and “spent coin” index and then debits coins for further news articles.
When the previous vendor system is “down”, a backup server in the system sends the e-coin ID, the touchstone, and the index to the broker. The new vendor could also contact the broker to get the e-coin touchstone and the “spent e-coin” index. At the end of each day, the vendors all send the spent e-coins to the broker, redeeming them for real money (done by macro-payment bank transfer from the broker to vendor accounts).
4 NetPay E-wallets
We have designed three kinds of e-wallets to manage e-coins in the NetPay system. One is hosted by vendor servers and is passed from vendor to vendor as the customer moves from one site to another. The second is a client-side application resident on the client’s PC. The third is a hybrid that caches E-coins in a web browser cookie for debiting as the customer spends at a site.
4.1 Server-Side E-wallet
Some people prefer to access the Internet from multiple computers (e.g. a business person who often travels around). A Server-side hosted e-wallet is suitable for these people. The server-side e-wallet is stored on the vendor server and is transferred from the broker to each vendor when required.
Fig. 1 shows how a vendor application server debits e-coins from the server-side e-wallet. When a customer clicks title of an article on his/her browser
(1), the web server sends the request to the vendor application server
(2), which then debits e- coins from the customer’s e-wallet
(3) paying for the content. Customers can buy articles using the server-side e-wallet anywhere in the world and the e-coin debiting time is very fast on the server-side e-wallet system.
However customers are required to remember e-coin IDs and password in order to log into a newspaper site when changing vendor. When a customer moves from one vendor to another, their e-wallet contents must be passed from the previous vendor site to the new one. If the first vendor site becomes unavailable, the customer temporarily does not have access to their e-wallet.
4.2 Client-Side E-wallet
Some people prefer to access the Internet using one machine (e.g. those who stay home most of the time or access sites from their work PC only). A Client-side e- wallet is more suitable for these kinds of people. The client-side e-wallet is an application running on the client PC that holds e-coin information.
5 NetPay E-wallet Design
In our current NetPay prototype we have implemented two kinds of e-wallet, a server- side e-wallet and a client-side e-wallet. The broker application sets the e-wallet that stores the e-coins in the server-side or client-side.
5.1 Server-Side E-wallet NetPay Design
The server-side e-wallet should be transferred from the broker to each vendor in turn that the customer is buying content from. Vendor systems need to know the location of the customer’s e-wallet and to get the e-wallet contents.
To do this we designed the broker application server so that it provides a set of CORBA interfaces with which the vendor application servers communicate to request an e-wallet location or to get an e- wallet. The vendor application servers also provide a CORBA interface in order for another vendor application server to get the e-wallet if it has been passed to one of them.
The e-wallet is thus passed from vendor to vendor as needed. The major problem with this approach is that the new vendor cannot get the e-wallet when the previous vendor crashes or becomes unavailable.
When a customer first clicks the Login&Buy button to purchase e-coins on the browser, the HTTP server runs JSPs handling the request. The Broker application server communicates with a macro-payment system to debit money from the cus- tomer bank account and stores the e-coins information in the database.
When the customer goes to a vendor site, he/she needs to login by entering the e- coin ID and the password. A JSP page handles the login request. If the e-wallet does not exist, the vendor’s application server communicates with broker application server via CORBA to get the e-wallet location, including host and port of the broker or previous vendor.
Then it communicates with the broker/previous vendor via CORBA to get the customer’s refreshed e-wallet.
This includes ecoinID, touchstone, index, paywords, and amount. After the customer clicks the article handing, a JSP page deals with a display content request.
The vendor application server debits e- coins from the server-side e-wallet paying for the content. The key components of the NetPay server-side e-wallet design as illustrated in Fig. 4.
5.2 Client-Side E-wallet NetPay
The client-side e-wallet is implemented as a Java application runs on the client PC. According to our protocol, a touchstone and an index (T&I) of a customer’s e-coin should be passed from the broker to each vendor.
To do this we have the broker application server provide a CORBA interface for vendor application servers to communicate with to get the T&I to verify e-coins. The vendor application servers also provide a CORBA interface in order for another vendor application server to communication with it to pass the T&I, avoiding use of the broker where possible.
We have developed a new protocol called NetPay that provides a secure, cheap, widely available, and debit-based protocol for an off-line micro-payment system [1]. NetPay differs from previous payword-based protocols by using touchstones that are signed by the broker and an e-coin index signed by vendors, which are passed from vendor to vendor. The signed touchstone is used by a vendor to verify the electronic currency – paywords, and signed Index is used to prevent double spending from customers and to resolve disputes between vendors. In this section, we describe the key transactions in the NetPay protocol.
Suppose an e-newspaper site wants to use the NetPay micro-payment system to sell articles on a per-page usage basis. The system involves four parties – a NetPay broker site; e-newspaper vendor sites; customer PCs; and a bank macro-payment system.
The customers can be classified as registered customers and unregistered customers. Only registered customers can buy e-coins from a broker’s site and click- buy an article with a newspaper site. Both types of customers can search and view article titles on line.
Initially a customer accesses the broker’s web site to register and acquire a number of e-coins from the broker (bought using a single macro-payment).
The broker creates an “e-wallet” that includes the e-coin ID, touchstone, and e-coins for the customer. This e-wallet may reside on the client PC (via a special application) or be passed to vendor servers.
The customer browses the home page of the newspaper web site and finds a desired news article to read. Each article will typically have a small cost e.g. 2-10c, and the customer would typically read a number of these. When wishing to read the de- tails of an article, the customer clicks on the article heading and the vendor system debits the customer’s e-coins by e.g. 10c (by taking 1, 2 or more e-coins from their payword chain, depending on the monetary value of each, up to 10c in value).
The newspaper system verifies that the e-coin provided by the customer’s e- wallet is valid by use of a “touchstone” obtained once only from the broker. If the payment is valid (coin is verified and sufficient credit remains), the article is dis- played on the screen. The customer may browse other articles, their coins being debited (the index of spent coins incremented) each time an article is read. If coins run out, the customer is directed to the broker’s site to buy more. The vendor keeps copies of the spent e-coins.
When the customer changes to another online newspaper (or other kind of vendor using the same e-coin broker currency), the new vendor site first requests the current e-coin touchstone information from previous vendor’s site. The new vendor.