Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3827—Use of message hashing
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/04—Payment circuits
  • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/22—Payment schemes or models
  • G06Q20/29—Payment schemes or models characterised by micropayments
• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07F—COIN-FREED OR LIKE APPARATUS
  • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
  • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
  • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
  • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption

Definitions

• the present invention relates to a digital payment transaction system.
• One promising approach uses a chain of hash functions to generate a series of digital payment tokens from a secret random or pseudo-random number.
• a series of digital payment tokens which is generated in this way is known as a coin stick.
• the hash function is a transformation which takes a variable size input m and returns a fixed length string h which is termed the hash value.
• the hash function is chosen to be a one-way function: that is to say, given a hash value h it is computationally infeasible to work out the input value m .
• a method of operating a digital payment transaction system comprising a) at a first party, (“the broker") generating a digitially encoded secret number b) storing at the first party the secret number c) communicating to a second party ("the user") the digitally encoded secret number, or a number derived therefrom d) generating a hash chain of values which are derived from the secret number e) communicating digitally encoded values from the hash chain from the second party to a third party ("the vendor”) in payment, which third party is selected from a multiplicity of potential vendors.
• the first aspect of the present invention provides for the first time a method of using a coin stick between three or more parties. This greatly increases the flexibility in operation of the transaction system, and makes it suitable, for example, for use in on-line trading with a multiplicity of vendors.
• the user may be issued with the secret random number by a bank. This forms the beginning of the hash chain.
• the user then uses a publically known hash function to operate on the serial number to produce a first hash value, and then operates on the first hash value with the hash function to produce a second hash value, and so on.
• the process is repeated a set number of times, say ten times, to produce a number of hash values corresponding to a number of units, each having a predetermined value.
• the user communicates to the vendor the value at the end of the hash chain, that is in this example the result of the tenth hash operation.
• the vendor validates this value by returning it to the issuing bank.
• the bank checks that the value is that expected for the tenth hash value generated from the relevant random secret number.
• the bank confirms to the vendor the validity of the value.
• the user wants to transfer, for example, three units of value, it communicates to the vendor the hash value three steps back along the hash chain, that is, in this example, the result of the seventh of operation of the hash function.
• the vendor is now able to validate this hash value without further communication with the bank, simply by operating on the transferred hash value with the hash function.
• the one-way nature of the hash function ensures that the vendor, despite knowing the value at the end of the chain, is not able to generate values preceding those which have been transferred by the user.
• a method of operating a digital payment transaction system comprising a) at a first party, (“the broker") generating a secret number b) storing at the first party the secret number c) generating at the first party a first hash chain of values which are derived from the secret number by successive operations of a hash function d) communicating to a second party ("the user") a digitally encoded value from the chain of hash values e) generating at the second party a second hash chain of values which are derived from the value communicated by the first party in step (d) f) communicating digitally encoded values from the said second hash chain to a third party (“the vendor”) in payment g) subsequently communicating to the second party from the first party a value in the said hash chain which precedes the value originally communicated in step (d) .
• This aspect of the present invention provides a transaction system in which, despite the one-way nature of the hash function, value can be transferred to the user of an existing coin stick, as well as value being transferred from the user. This makes it possible, for example, for a vendor to make a refund to the user, without it being necessary for the user to have a merchant relationship with a bank. Alternatively this capability can be used to top up a coin stick following further payment to the bank by the user without incurring the processing and communication overheads which would be associated with the generation of a new coin stick.
• the value potentially available to the user is effectively determined by the difference between two values held as two pointers, one at the party that issues the coin stick (termed "the broker") and one at the user, rather than being determined by a single pointer which corresponds simply to the number of unspent values in the hash chain.
• the value actually available at any instant corresponds to the difference between the highest pointer held by the user and the highest so- far revealed to a vendor.
• the vendor agrees with the broker to forgo its right to some of the value it has revealed to the broker, the broker moves its pointer, which corresponds to the value revealed to the user back down the hash chain, and issues to the user a value which precedes the hash value which was originally communicated in step (d) . This results in there being additional units of value which are available to the user for payment to the vendor.
• the payment transaction system is a pre-paid system in which, in step (d), the value from the hash chain is issued in return for payment by the second party to the first party.
• At least two of the first, second and third parties are all located remotely from each other, and digitally encoded hash values are communicated between the parties via a communications network which links the parties.
• the communications network uses Internet protocols.
• the present invention particularly addresses the needs of on-line trading, for example over the Internet.
• its use is particularly advantageous in this context.
• the invention is not however limited to use in this way and might also be used, for example, in transactions carried out with a payment card and an electronic terminal which reads the payment card.
• a payment server for use in a digital payment transaction system, comprising: a) means for generating a secret number; b) a store for storing the secret number; c) means for generating a chain of hash values from the secret number by successive operations of a hash function; d) means for issuing to a user a value from the said chain of hash values; and e) means responsive to a request from the user or from another party for issuing to the user another value from the said hash chain of values which precedes the value originally issued in step (d).
• a method of operating a digital payment transaction system including issuing to a user a plurality of different hash chains corresponding to different monetary denominations.
• This aspect may advantageously be combined with the method of one or more of the other aspects of the invention, but may also be used independently of those other aspects.
• a method of operating a digital payment transaction system comprising a) at a first party, (“the broker") generating a digitally encoded secret number b) storing at the first party the secret number c) communicating to a second party ("the user") the digitally encoded secret number, or a number derived therefrom d) generating a hash chain of values which are derived from the secret number e) communicating digitally encoded values from the hash chain from the second party to a third party ("the vendor”) in payment, which third party is selected from a multiplicity of potential vendors; f) subsequently selecting another one of the multiplicity of potential vendors and communicating one or more further values from the hash chain generated in step
• This aspect of the invention may be combined with the preceding aspects, but may also be used independently of them. It enhances the fexibility in use of the coin sticks by allowing the user to switch between different vendors. It is particularly preferred that when the switch between users takes place, that the responsibility for alerting the broker should lie with the new vendor.
• the number of potential vendors available for selection is greater than or equal to 500, and more preferably is greater than or equal to 1000.
• Another significant feature of the present invention is its scalabilty to large scale systems with many vendors.
• Figure 1 is a schematic of a network embodying the invention
• Figure 2 is a diagram showing in futher detail the components of the network of Figure 1 ;
• Figure 3 is a diagram showing a chain of hash functions used in the generation of a coin stick.
• a client terminal 1 which in this example is a personal computer, is connected via a modem 2 and the PSTN (public switched telephony network) 3 to an Internet Service Provider (ISP) 4.
• ISP Internet Service Provider
• the client terminal forms, at different times, connections to a broker 6 who operates a payment server and to one or more of a number of on-line vendor 5.
• the vendors 5, in this example offers a service for payment.
• the vendor may serve pages of personalised news items using HTTP (hypertext transfer protocol) at low charges per page.
• the client terminal runs a Web browser application, such as Microsoft Corporation's Internet Explorer (trademark).
• a payment application is run in conjunction with the web browser as a plug-in or helper application.
• the payment server runs on an appropriate platform, in this example a UNIX workstation.
• Figure 2 shows in further detail the structure of the client payment application, of the payment server and of the vendor.
• the client payment application comprises a payment module 102 , a messaging module 103, and a local data store 104.
• the payment server comprises a coin stick issue module 601 , a verifier module 602, a messaging module 603, and a settlement module 609.
• a random number generator 604 is connected to the coin stick issue module 601 .
• a local data store 605 stores data about coin sticks which have been issued to users.
• the vendor includes a payment transaction module 501 , a verifier module 502 and a messaging module 503.
• a data store 504 at the vendor stores digital payment tokens which have been received from the user.
• the broker offers three interfaces for incoming requests: a coin stick issuing interface 606, an authorisation interface 607 and a settlement interface 608.
• the vendor offers two interfaces for incoming requests, a payment interface 505 and a call-back interface 506.
• the client 1 first contacts the broker and purchases a coin stick. Subsequently the client 1 contacts the vendor 5. When the client wishes to make a purchase the transfer a value from the coin stick to the vendor.
• the vendor 5 communicates with the broker 6 to verify the validity of the end-value derived from the value received from the client 1 . The validity is confirmed to the client, and the purchase of, e.g., HTTP pages then goes ahead.
• the vendor 5 stores values which are received from the client 1 . Vendor 5 subsequently returns the received values to the broker 6. The payment transaction is completed by the broker 6 then paying the vendor 5 accordingly.
• the vendor 5 may also contact the broker 6, and request that a refund be made to the client 1 .
• the client 1 initially contacts the broker 6 by accessing, using the Web browser, an Internet URL (uniform resource locator) which corresponds to the interface 606 of the coin stick issue module 601 of the broker 6.
• the coin stick issue module 601 executes a CGI (Common Gateway Interface) script which accepts and processes data from the user, and establishes a digitally signed contract with the user, as will be further described.
• the client requests from the broker 6 a coin stick of a specified value, say £1 0 and in a specified denomination, say 10p.
• the client pays the broker for the coin stick, for example by communicating in encrypted form the user's credit card number.
• an anonymous payment method such as Mondex (Trademark) could be used.
• the coin stick issue module reads from the random number generator 604 a 1 60 bit value z 0 .
• the coin stick issue module operates on this value z 0 with a hash function to produce a hash value z-i , operates on ⁇ . ⁇ with the hash function to produce a further hash value z 2 , and so on.
• the processing with the hash function is iterated a predetermined number of times, for example 50 times, and the resulting value z m is issued to the client 1 , to form the basis of the coin stick.
• the broker stores a pointer which records the position m in the hash chain of the value issued to the client 1 .
• the term "pointer” is used in this specification broadly to denote an index value or similar stored indicator. It is by no means limited to a pointer as implemented in programming languages such as C + + which employ what is termed "pointer arithmetic").
• the value z m may be encoded for transfer to the client 1 , for example using a public key algorithm such as RSA dual key .
• the value z m is issued bound in a digitally signed contract.
• the contract includes the following data: v 0 , the coin stick value d u , the coin stick denomination h u , the hash function i, a coin stick identifier, unique within the broker
• URL A the address of the broker's authorisation interface.
• the hash function may be any one of a number of cryptographic hash functions in common use. Appropriate hash functions include those known as SHA1 and RIPE MD( 1 60).
• Both the hash function and the denomination need not be directly communicated in each message but may be implied by reference to a standard protocol name, however, including the hash function and the denomination explicitly in each message makes it easier to upgrade the protocol should the need arise due to monetary inflation or due to mathematical compromise of the hash function.
• the contract between the broker and the client stipulates that once any coin on the coin stick has been revealed to any vendor, the liability on the bank's part to refund the value beyond that coin transfers from being a liability to pay the user, to a liability to pay the vendor.
• the user is therefore able to transfer monetary value to a vendor by revealing values from the coin stick.
• the client 1 Having purchased the coin stick from the broker, the client 1 subsequently accesses the Web site of the vendor.
• the client 1 requests access to a number of pages of personalised news information under different headings and each conforming to a profile corresponding to the particular interests of the user.
• the transaction module 501 in the vendor calculates the total price of the requested pages, v p , and requests a prepayment of this value from the client 1 into its payment interface.
• the payment interface may be located at the vendor and operated under the direct control of the vendor. Alternatively, the vendor may sub-contract the payment operation to another party, in which the payment interface is operated under the control of that sub-contractor.
• the vendor also calculates p and runs this many more hash functions on the hash value z m + n . p to arrive at the value z m + n .
• the vendor connects to the broker's authorisation interface at URL A , passes the broker its callback interface, URL C and requests confirmation that z m + n is the value at the length of the coin stick with identity i issued to the client.
• the broker checks its stored data, and compares the value of z m + n communicated by the vendor with the expected value for the end of the coin stick i by running the same hash sequence.
• the broker replies to the vendor confirming that it will honor payments made with this coin stick, up to the value v 0 , on its settlement interface URL S . If the user has tried to defraud the bank, by increasing the length and hence the value of the coin stick, for example to z m + n + 1 , then the bank refuses the transaction at this point.
• the vendor can disconnect from the broker.
• the vendor now delivers the goods to the client.
• Subsequent requests for goods then require the payment module 102 to calculate the number of units of the coin stick denomination which are required to match the requested price. If, for example, three units are required, then the payment module communicates to vendor the hash value which is three steps back in the hash chain from the current end value z m + r p The transaction module 501 at the vendor receives this hash value, checks that three further hashes result in the previous end hash value, if so stores the new end hash value in data store 504 and supplies the goods.
• the client 1 maintains a pointer to the last hash value transferred, and this provides an indication of the remaining value in the coin stick.
• the client may make further payments to the vendor subsequently by revealing other hash values which are still further back in the hash chain.
• the vendor may collect the money owed to it at any time by communicating the last revealed hash value to the broker's settlement interface at an address URL S .
• the broker will require the vendor to identify themselves with a digital certificate before settling the account.
• the vendor may wish to make a refund to the client 1 , for example because one of the pages returned in response to the initial transaction was corrupted and unreadable.
• the transaction module 501 communicates to the broker 6 the identity i of the relevant coin stick and the number of units of denomination, say two, which are to be refunded.
• the broker recalls from the store 605 data on the relevant coin stick including the callback interface of the vendor, URL C .
• the broker reads the hash value z m _ 2 which is two steps back in the hash chain from the value z m which was originally communicated to the client.
• the broker disconnects from the vendor and re-connects to URL C to check the refund requirement is valid.
• the vendor signals to the client 1 that the refund is available.
• the broker stores the fact that now the vendor is entitled to settle for two less units than originally contracted in the same way that any partial settlement would be recorded.
• the client accesses the URL of the coin stick issue module 601 , and receives from the broker the new hash value z m _ 2 .
• the client payment application then resets its pointer to indicate that it has two additional denomination units of value remaining in the coin stick i.
• the broker resets its respective pointer to m-2.
• the procedure described above, in which the broker issues a new secret number to the client from further back in the original chain of hash functions, may also be used by the broker to top-up a previously issued coin stick, in return for a further payment received from the client.
• Such an arrangement has the advantage, by comparison with the issuing of a new coin stick, that a new digitally signed contract with the client is not required, and the processing and communication overheads associated with a new contract are avoided.
• the broker and the client may compute once and then store all the values in the hash chain. Alternatively, only the initial values in the chains may be stored, and the repeated hasH functions may then be computed each time a specific value in the hash chain is needed for a transaction.
• the user might take a smart card to the user's bank, acting as the broker.
• the coin stick data may then be loaded directly in the memory of the smart card from a card reading/writing terminal connected to the platform which supports the broker modules.
• the transactions with the vendor might be carried out between the user's smart card and an EPOS (electronic point of sale) terminal.
• the client functions are implemented on a smart card
• the vendor functions are implemented in an EPOS
• the function performed by the Internet in the first example is replaced by the internal connections of the EPOS.
• the system operates as described in the first example.
• the interfaces to the functions offered by each party are characterised by URLs that invoke processes through the CGI, these services may be offered by any invocation mechanism such as remote procedure call to object interfaces, either over Internet protocols or other more proprietary communications systems.
• the Web browser might be replaced by a specialist client module.
• the broker is characterised as a single party.
• the user could interact with one broker and the vendor with another; each broker communicating with the other, for example, through a traditional electronic funds transfer system.
• the efficiency of the system for the user can be further improved by issuing a bundle of coin sticks in different denominations (e.g. 0.1 p, 1 p, 10p, £1 ) . These may be distinguished by different starting numbers, and/or by different hash functions, preferably by both.
• the broker generates a number of hash chains, one for each denomination, and issues an intermediate value from each chain to the user, together with data which identifies the relevant denomination. The user then makes payments by calling off values from the different hash chains in the most efficient combinations.
• Another feature of the present implementation is that it allows the user to switch between vendors with a partially used coin stick. There are three ways for the user to switch their coin stick from vendor
• vendor M2 could simply approach vendor M2 and make it their responsibility to get the appropriate acknowledgement from vendor M 1 via the bank .
• the bank has to contact vendor M 1 rather than the other way round. If either is the one implemented, the previously described protocol between the vendor and the bank is modified by adding the vendor's interface (for sending a stop message) to the information sent to the bank.
• vendor M2 just as if their coin stick was freshly bought from the bank.
• vendor M2 approached the bank for authorisation, the bank would recognise there was a preexisting contract covering that stick with a different vendor, M 1 .
• the bank would send a stop message to vendor, M 1 's appropriate interface and await a reply confirming the last hash value to have been sent by the user.
• the bank would then confirm its contract to settle was now limited to the balance up to the current length of the stick. Only on acknowledgement of this would a new contract then be sent to vendor M2, preventing the double use of any coins.
• a request to settle from vendor M 1 would accompany the reply from vendor M 1 .
• the bank may charge a fee for settlement, which would discourage vendors from allowing users to switch vendors after only running up a small account. It is therefore likely that vendors would pass on the barrier of this minimum fee to the user by charging a minimum fee themselves for their service. Because this itself introduces a barrier to the use of micropayments, a far more likely solution would be for a vendor not to pass on this minimum payment barrier to its users, but instead to aggregate all the small payments from many users until they were economic to redeem from the bank.
• vendor M 1 has to be willing to relinquish their hold on the user's account (coin stick) by acknowledging they have received- the message warning them not to accept further coins, before the bank can authorise another vendor to use the stick. Therefore, if the user wishes to have this flexibility, she must ensure the original contract with vendor M 1 includes such an undertaking.
• the distributed failure modes here are potentially difficult, as it is necessary to avoid creating a distributed two phase commit.
• the above series of messages is fail-safe.
• the present embodiment uses a further fourth alternative based on the second alternative described above.
• the contract between vendor and bank stipulates that, if at any time the vendor's call-back interface, URL C , had been off-line, the vendor would be liable for any losses caused by accepting hash value coins in exchange for goods without first checking with the bank that there had not been an attempt to send a stop message by the bank during the downtime.
• the vendor's callback interface is down their sales interface is also down, after a period of down-time it becomes the vendor's responsibility to request any messages queued for the callback interface and process them before accepting requests on the sales interface.
• the vendor would take the risk if they wished to continue accepting sales. This is preferred because the user can switch to M2 at any time, whether
• M 1 is on-line or not. Normally a live acknowledgement from M 1 would be expected, but if it became obvious this was not going to be received (e.g. after a time-out), the bank would simply queue the message for M 1 and allow the switch to proceed knowing the risk was with M 1 . This does open the vendor to a denial of service attack on their call-back interface while the user switches to another vendor and simultaneously continues to purchase goods from the first vendor, but as already stated, if the vendor can detect the denial of service on its call-back interface, it simply has to shut down its sales interface.

Priority Applications (1)

Applications Claiming Priority (4)

Publications (1)

Family

ID=26147369

Family Applications (1)

Country Status (2)

Families Citing this family (17)

Family Cites Families (6)

• 1998
  • 1998-03-23 WO PCT/GB1998/000883 patent/WO1998043211A1/en active Application Filing
  • 1998-03-23 EP EP98912621A patent/EP0972276A1/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events