WO2003046697A2

WO2003046697A2 - E-commerce payment systems

Info

Publication number: WO2003046697A2
Application number: PCT/ZA2002/000180
Authority: WO
Inventors: Valentin Kisimov; Desmond Seeley
Original assignee: Valentin Kisimov; Desmond Seeley
Priority date: 2001-11-30
Filing date: 2002-11-18
Publication date: 2003-06-05
Also published as: AU2002365598A1; AU2002365598A8; ZA200209009B; WO2003046697A3

Abstract

Equipment and a method of managing e-commerce transactions by an e-merchant (12) in which a customer (10) has a smart device (10.1) associated with a bank (14). The method includes in a suitable order the steps of: a) in response to a customer order (42), confirming the reputability of the e-merchant (12) to the customer (10) by generating a digital voucher (44); b) causing the customer's smart device (10.1) to verify the validity of the digital voucher and, if valid, to debit the cost of the purchases from the customer's e-purse (10.2); c) causing the customer's smart device (10.1) to generate and send an authorisation for payment message (50) to the e-merchant (12) from the customer (10); d) requesting payment by the customer's bank (14) to the e-merchant (12) in response to the received authorisation for payment (52); and e) causing payment (54) of the authorised amount to the e-merchant (12) by the customer's bank (14).

Description

E-COMMERCE PAYMENT SYSTEMS

TECHNICAL FIELD:

This invention relates to payment systems for electronic-commerce (e- commerce), implementing secure communications and transactions for use over the Internet, i.e. public network. The field of computing, generally and particularly in relation to the Internet, is replete with jargon, acronyms and terms and phrases that have specialised meanings that may vary with context and that sometimes are unrelated to their literal construction. Thus, the meanings of some terms used herein are defined in the glossary at the end of this specification.

BACKGROUND ART:

On-line payment systems are the basis of e-commerce. Existing on-line payment systems generally work with customers' credit cards, debit cards or some form of electronic money. Both customer and merchant are at risk when working with credit cards. For example, an e-merchant is exposed to the use of fraudulent credit cards or credit card numbers; this risk may be insured against or losses may be absorbed using appropriate transaction-risk assessment accounting. The customer is at risk in that his credit card number can be used fraudulently if intercepted on the Internet or if accessed from an e-merchant's data store and his financial and possibly also personal details can be sold to or used by marketers against his wishes. Additionally the customer has no guarantee for the delivery of his purchases by an e- merchant.

A payment or business protocol, known as SET, has been established in order to alleviate some of the risks set out above. SET requires dedicated computer hardware and software and each banking participant to an on-line transaction, i.e. the customer's bank and the e-merchant's bank, must support the SET protocol. The use of SET is currently limited, as relatively few banks have a payment gateway to support the SET protocol.

This invention thus seeks to provide a method for conducting e-commerce that at least ameliorates the risks to the e-merchant and customer outlined above in a manner that can be satisfactorily implemented by bank or banking service providers.

Aspects of the invention are thus concerned with: smart card based payment mechanisms using e-money stored in the e- purse of the smart card; confirmed reputability of electronic merchants (e-merchant) through financial institutions; electronic payment to an e-merchant from a purchaser's banker without transmitting a customer's financial details therewith; hiding all payment messages relating to a particular purchase between a purchaser and his banker from the e-merchant; - hiding all purchase activities between a purchaser and an e-merchant from the purchaser's banker; preventing any of a purchaser's financial data from being stored at an e-merchant's web site; implementing high-security Internet transactions and communications between purchaser, e-merchant and the purchaser's banker; and implementing high-performance and low-cost e-commerce payment mechanisms.

DISCLOSURE OF THE INVENTION:

One aspect of the invention provides a method of conducting or managing an e-commerce transaction between a customer, an e-merchant and a bank of the customer, the bank having facilities for administering e-money, the e- merchant having an e-commerce website and a public key for encryption of data, the customer having a smart device with an e-purse, the transaction including the active participation of the customer's bank, and communication links being established when required between the customer and the e- merchant, between the customer and his bank and between the e-merchant and the customer's bank, including the steps, in any suitable order, of a) permitting the customer to select at least one purchase from the e- commerce website and, in response thereto, causing at least one message to be sent from the customer to the e-merchant notifying the e-merchant of the selection; b) sending a confirmation message from the e-merchant to the customer, the confirmation message comprising the customer's selection, the public key of the e-merchant, and optionally the cost of the selection or items therein; c) causing the reputability of the e-merchant to be checked by the customer; d) causing the cost of the selected purchases to be debited from the customer's e-purse when the reputability of the e-merchant has been confirmed; e) causing an authorisation for payment message to be sent from the customer to the e-merchant, the message comprising an identification of the customer's bank, a summary of the debiting transaction administered by the smart device, and optionally a delivery address; f) sending a payment request message from the e-merchant to the customer's bank, the payment request message including the authorisation for payment message; and g) causing payment of the authorised amount to the e-merchant by the customer's bank to be transmitted when the authorisation for payment message has been verified by the bank. In the method, each of the specified steps, separately, may include: a. (selecting purchases): the step of electronically or program matically indicating one or more items that are to by purchased or placed in a list or "shopping basket" for delivery when payment has been made to the e- merchant. b. (sending a confirmation message from e-merchant to customer): the steps of the e-merchant collating messages of items to be purchased received from the customer to compile a list of the items ordered with their prices and sending these to the customer with an applet, alone or in a web page, the applet causing the customer's browser to display an order form to be completed and "submitted" to the e-merchant. c. (checking reputability of the e-merchant): the steps of sending a message from the customer to his bank, the message containing at least the e- merchant's public key and a request that the merchant's public key be signed by the bank and returned to the customer. This is to obtain a digital voucher from the customer's bank, the voucher signifying that in the bank's view the e-merchant is reliable and will in all probability deliver the purchase to the consumer satisfactorily.

This step, in turn, includes the bank checking, using the e-merchant's public key, through its own records and/or through publicly available records that the e-merchant is not on a list of barred e-merchants, such as a Financial Certificate Revocation List (CFL) prepared by financial authorities trusted by the bank or a list prepared by the bank itself. If the bank confirms the e- merchant is reputable, then it does so by signing the e-merchant's public key with the bank's private key and sending the signed order to the customer. The customer is thus able to check the reputability of the e-merchant by verifying the signature of the e-merchant's public key by the customer's bank.

Preferably the message sent to the bank by the customer is the confirmation message of step b.

The reputability of the e-merchant may be authorised or vouched for by another bank in which event the customer's bank sends or passes on that other bank's public key for verification of the signing of the e-merchant's public key. This occurs when and if the customer's bank trusts that other bank. d. (debiting the customer's e-purse) the steps of causing the customer's smart device to perform a calculation to deduct the cost of the purchases from the e-purse and return (or output) a result comprising the cost of the purchase and at least one of the initial or final (i.e. after deduction of the purchase cost) balances available in the e-purse. This is done only after receiving a confirmation of reputability from the bank. The functioning of the customer's smart device is driven by a code of the applet. The applet requests appropriate actions from the smart device by sending "smart device commands" to the device. Each smart device command includes operation code, optional data for transmission to the smart device and response from the smart device. Part or all of each smart device command is digitally signed with the e-merchant's private key. The checking of the e-merchant's reputability is executed inside the smart device; if the e- merchant is confirmed as reputable, then the e-merchant's public key is stored temporarily in the customer's smart device. From this moment all smart device commands sent from the e-merchant's applet to the smart device, will be verified successfully (using the already confirmed reputable e-merchant's public key) and they will receive permission for execution. e. (authorisation for payment message): the steps of securing the part of the authorisation for payment message having the customer's details by encrypting that part with the customer's private key and/or the bank's public key, so that the e-merchant cannot view or access the customer's digital identification, e-purse balances, etc. Other details for processing the purchases may be viewed/accessed, i.e. need not be secured.

The payment message as a whole is preferably further secured by encrypting it with the public key of the e-merchant to protect the information on the Internet. The information to be encrypted may be split into

I. information needed for processing by the customer's bank, such as the smart device's debiting summary and other financial data, which is encrypted using the public key of the bank and optionally signed by the customer's private key, and II. information needed for processing by the e-merchant, such as a confirmed purchase list, which is encrypted using the e-merchant's public key. In this way financial details are hidden from the e-merchant and purchasing details are hidden from the bank. f. (payment request message from the e-merchant to the customer's bank): the steps of encrypting this message using the public key of the bank and signing by the private key of the customer, which is decipherable only by the bank. This is to prevent the e-merchant altering the payment or fraudulently or illegally access the customer's e-purse or his account at his bank.

In practice the e-merchant controls the operation of the method, so that the following is intended to be protected: The operation by an e-merchant of e-commerce management software that performs the steps, in any suitable order, of: a) receiving at least one purchase request from a customer; b) sending at least one applet to the customer; c) sending to the customer the purchase request or a complied list of purchase requests and the e-merchant's public key; d) causing, using the applet, a message to be generated and sent from the customer to the customer's bank requesting the bank to sign the e-merchant's public key and to return same to the customer; and e) activating, using the applet with digitally signed smart device commands, the customer's smart device to cause it to debit the cost of the purchases from the e-purse therein and then cause a message to be generated and sent from the customer to the e-merchant, the message comprising the purchase list, an identification of the customer's bank and summary of the debit from the e-purse to the e- merchant, preferably with the whole message being encrypted with the public key of the e-merchant. Another aspect of the invention provides a method of conducting or managing an e-commerce transaction between a customer and an e-merchant, the customer having a smart device and a bank associated therewith that has facilities for administering e-money, including the steps, in a suitable order, of a) when required, establishing a communication link between the customer and the e-merchant and, when required, between the e- merchant and the customer's bank; b) selecting purchases by the customer; c) sending a message from the customer to the e-merchant identifying the customer's bank; d) generating a request from the e-merchant to the customer's bank to provide the e-merchant with a digital voucher confirming the reputability of the e-merchant; e) checking the reputability of the e-merchant by the customer's bank and providing, if applicable, a suitable digital voucher to the e-merchant, the digital voucher comprising the e-merchant's public key signed by the bank with its private key; f) sending the digital voucher from the e-merchant to the customer to confirm the reputability of the e-merchant to the customer; g) causing the customer's smart device automatically to debit the cost of the purchases from the customer's e-purse when the reputability of the e-merchant is received; h) sending an authorisation for payment message to the e-merchant from the customer, the message comprising an identification of the customer's bank and a summary of the automatic debiting transaction from the e-purse; and i) sending an aggregation message from the e-merchant to the customer's bank, the aggregation message comprising the customer's authorisation for payment message to the e-merchant.

The customer's bank effects payment to the e-merchant in response to receiving a valid aggregation message. An aspect of the invention thus provides the operation by an e-merchant of e- commerce management software that performs the steps, in any suitable order, of: a) receiving at least one purchase request from the customer; b) generating a request from the e-merchant to the customer's bank to provide the e-merchant with a digital voucher confirming the reputability of the e-merchant; c) sending a message comprising the digital voucher and the purchase list from the e-merchant to the customer to confirm the reputability of the e-merchant to the customer; d) causing, using digitally signed smart device commands in an applet, the customer's smart device to verify the validity of the digital voucher and thereafter, if valid, to debit the cost of the purchases from the customer's e-purse when the digital voucher is confirmed to be valid; e) causing, using digitally signed smart device commands in an applet, the customer's smart device to send an authorisation for payment message to the e-merchant from the customer, the message comprising an identification of the customer's bank and a summary of the debiting transaction from the e-purse, preferably encrypted by at least one of the bank's public key and the e-merchant's public key; f) partially decrypting the authorisation for payment message by the e- merchant to obtain delivery details for the purchases; and g) sending a request for payment message from the e-merchant to the customer's bank, the request for payment message including the customer's authorisation for payment message to the e-merchant.

The operations performed by the customer's smart device and/or computer and by the bank are preferably caused to be performed or are performed by one or more applets sent from the e-merchant to the customer and to the bank, respectively. Techniques for sending and activating applets on client machines are known to those skilled in the art.

The "digital voucher" comprises the e-merchant's public key and, optionally a timestamp, all signed by the voucher issuing bank. The digital voucher confirms the reputability of the e-merchant to the customer. The term "time stamps" includes, dates, expiry times and/or dates, credit limit data and so on.

The authorisation for payment messages referred to above, i.e. debiting summary and identification of customer's bank, and sent from the customer to the e-merchant, are preferably encrypted. More preferably the encryption comprises a double encryption, first the part of the message concerned with the customer's financial identification is encrypted using the public key of the customer's bank and then the entire message is encrypted using the public key of the e-merchant.

Additional encryption mechanisms may be used, such as those disclosed in South African Patent Nos. 2001/8196 through 2001/8199, hereinafter referred to as "said SA patents". Preferably, all communications between the customer and the e-merchant; between the customer and his bank; and between the e-merchant and the customer's bank, are also secured and encrypted using the high-security transactional mechanisms disclosed in said SA patents.

The reputability of the e-merchant may be checked or established by the bank in a number of ways, such as its own records, a CRL published by a trusted authority, a reference list maintained by or accessible to banks, and the like.

Confirmed reputability of an e-merchant by a customer's bank ascribes a higher-level trust to the e-merchant for the customer than checking for existence of the e-merchant in a CRL or financial CRL. To obtain confirmed reputability the e-merchant must activate a request for the appropriate customer's bank to sign the e-merchant's public key with the bank's private key. Issuing of such confirmed reputability can be done automatically by the customer's bank after it has used appropriate checking of the e-merchant. The e-merchant can activate the request for signing either periodically, for example daily at the beginning of each day, e.g. for a number of banks frequently used by customers for use in the second aspect of the invention, or during the e-commerce process, e.g. for banks that are seldomly or infrequently used, for use in both aspects of the invention.

Yet another aspect of the invention provides a method of managing e- commerce transactions by an e-merchant in which a customer has a smart device associated with a bank, including, in a suitable order the steps of. a) in response to a customer order, confirming the reputability of the e- merchant to the customer by generating a digital voucher; b) causing the customer's smart device to verify the validity of the digital voucher and, if valid, to debit the cost of the purchases from the customer's e-purse; c) causing the customer's smart device to generate and send an authorisation for payment message to the e-merchant from the customer; d) requesting payment by the customer's bank to the e-merchant in response to the received authorisation for payment; and e) causing payment of the authorised amount to the e-merchant by the customer's bank.

The digital voucher may be generated by the steps of:

I. sending a confirmation message of the order from the e-merchant to the customer, the confirmation message including a digital identification of the e-merchant and an applet; activating the customer's smart device using the applet to send a message to the customer's bank including digital identification of the e- merchant and a request that it be checked; and causing the bank to issue the digital voucher if the reputability of the e-merchant is confirmed; or II. the e-merchant requesting a digital voucher from the customer's bank; and the customer's bank checking the reputability of the e- merchant and issuing the digital voucher if such reputability is confirmed.

The digital voucher preferably comprises the public key of the e-merchant digitally signed by the customer's bank.

Further features, variants and/or advantages of the invention will emerge from the following non-limiting description of examples of the invention made with reference to the accompanying schematic drawings.

BRIEF DESCRIPTION OF THE DRAWINGS:

Figure 1 shows schematically a method for conducting e-commerce, with active participation of a customer's bank during a transaction according to the invention; Figure 2 shows schematically a system for confirming reputability of an e- merchant in the method of Figure 3; and

Figure 3 shows schematically a method for conducting e-commerce, without active participation of a customer's bank during a transaction of the invention.

EXEMPLARY MODE FOR CARRYING OUT THE INVENTION:

In the drawings the same or similar elements have the same reference numbers, certain elements having sub-numbers to identify them as part of an element or as substantially equivalent elements in different embodiments. Dark line arrows indicate messages and their transmission direction.

Figure 1 illustrates a method of the invention including participation of the customer's bank in a transaction, wherein there is a customer 10 having a smart device 10.1 containing an e-purse 10.2, an e-merchant 12, a bank 14 used by the customer, and the Internet 16. The customer, e-merchant and bank are in communication with one another via the Internet.

The method is initiated when the customer using his Internet browser visits an e-merchant's web site, the browser downloading and displaying one or more HTML web pages which contain or are downloaded with applets. When the customer selects one or more items to purchase, the appropriate applet causes this selection to be sent as a message 18 to the e-merchant's site. The message 18 may be sent either immediately with each selection or as a list of purchases in a "shopping basket". The e-merchant receives the message 18 or collection of messages 18, compiles a list of intended purchases and sends a message 20 to the customer. Message 20 comprises the list of purchases made by the customer and the e-merchant's public key. An applet sent with the message 20 causes the customer's browser to check with his bank 14 via sent and received messages 22 whether the e-merchant is reputable. This is done automatically by suitable applets, which amongst other things sends the e-merchant's public key to the bank. The bank checks whether the e-merchant's public key appears on any Certificate Revocation List (CRL) or on any list of permitted e-merchants. If in order the bank signs the e-merchant's public key with its private key and sends the bank issued "digital voucher" to the customer, confirming the e-merchant is reputable in its view.

If the e-merchant's public key is already signed not by the customer's bank, but by another bank, i.e. the e-merchant already has a bank issued digital voucher, the customer's bank sends the customer the public key of the other bank if it trusts that other bank. In other words, the bank validates the existing digital voucher by sending the customer the other bank's public key.

When the customer's browser receives the digital voucher, then an applet causes the e-purse application 10.2 in the smart device 10.1 to verify the e- merchant's public key and then, if in order, to deduct the value or amount of the shopping list from the available e-money in the e-purse. This is indicated by an internal operation 24. Operation 24 is activated when and only when the e-merchant's applet contains smart card commands that are digitally signed by the e-merchant. The smart device automatically and using a suitable applet creates and sends an authorisation for payment message 26 to the e-merchant. Message 26 comprises the customer's bank digital identification and the amount debited from the e-purse, the combination being encrypted using the public key of his bank; the name of the customer's bank in a plain text and, if appropriate, physical delivery details (name, address etc.). The entire message 26 is encrypted using the public key of the e-merchant.

The e-merchant, in an internal operation 28, decrypts message 26 to obtain the confirmed shopping list and the customer's delivery details, if available; the customer's bank digital identification and customer's digital identification cannot be decrypted by the e-merchant, as they are encrypted with the bank's public key.

The e-merchant sends a message 30 to the bank, the message comprising the customer's encrypted data portion. The bank checks the customer's banking details and provides payment 32 to the e-merchant, upon receipt of which the e-merchant arranges delivery of the purchase/s to the customer.

In effect this on-line payment method works with three parties, i.e. the customer, the e-merchant and the customer's bank. The customer trusts the e-merchant, because his bank, whom he trusts, issues a digital voucher for the e-merchant. The e-merchant cannot read any financial messages between the customer and his bank, because they are encrypted with the public key of the bank. If the e-merchant stores these details and a hacker obtains access to them, they are unreadable, except for the name of the customer's bank. The bank does not have any e-commerce details, because these are encrypted with the e-merchant's public key and the e-merchant transmits data relating to the purchase value only to the customer's bank.

None of the customer's credit/debit/account information is contained in any of the messages that are transmitted on the Internet. The number of exchanged messages is limited. There is no requirement for special and sophisticated equipment at any of the banks, i.e. the required security algorithms can be realised by software, and i.e. the bank need only have a suitable database or database access and be prepared to accept applets from e-merchants via its client's. Figure 2 illustrates a process for confirming reputability of an e-merchant 12 by a set of banks 14.1, 14.2, 14.3, etc. The first step in the process is the generation by the e-merchant of a message 34 requesting each bank to issue a digital voucher to the e-merchant, the digital voucher comprising the e- merchant's public key signed by the bank. Message 34 causes an internal operation 36 in the banks computer to check the reputability of the e- merchant, such as comparing the e-merchant's pubic key against a CRL available to or maintained by the bank and determining a trust level for the e- merchant, such as the value of a transaction that would be authorised, or even vouched for, by the bank. Various algorithms can be developed for checking e-merchant reputability. If in order, then the bank digitally signs the e-merchant's public key, i.e. adds a time-stamp and encrypts the e-merchant's public key and time stamp with the bank's private key and sends this with a message 38. Arrow 40 indicates a set of possible automatic activities which the e-merchant site performs to have its public key counter-signed by a number of banks.

Figure 3 illustrates a method of the invention for conducting e-commerce over the Internet without active participation of the customer's bank during an e- commerce transaction between a customer 10 and an e-merchant 12, the customer having a smart device 10.1, such as a smart card, with an e-purse 10.2.

The method starts when the customer accesses the e-merchant's web site and selects one or more items to purchase via his web browser, which sends the selection together with an identification of the customer's bank via message 42 to the e-merchant.

The e-merchant's software processes the shopping list and sends a reply message 44 to the customer containing the shopping list, prices of the selected items and its digital voucher, i.e. public key signed by the customer's bank. If the e-merchant does not have its public key signed by the customer's bank, then it obtains a digital voucher from the appropriate bank as a back- end process. On receipt of the reply message by the customer's browser, an applet causes an internal operation 46 in the customer's smart device to check whether the e-merchant's public key is signed by the right customer bank; the reputability of the e-merchant is now confirmed to the customer's smart device. In a second internal operation 48 the e-purse deducts the value of the shopping list from the available e-money in the smart device and forms and sends an authorisation for payment message 50 comprising the customer's bank's digital identification and purchase amount, both encrypted using the public key of his bank, the name of the customer's bank in plain text and delivery details (name, address etc.) if needed, the entire message being encrypted using the public key of the e-merchant. Operations 46 and 48 are activated when and only when the e-merchant's applet contains smart device commands that are digitally signed by the e-merchant.

The e-merchant decrypts the authorisation for payment message using its private key to obtain the delivery details and name of the customer's bank. The transaction is completed by the e-merchant sending the customer's encrypted data to the customer's bank 52, which data is decrypted using the bank's private key and checked 36, and the bank providing payment to the e- merchant 54.

In effect this on-line payment method works actively with the customer and the e-merchant and passively with the customer's bank. The customer trusts the e-merchant, because his bank creates a better trusted model, called "e- merchant's confirmed reputability", which to some extent results from checking the existence of the e-merchant's public key in a CRL. The e- merchant's reputability can be created in off-line mode with respect to the customer (for example at the beginning of the day), whereby the entire on-line payment method needs to embrace only two parties, i.e. the customer and the e-merchant. The e-merchant cannot read any financial messages between the customer and his bank, because they are encrypted with the public key of the bank. The privacy of the customer's banking and e-commerce details are preserved as described above.

All communications and operations are preferably secured and encrypted according to said SA patents.

The presented methods for payment contain all benefits of the SET protocol, while being robust and elegant in the sense of requiring minimal messages to be transmitted and minimal involvement of each bank as far as software, hardware and network bandwidth are concerned. These methods provide the following benefits: No credit card or other financial information of the customer is sent through the Internet. Only the customer's bank's digital identification is sent on the Internet and then it is suitably encrypted, e.g. triple encrypted with three different algorithms and suitable keys, such as those disclosed in said SA patents. All of the customer's security algorithms are executed inside his smart device, not on his PC or by an applet. The e-merchant is not given and so cannot posses the customer's banking and financial details. All messages are digitally signed. There is no involvement of or need for other parties in the proposed e-commerce payment, thereby making the payment mechanism efficient and quick. Transaction fees are collected only by the customer's bank. There is no risk to the customer regarding disclosing confidential banking details to the e-merchant. The customer is given an indication of the trustworthiness of the merchant via the presence of a bank issued digital voucher. The e-merchant is certain it will receive the payment, because it is confirmed by a bank. The merchant and the bank are each limited to that information which is dedicated to and needed by them. An e-merchant using this system will be more readily accepted as a reputable site by customers than e-merchants not using the system.

The invention is not limited to the precise details described above and shown in the drawings. Modifications may be made and other embodiments developed without departing from the spirit of the invention.

GLOSSARY - DEFINITIONS AND EXPLANATIONS OF TERMINOLOGY:

"smart device" means a device, such as a smart card, integrated circuit chip device, controllers in pervasive computing devices (see below) and the like that may exist or be developed, that includes a processor, a non- volatile memory (e.g. ROM, EEPROM, mini-disk), a volatile memory (RAM), and an operating system and that can store and process data sequentially or based on rules. Such devices may be viewed as intelligent plastic debit/ credit cards capable of being used for more functions and on wider scale, although currently used to a limited extent for identification and storing information. Such device may also be viewed as a micro-computer containing different programs with possible inter-operability between them. A feature of such devices is that data stored securely in the device, e.g. financial account numbers, private keys, etc., cannot be accessed, unless the device is linked to an authorised communicate and the device has been activated; even then, all communicated data is encrypted. Activation means entry of a suitable identification, such as a PIN code, biometric data, etc.

"pervasive computing" means the use of mobile devices, such as cellphones, so called "palm computers", etc., able to provide computing services anywhere and any time. Such devices are evolving rapidly, becoming more intelligent and embodying advanced smart devices and processors.

"protocol" means a digital language of data packets used by computers to communicate with one another over a network, such as a public network like the Internet, a local area network (LAN), a wide area network (WAN), a cell network, satellite linked network and the like. "security protocol" means a protocol in which the data packets are encrypted using an algorithm. Various security protocols exist, these being generally classified according to the basic protocol. "private key" means a unique set of digital characters, personal to each owner and usually assigned by a verification authority. A private key acts as a digital signature and may be used for decryption and signing.

"public key" means a unique set of digital characters associated with a private key and used to encrypt messages, the messages being decryptable using the corresponding private key only. A public key may also be used to verify a digital signature.

"digital certificate" means a form of digital identification containing the holder's key (or set of bits) assigned by a trusted authority, such as Verisign, that uniquely identifies the certificate holder and by means of which the identity of the holder can be authenticated via the trusted authority.

"sign" means to encrypt a message with the private key of the sender to identify the sender. (See verify).

"verify" means to decrypt a signed message using the public key of the sender, either already held or obtained from a trusted authority, to confirm the identity of the sender and that the message originated from the sender.

"encrypt" means to modify a message or each byte or data packet in a message using a key, the modified message being able to be decrypted using a suitable key. Asymmetrical encryption uses a public key for encryption and the corresponding private key for decryption. Symmetrical encryption uses a secret key for encryption and decryption.

"e-money" or means the electronic equivalent of physical money, the e- money being guaranteed by a financial institution that, ultimately, delivers the physical money equivalent to a designated payee.

"e-merchant" is a business offering goods and/or services for sale or hire on an Internet web site in return for payment by e-money.

"e-commerce" means the Internet activity of an e-merchant selling or hiring goods and/or services to customers in exchange for e-money.

"e-purse" is an application in a secure data store, such as a smart device, that holds e-money or personal details or access thereto. "applet" is a program, usually small, compact and often signed, comprising operators that is sent from one computing device (host) to another (client) and that runs on or in an application running on the client. The operator may display a message, perform software steps and/or return a result to the sender. In relation to the Internet, the host is a web server application and the client is a web browser, the applet running automatically within web browser. Internet applets are usually sent when the user of the browser accesses a web site which sends a web page to the client, the web page containing instructions and data in a suitable form, such as in hypertext markup language (HTML), for activating the applet.

Claims

CLAIMS:

1. A method of managing an e-commerce transaction between a customer, an e-merchant and a bank of the customer, the bank having facilities for administering e-money, the e-merchant having an e-commerce website and a public key for encryption of data, the customer having a smart device with an e-purse, the transaction including the active participation of the customer's bank, and communication links being established when required between the customer and the e-merchant, between the customer and his bank and between the e-merchant and the customer's bank, including the steps, in any suitable order, of a. permitting the customer to select at least one purchase from the e- commerce website and, in response thereto, causing at least one message to be sent from the customer to the e-merchant notifying the e-merchant of the selection; b. sending a confirmation message from the e-merchant to the customer, the confirmation message comprising the customer's selection, the public key of the e-merchant, and optionally the cost of the selection or items therein; c. causing the reputability of the e-merchant to be checked by the customer; d. causing the cost of the selected purchases to be debited from the customer's e-purse when the reputability of the e-merchant has been confirmed; e. causing an authorisation for payment message to be sent from the customer to the e-merchant, the message comprising an identification of the customer's bank, a summary of the debiting transaction administered by the smart device, and optionally a delivery address; f. sending a payment request message from the e-merchant to the customer's bank, the payment request message including the authorisation for payment message; and g. causing payment of the authorised amount to the e-merchant by the customer's bank to be transmitted when the authorisation for payment message has been verified by the bank.

2. The method of claim 1, wherein sending the confirmation message from e-merchant to customer includes the steps of the e-merchant collating messages of items to be purchased received from the customer to compile a list of the items ordered with their prices and sending these to the customer with an applet, alone or in a web page as desired, the applet causing the customer's browser to display an order form to be completed and optionally submitted to the e-merchant.

3. The method of claim 1 , wherein checking the reputability of the e-merchant includes the steps of causing a message to be sent from the customer to his bank, the message containing at least the e-merchant's public key and a request that the merchant's public key be signed by the bank and returned to the customer.

4. The method of claim 1, wherein the reputability of the e- merchant is verified by a digital voucher issued by the customer's bank, the voucher signifying that in the bank's view the e-merchant is reliable and will in all probability deliver the purchase to the consumer satisfactorily.

5. The method of claim 1, wherein the reputability of the e- merchant is verified by the steps of causing the bank to check, using the e- merchant's public key, through suitable records that the e-merchant is not on a list of barred e-merchants.

6. The method of claim 1, wherein the reputability of the e- merchant is confirmed to the customer by the bank signing the e-merchant's public key with the bank's private key and sending the signed order to the customer.

7. The method of claim 1 , wherein the message sent to the bank by the customer is the confirmation message of step b. of claim 1.

8. The method of claim 1, wherein the reputability of the e- merchant is vouched for by another bank, the customer's bank sending that other bank's public key for verification of the signing of the e-merchant's public key.

9. The method of claim 1 , wherein debiting the customer's e-purse includes the steps of causing the customer's smart device to perform a calculation to deduct the cost of the purchases from the e-purse and return a result comprising the cost of the purchase and at least one of the initial or final balances available in the e-purse.

10. The method of any one of the preceding claims, wherein the functioning of the customer's smart device is driven by code in the applet that initiates program commands in the smart device.

11. The method of claim 10, wherein each smart device command includes operation code, optional data for transmission to the smart device and response from the smart device.

12. The method of any one of the preceding claims, wherein at least part of each smart device command is digitally signed with the e-merchant's private key.

13. The method of any one of the preceding claims, wherein the checking of the e-merchant's reputability is executed inside the smart device, the e-merchant's public key being stored temporarily in the customer's smart device if the e-merchant is confirmed as reputable.

14. The method of claim 13, wherein the e-merchant's public key stored temporarily in the customer's smart device enables subsequent smart device commands sent from the e-merchant's applet and signed with the e- merchant's public key to be executed in the smart device.

15. The method of claim 1, wherein sending the authorisation for payment message includes the steps of securing the part of the authorisation for payment message having the customer's details by encrypting that part with at least one of the customer's private key and the bank's public key, so that the e-merchant cannot view or access the customer's digital identification, e-purse balances, etc.

16. The method of claim 13, wherein the authorisation payment message as a whole is further secured by encrypting it with the public key of the e-merchant to protect the information on the Internet.

17. The method of either of claims 15 or 16, wherein the information to be encrypted is split into (i) information needed for processing by the customer's bank, such as the smart device's debiting summary and other financial data, which is encrypted using the public key of the bank and optionally signed by the customer's private key, and

(ii) information needed for processing by the e-merchant, such as a confirmed purchase list, which is encrypted using the e-merchant's public key.

18. The method of claim 1, including the steps of hiding the customer's financial details from the e-merchant.

19. The method of claim 1, including the steps of hiding purchasing details from the bank.

20. The method of claim 1, including the steps of encrypting the payment request message from the e-merchant to the customer's bank using at least one of the public key of the bank and the private key of the customer, the latter being decipherable only by the bank.

21. A method of managing an e-commerce transaction by an e- merchant using e-commerce management software that performs the steps, in any suitable order, of: a. receiving at least one purchase request from a customer; b. sending at least one applet to the customer; c. sending to the customer the purchase request or a complied list of purchase requests and the e-merchant's public key; d. causing, using the applet, a message to be generated and sent from the customer to the customer's bank requesting the bank to sign the e-merchant's public key and to return same to the customer; and e. activating, using the applet with digitally signed smart device commands, a smart device of the customer to cause it to debit the cost of the purchases from the e-purse therein and then cause a message to be generated and sent from the customer to the e-merchant, the message comprising the purchase list, an identification of the customer's bank and summary of the debit from the e-purse to the e- merchant.

22. The method of claim 22, including the step of encrypting at least part of the message of step e. sent from the customer to the e-merchant using the public key of the e-merchant.

23. The method of claim 22, including the step of encrypting the whole message of step e. sent from the customer to the e-merchant using the public key of the e-merchant.

24. A method of managing an e-commerce transaction between a customer and an e-merchant, the customer having a smart device and a bank associated therewith that has facilities for administering e-money, including the steps, in a suitable order, of a. enabling a customer to select at least one purchase from the e- merchant; b. sending a message from the customer to the e-merchant identifying the customer's bank; c. generating a request from the e-merchant to the customer's bank to provide the e-merchant with a digital voucher confirming the reputability of the e-merchant; d. causing the reputability of the e-merchant to be checked by the customer's bank and providing, if applicable, a suitable digital voucher to the e-merchant, the digital voucher comprising the e-merchant's public key signed by the private key of the bank; e. sending the digital voucher from the e-merchant to the customer to confirm the reputability of the e-merchant to the customer; f. causing the customer's smart device automatically to debit the cost of the purchases from the customer's e-purse when the reputability of the e-merchant is received; g. causing an authorisation for payment message to be sent from the customer to the e-merchant, the message comprising an identification of the customer's bank and a summary of the automatic debiting transaction from the e-purse; and h. sending an aggregation message from the e-merchant to the customer's bank, the aggregation message comprising the customer's authorisation for payment message to the e-merchant.

25. The method of claim 24, including causing the customer's bank to effect payment to the e-merchant in response to receiving a valid aggregation message.

26. A method of managing an e-commerce transaction by an e- merchant using e-commerce management software that performs the steps, in any suitable order, of: a. receiving at least one purchase request from the customer; b. generating a request from the e-merchant to the customer's bank to provide the e-merchant with a digital voucher confirming the reputability of the e-merchant; c. sending a message comprising the digital voucher and the purchase request from the e-merchant to the customer to confirm the reputability of the e-merchant to the customer; d. causing, using digitally signed smart device commands in an applet, the customer's smart device to verify the validity of the digital voucher and thereafter, if valid, to debit the cost of the purchases from the customer's e-purse when the digital voucher is confirmed to be valid; e. causing, using digitally signed smart device commands in an applet, the customer's smart device to send an authorisation for payment message to the e-merchant from the customer, the message comprising an identification of the customer's bank and a summary of the debiting transaction from the e-purse; f. partially decrypting the authorisation for payment message by the e- merchant to obtain delivery details for the purchases; and g. sending a request for payment message from the e-merchant to the customer's bank, the request for payment message including the customer's authorisation for payment message to the e-merchant.

27. The method of claim 24, wherein the digital voucher comprises the e-merchant's public key and, optionally a timestamp, all signed by the voucher issuing bank.

28. The method of claim 24, including causing the authorisation payment message sent from customer to the e-merchant of step e. to be encrypted by at least one of the bank's public key and the e-merchant's public key.

29. The method of claim 28, wherein the encryption comprises a double encryption, first the part of the message concerned with the customer's financial identification being encrypted using the public key of the customer's bank and then the entire message being encrypted using the public key of the e-merchant.

30. The method of any one of the preceding claims, wherein confirmed reputability of an e-merchant by a customer's bank ascribes a higher-level of trust to the e-merchant for the customer than checking for existence of the e-merchant in a CRL or financial CRL.

31. The method of any one of the preceding claims, wherein confirmed reputability the e-merchant includes activating a request for the appropriate customer's bank to sign the e-merchant's public key with the bank's private key.

32. The method of claim 31 , including the steps of the e-merchant activating the request for signing by a bank periodically, for example daily at the beginning of each day, for a number of banks frequently used by customers.

33. The method of claim 31 , including the steps of the e-merchant activating the request for signing by a bank during the e-commerce process.

34. E-commerce equipment comprising a smart device for each customer and e-commerce management software that performs the steps, in any suitable order, of: a. receiving at least one purchase request from a customer; b. sending at least one applet to the customer; c. sending to the customer the purchase request or a complied list of purchase requests and the e-merchant's public key; d. causing, using the applet, a message to be generated and sent from the customer to the customer's bank requesting the bank to sign the e-merchant's public key and to return same to the customer; and e. activating, using the applet with digitally signed smart device commands, a smart device of the customer to cause it to debit the cost of the purchases from the e-purse therein and then cause a message to be generated and sent from the customer to the e-merchant, the message comprising the purchase list, an identification of the customer's bank and summary of the debit from the e-purse to the e- merchant.

35. E-commerce equipment comprising a smart device for a customer and e-commerce management software that performs the steps, in any suitable order, of: a. receiving at least one purchase request from the customer; b. generating a request from the e-merchant to the customer's bank to provide the e-merchant with a digital voucher confirming the reputability of the e-merchant; c. sending a message comprising the digital voucher and the purchase request from the e-merchant to the customer to confirm the reputability of the e-merchant to the customer; d. causing, using digitally signed smart device commands in an applet, the customer's smart device to verify the validity of the digital voucher and thereafter, if valid, to debit the cost of the purchases from the customer's e-purse when the digital voucher is confirmed to be valid; e. causing, using digitally signed smart device commands in an applet, the customer's smart device to send an authorisation for payment message to the e-merchant from the customer, the message comprising an identification of the customer's bank and a summary of the debiting transaction from the e-purse; f. partially decrypting the authorisation for payment message by the e- merchant to obtain delivery details for the purchases; and g. sending a request for payment message from the e-merchant to the customer's bank, the request for payment message including the customer's authorisation for payment message to the e-merchant.

36. A method of managing e-commerce transactions by an e- merchant in which a customer has a smart device associated with a bank, including, in a suitable order the steps of: a. in response to a customer order, confirming the reputability of the e- merchant to the customer by generating a digital voucher; b. causing the customer's smart device to verify the validity of the digital voucher and, if valid, to debit the cost of the purchases from the customer's e-purse; c. causing the customer's smart device to generate and send an authorisation for payment message to the e-merchant from the customer; d. requesting payment by the customer's bank to the e-merchant in response to the received authorisation for payment; and e. causing payment of the authorised amount to the e-merchant by the customer's bank.

37. The method of claim 36, wherein the digital voucher is generated by the steps of: I. sending a confirmation message of the order from the e-merchant to the customer, the confirmation message including a digital identification of the e-merchant and an applet; ii. activating the customer's smart device using the applet to send a message to the customer's bank including digital identification of the e- merchant and a request that it be checked; and iii causing the bank to issue the digital voucher if the reputability of the e- merchant is confirmed.

38. The method of claim 36, wherein the digital voucher is generated by the steps of:

I. the e-merchant requesting a digital voucher from the customer's bank; and the customer's bank checking the reputability of the e-merchant and issuing the digital voucher if such reputability is confirmed.

39. The method of any one of claims 36 to 38, wherein the digital voucher comprises the public key of the e-merchant digitally signed by the customer's bank.