Abstract:
A system for securely transferring digital tokens by electronic means includes a secure digital token handling domain and predetermined third parties. The secure digital token handling domain comprises a plurality of tamper-resistant electronic token holders. Each token holder has the ability to process and store information relating to the transfer of digital tokens. The token holders are able to communicate within the digital token handling domain only with other token holders. The token holders are able to communicate outside the digital token handling domain only with the predetermined trusted third parties. One or more of the trusted authorities being responsible for the administration of encryption matters. Communications between token holders within the digital token handling domain, and between token holders and the predetermined third parties involving encrypting and decrypting of messages. Digital token transfers can be securely performed within the digital token handling domain according to a predetermined method.

Description:
FIELD OF THE INVENTION  
         [0001]    The present invention relates to a system for securely transferring digital tokens by electronic means and a method for conducting the same.  
         BACKGROUND OF THE INVENTION  
         [0002]    There are several well known problems associated with the use of bank notes and coins. These include clumsiness, lack of longevity, forgery, transportation and protection costs, and an inability to transfer directly from person to person by electronic means. It is anticipated that digital token will have a significant role in the future provided that security issues can be sufficiently addressed.  
           [0003]    Some attempts have been made to provide digital token such as the Mondex scheme trialled in Swindon in the United Kingdom. This method used a classical asymmetrical encryption key. The sender of the electronic digital token encrypts a message with a public key, and the receiver recovers the digital token transfer message by decrypting with a private key.  
           [0004]    In this trial the value of money is represented as a combination of numerical value, currency type, a serial number and other administrative information. This representation was protected so that its intended monetary value is maintained, and its replication can be prevented. This was achieved using a combination of two methods. Firstly, a conventional digital signature was used, with a digitally signed token able to be redeemed by the receiver by electronically depositing it with a signing third party who verifies the authenticity of the signature. Secondly, methods were used to ensure the token is never unencrypted outside the secure environment. This environment is usually a tamper resistant enclosure in which the digital token is stored and the means for performing the cryptographic function are housed. Transactions required an exchange of public keys of the respective parties.  
           [0005]    This technique suffered from the following disadvantages. There is a need to know with absolute certainty the public key of the receiving party. In a face to face situation this was relatively straightforward. However it was difficult and uncertain if two transacting parties are far apart. The question of revocation can arise due to compromise of the public key. The Mondex approach is difficult to use and suffers from the same well known problem of any public key infrastructure system. There were also problems with the control of the public/private key pair. Once a person is issued with a public/private key pair, there is no way of controlling when the keys may or may not be used. One party receives a public key without knowing the validity of the key. The issue of the public/private key pair does not have a way to control when the receiver can use the private key to decrypt. Neither party can specify and enforce when decryption can take place.  
           [0006]    The present invention seeks to provide a solution that does not suffer from at least one of these disadvantages.  
         BRIEF DESCRIPTION OF THE PRESENT INVENTION  
         [0007]    It should be understood that throughout this specification the word token is used to mean a representation of something having value. In this context, a token may represent cash, tickets, gift vouchers, reward/loyalty points etc. A token can be a discrete item that may only be exchanged intact, such as a ticket. Alternatively, a token can be an item that is transient and merely representative of the value of the item, such as the amount of currency being transferred.  
           [0008]    According to a first aspect of the present invention there is provided a system for securely transferring digital tokens by electronic means, the system comprising at least:  
           [0009]    a secure digital token handling domain comprising a plurality of tamper-resistant electronic token holders, each token holder having the ability to process and store information relating to the transfer of digital tokens;  
           [0010]    means for said token holders to communicate within the digital token handling domain only with other token holders,  
           [0011]    means for said token holders to communicate outside the digital token handling domain only with predetermined trusted third parties, including one or more trusted authorities responsible for the administration of encryption matters;  
           [0012]    means for encrypting and decrypting secure communications between token holders within the digital token handling domain, and between token holders and the predetermined third parties;  
           [0013]    whereby, in use, digital token transfers can be securely performed within the digital token handling domain.  
           [0014]    According to a second aspect of the present invention there is provided a digital token holder comprising at least:  
           [0015]    a tamper-resistant store for storing digital tokens;  
           [0016]    communication means for enabling communication within a digital token handling domain only with one or more other token holders for the transfer of digital token to one of said other token holders;  
           [0017]    communication means for enabling communication outside the digital token handling domain only with predetermined trusted third parties including communication for receipt of a decryption key;  
           [0018]    means for encrypting and decrypting secure communications with token holders within the digital token handling domain, and with the predetermined third parties;  
           [0019]    control means for controlling the store of digital tokens according to a pre-programmed method of encrypted communication with other token holders within the digital token handling domain and predetermined trusted third parties to ensure secure exchange of digital tokens.  
           [0020]    Preferably the means for said token holders to communicate within the digital token handling domain is in the form of a digital cashier that resides in each token holder.  
           [0021]    Preferably the means for said token holders to communicate outside the digital token handling domain is in the form of a digital cashier that resides within the token holder.  
           [0022]    Preferably the means for encrypting and decrypting secure communications is in the form of a control means resident within each token holder.  
           [0023]    Preferably each control means operates according to a pre-programmed method of encrypting and decrypting communication to and from the respective digital cashier.  
           [0024]    Preferably the control means controls stores digital tokens according to a pre-programmed method based on information encrypted within communications with other token holders and predetermined trusted parties.  
           [0025]    Preferably the value of each type of digital token within the secure digital token handling domain remains constant except where digital tokens are added to the secure digital token handling domain by a source predetermined trusted third party or digital tokens are removed from the secure digital token handling domain by a sink trusted third party.  
           [0026]    Preferably the one or more trusted authorities provide each token holder with a decryption key for use in decrypting encrypted communication with other token holders.  
           [0027]    Preferably each token handler has a unique identification.  
           [0028]    Preferably the decryption key provided by each trusted authority is a private key capable of decrypting a message encrypted with a public key derived from the identification of the respective token holder.  
           [0029]    According to a third aspect of the present invention there is provided a method of exchange of digital tokens including the steps of:  
           [0030]    providing a secure digital token handling domain comprising a plurality of tamper-resistant electronic token holders, each token holder having the ability to process and store information relating to the transfer of digital tokens;  
           [0031]    a first of the token holders (DTH 1 ) communicating with a second of the token holders (DTH 2 ) by an exchange of one or more encrypted messages, the second token holder communicating with a corresponding predetermined trusted third party to obtain a decryption key;  
           [0032]    wherein the respective decryption key obtain by the second token holder enables decryption of one of the encrypted messages sent by the first token holder, wherein the one encrypted message includes the digital token.  
           [0033]    Preferably where the digital token is for the transfer of a currency, the token including an amount of currency transferred, wherein transfer of the digital token according to the encrypted message includes adding the amount to a store of currency in the second token holder.  
           [0034]    Preferably the DTH 1  is provided with an identification ID 1 . Preferably DTH 2  is provided with an identification ID 2 .  
           [0035]    Preferably the method further includes the step of a first trusted authority providing the DTH 1  with a first private key capable of decrypting a message encrypted with a public key derived from ID 1 . Preferably the first public key includes or is derived from a temporal value. More preferably the first private key is capable of decrypting a message encrypted with the first public key.  
           [0036]    Preferably the method includes the step of providing the DTH 2  with a second private key capable of decrypting a message encrypted with a public key derived from ID 2 . Preferably the second public key includes or is derived from a temporal value. Preferably the second private key is capable of decrypting a message encrypted with the second public key.  
           [0037]    Preferably the method includes the step of providing the DTH 2  with a symmetrical encryption key capable of encrypting a message that can be decrypted using the symmetrical encryption key or a decryption key derived from the symmetrical key (hereafter symmetrical decryption key). Preferably the symmetrical encryption key is permanently stored in the DTH 2 . Alternatively, the symmetrical encryption key is generated by DTH 2 . Preferably the symmetrical decryption key is permanently stored in DTH 2 . Alternatively, the symmetrical decryption key is generated by DTH 2 .  
           [0038]    Preferably the method includes the step of DTH 1  providing DTH 2  with ID 1 .  
           [0039]    Preferably the method further includes the step of DTH 2  encrypting the symmetrical encryption key and ID 2  using a public key derived from ID 1  to provide a first encrypted message. More preferably the public key is also derived from a temporal value.  
           [0040]    Preferably DTH 2  provides DTH 1  with the first encrypted message. Preferably the method further includes the step of DTH 1  using the first decryption key to decrypt the first encrypted message to obtain the symmetrical encryption key and ID 2 .  
           [0041]    Preferably DTH 1  displays ID 2  and the amount of token to be transferred to DTH 2 . Preferably DTH 1  receives confirmation to proceed with the transfer of the digital token. Preferably the digital token is encrypted with a public key derived from ID 2 . More preferably the public key is also derived from a temporal value.  
           [0042]    Preferably the decryption key is used to decrypt the encrypted message sent from DTH 1  to DTH 2  to obtain a second encrypted message. Preferably DTH 2  uses the symmetrical decryption key to decrypt the second encrypted message to obtain the digital token to be transferred.  
           [0043]    Preferably DTH 2  displays the information contained in digital token transferred. Preferably DTH 2  acknowledges receipt of the digital token to DTH 1 . Preferably DTH 1  displays the receipt.  
           [0044]    According to a fourth aspect of the present invention there is provided a method of exchange of digital tokens including the steps of:  
           [0045]    providing a first digital token holder (DTH 1 ) having a store for holding digital tokens and a first identification (ID 1 );  
           [0046]    providing a second digital token holder (DTH 2 ) having a store for holding digital tokens and a second identification (ID 2 );  
           [0047]    providing the DTH 2  with a private decryption key capable of decrypting a message encrypted with a public key derived from ID 2 ;  
           [0048]    DTH 1  receiving ID 2 ;  
           [0049]    DTH 1  receiving information concerning the digital token to be transferred to DTH 2 ;  
           [0050]    DTH 1  encrypting the digital token with the public key derived from ID 2  to provide an encrypted message;  
           [0051]    DTH 1  providing DTH 2  with the encrypted message;  
           [0052]    DTH 1  removing the digital token from its store of digital tokens;  
           [0053]    DTH 2  using the decryption key to decrypt the encrypted message to obtain the digital token to transferred;  
           [0054]    DTH 2  adding the digital token to its store of digital tokens.  
           [0055]    Preferably the information received concerning the digital token to be transferred is an identification of the token. Alternatively the information received concerning the digital token is the amount of a currency to be transferred, the amount forming the token.  
           [0056]    Preferably removing the digital token from the store of digital tokens involves deducting the amount of currency transferred to DTH 2  from the store of currency held as a token in the store for holding digital tokens of DTH 1 .  
           [0057]    Preferably adding a digital token to the store of digital tokens involved adding the amount of currency transferred to a token representing the amount of currency currently stored.  
           [0058]    Preferably the public key derived from ID 2  may also be derived from a temporal value. According to a fifth aspect of the present invention there is provided a method of exchange of digital tokens in the form of digital cash including the steps of:  
           [0059]    providing a first digital cash holder (DCH 1 ) having a store for holding digital tokens in the form of digital cash and a first identification (ID 1 );  
           [0060]    providing a second digital cash holder (DCH 2 ) having a store for holding digital tokens in the form of digital cash and a second identification (ID 2 );  
           [0061]    a first trusted authority providing the DCH 1  with a first private key capable of decrypting a message encrypted with a public key derived from ID 1  and optionally a temporal value;  
           [0062]    providing the DCH 2  with a second private key capable of decrypting a message encrypted with a public key including ID 2  and the current data and a symmetrical key capable of encrypting a message that can be decrypted using a symmetrical decryption key;  
           [0063]    DCH 1  providing DCH 2  with ID 1 ;  
           [0064]    DCH 2  encrypting the symmetrical key and ID 2  using a public key including ID 1  and the current date to provide a first encrypted message;  
           [0065]    DCH 2  providing DCH 1  with the first encrypted message;  
           [0066]    DCH 1  using the first decryption key to decrypt the first encrypted message to obtain the symmetrical key and ID 2 ;  
           [0067]    DCH 1  receiving an amount of digital cash to be transferred to DCH 2 ;  
           [0068]    DCH 1  encrypting the amount of digital cash with the symmetrical key to produce a second encrypted message;  
           [0069]    DCH 1  encrypting the second encrypted message with a public key including ID 2  and the current date to provide a third encrypted message;  
           [0070]    DCH 1  providing DCH 2  with the third encrypted message;  
           [0071]    DCH 1  deducting the amount from its store of digital cash;  
           [0072]    DCH 2  using the second decryption key to decrypt the third encrypted message to obtain the second encrypted message;  
           [0073]    DCH 2  using the symmetrical decryption key to decrypt the second encrypted message to obtain the amount of digital token to transfer; and  
           [0074]    DCH 2  adding the amount to its store of digital cash.  
           [0075]    Preferably DCH 2  displaying the amount of digital cash transferred.  
           [0076]    Preferably DCH 2  acknowledging receipt of the digital cash to DCH 1 .  
           [0077]    Preferably DCH 1  displays the receipt.  
           [0078]    According to a sixth aspect of the present invention there is provided a method of controlling a first digital token holder (DTH 1 ) to transfer a digital token to a second digital token holder (DTH 2 ), said DTH 1  having a communication means for communicating with DTH 2 , a store for holding digital tokens and a first identification (ID 1 ), said DTH 2  having a second identification (ID 2 );  
           [0079]    receiving a private decryption key capable of decrypting a message encrypted with a public key derived from ID 1 ;  
           [0080]    sending ID 1  to DTH 2  using the communication means;  
           [0081]    receiving a first encrypted message from DTH 2  using the communication means;  
           [0082]    decrypting the first encrypted message using the private decryption key to obtain a symmetrical key capable of encrypting a message that can be decrypted using the symmetrical key or a decryption key based on the symmetrical key and ID 2 ;  
           [0083]    receiving information concerning the digital token to be transferred to DTH 2 ;  
           [0084]    encrypting the digital token with the symmetrical key to produce a second encrypted message;  
           [0085]    encrypting the second encrypted message with a public key derived from ID 2  to provide a third encrypted message;  
           [0086]    sending the third encrypted message to DTH 2  using the communication means; and  
           [0087]    removing the digital token from the store of digital tokens.  
           [0088]    According to a seventh aspect of the present invention there is provided a method of controlling a first digital token holder (DTH 1 ) to receive a digital token from a second digital token holder (DTH 2 ), said DTH 1  having a communication means for communicating with DTH 2 , a store for holding digital tokens and a first identification (ID 1 ), said DTH 2  having a second identification (ID 2 );  
           [0089]    receiving a private decryption key capable of decrypting a message encrypted with a public key derived from ID 1 ;  
           [0090]    receiving ID 2  from DTH 2  using the communication means;  
           [0091]    encrypting a symmetrical key capable of encrypting a message that can be decrypted using the symmetrical key or a decryption key based on the symmetrical key and ID 1  using a public key derived from ID 2  to provide a first encrypted message;  
           [0092]    sending the first encrypted message to DTH 2  using the communication means receiving a second encrypted message from DTH 2  using the communication means;  
           [0093]    using the private decryption key to decrypt the second encrypted message to obtain a third encrypted message;  
           [0094]    using the symmetrical key or decryption key to decrypt the third encrypted message to obtain a digital token transferred from DTH 2 ; and  
           [0095]    adding the digital token to the store of digital tokens.  
           [0096]    According to an eight aspect of the present invention there is provided a method of controlling a first digital token holder (DTH 1 ) to transfer a digital token to a second digital token holder (DTH 2 ), said DTH 1  having a communication means for communicating with DTH 2 , a store for holding digital token and a first identification (ID 1 ), said DTH 2  having a second identification (ID 2 );  
           [0097]    receiving a private decryption key capable of decrypting a message encrypted with a public key derived from ID 1 ;  
           [0098]    sending ID 1  to DTH 2  using the communication means;  
           [0099]    receiving a first encrypted message from DTH 2  using the communication means;  
           [0100]    decrypting the first encrypted message using the private decryption key to obtain ID 2 ;  
           [0101]    receiving an amount of digital token to be transferred to DTH 2 ;  
           [0102]    encrypting the amount of digital token with a public key derived from ID 2  to provide a second encrypted message;  
           [0103]    sending the second encrypted message to DTH 2  using the communication means; and  
           [0104]    deducting the amount from the store of digital token.  
           [0105]    According to a ninth aspect of the present invention there is provided a method of controlling a first digital token holder (DTH 1 ) to receive a digital token from a second digital token holder (DTH 2 ), said DTH 1  having a communication means for communicating with DTH 2 , a store for holding digital tokens and a first identification (ID 1 ), said DTH 2  having a second identification (ID 2 );  
           [0106]    receiving a private decryption key capable of decrypting a message encrypted with a public key derived from ID 1 ;  
           [0107]    receiving ID 2  from DTH 2  using the communication means;  
           [0108]    encrypting ID 1  using a public key derived from ID 2  to provide a first encrypted message;  
           [0109]    sending the first encrypted message to DTH 2  using the communication means  
           [0110]    receiving a second encrypted message from DTH 2  using the communication means;  
           [0111]    using the private decryption to decrypt the second encrypted message to obtain an amount of digital token transferred from DTH 2 ; and  
           [0112]    adding the amount to the store of digital tokens. 
       
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS  
       [0113]    In order to provide a better understanding of the present invention, preferred embodiments will now be described in greater detail, by way of example only, with reference to the accompanying drawings, in which:  
         [0114]    [0114]FIG. 1 is a schematic representation of a system for securely transferring digital tokens by electronic means according to a preferred form of the present invention;  
         [0115]    [0115]FIG. 2 is a schematic representation of a digital token holder shown interacting with other components of the system of FIG. 1;  
         [0116]    [0116]FIG. 3 is a schematic diagram showing exchange of encrypted messages between tokens holders according to a preferred form of the method of the present invention. 
     
    
       [0117]    Referring to FIG. 1, there is shown a system  10  for securely transferring digital tokens by electronic means. The system  10  includes a secure token handling domain  12 , one or more trusted authorities  16  and one or more trusted third parties  20 . Trusted authorities  16  are also trusted third parties. The token handling domain  12  includes a plurality of secure tamper resistant electronic token holders  14 . In FIG. 1 there are a plurality of trusted authorities  18 . The trusted third parties  20  include at least one token source  22  and at least one token sink  24 .  
         [0118]    The token handling domain  12  is configured to able digital tokens to be passed only between token holders  14  within the token handling domain  12 . Thus, subject to the exception described below, the number or value of each type of digital token remains constant. Where the digital token represents a currency, the amount of tokens within the token handling domain  12  remains constant. The only manner in which a token is added to or removed from the token handling domain  12  is by one of the trusted third parties  20 . If a person wishes to add money to the pool of funds in their token holder  14 , it is taken from a conventional money source and added to their token holder  14  within the token handling domain  12  through one of the token sources  22 , such as a machine similar to an Automatic Teller Machine. Likewise cash is removed from the token handling domain  12  by removing it from one of the token holders  14 , it is provided to a token sink  24  where it is converted to a conventional form, such as cash or an electronic deposit into a bank account. If a person purchases a digital ticket from an electronic ticket vendor, the number of tickets of the type purchased remains constant within a new token handling domain  12  until a new ticket is purchased and transferred to one of the token holders  14 .  
         [0119]    Referring to FIG. 2, a secure digital token holder  14  is described in more detail. The token holder  14  includes a digital cashier  26  for interfacing with other token holders  14  within the token handling domain  12  or trusted third parties  20  or a trusted authority  18 . The token holder  14  also includes a token slot  30  for holding digital tokens. The token slot  30  may also hold one or more encryption/decryption keys. Alternatively the keys may be store in another secure memory of the token holder.  
         [0120]    The token slot  30  may be, for example, non volatile memory with error correction. The digital cashier  26  and token slot  30  are controlled by a control means  28  in the form of a microprocessor. The microprocessor encrypts and decrypts the communications of the digital cashier  26 . The control means  28  controls the digital tokens stored in the token slot  30  according to a pre-programmed method involving encrypted communication with other taken holders  14  within the digital token domain  12  and pre-determined trusted third parties  16  or  20  to ensure secure exchange of digital tokens. The digital token holder  14  is made physically tamper resistant so as to reduce the possibility of interference and fraud occurring.  
         [0121]    The token holder  14  may be in the form of a mobile/cellular telephone SIM card with the telephone that the SIM card is within acting as an interface between the user and the token holder  14 . The telephone may also provide the communication means between the digital cashier  26  and other the token holders  14 . Alternatively the telephone could function as the cashier  26 . The digital token holder  14  may take some other suitable form, such as for example a key ring.  
         [0122]    The transfer of information between the token holders  14  will preferably use a wireless communication such as the infra-red communication or radio frequency communication such as using the Bluetooth standard. Alternatively it may be modulated communication over a telephone network, including a mobile/cellular network.  
         [0123]    [0123]FIG. 3 (spanning 3 pages) shows a method  40  for the exchange of digital tokens in the form of digital cash between a first cash/token holder (DTH 1 ) and a second cash/token holder (DTH 2 ).  
         [0124]    Each digital cash holder, DCH 1  and DCH 2 , receives a respective private key PrK 1  and PrK 2 , specific to that digital cash holder from a respective trusted authority TA 1  and TA 2 , respectively. Each cash holder has a respective identification, ID 1  and ID 2 . The private keys, PrK 1  and PrK 2  are derived from the respective identification, ID 1  and ID 2  of the cash holders DCH 1  and DCH 2  and a temporal value such as the current date. Steps  42  and  44  show the respective cash holder DCH 1  and DCH 2  receiving today&#39;s private key PrK 1  and PrK 2 , respectively, from the respective trusted authority TA 1  and TA 2 . Each of the cash holders store the respective private key PrK 1  and PrK 2  for the duration of the day or other period of time or until a new private key is sent from the respective trusted authority. The method of providing the private key may be for example; on powering up of the cash holder, communication is established with its respective trusted authority, whereupon it downloads and stores the private key. It is preferred that the communication for the downloading of the private key is encrypted. This may be for example by the trusted authority using a public key to encrypt the private key PrK 1  or PrK 2 , the encrypted private key they being sent to the respective cash holder, whereupon it is decrypted using a fixed private key held within the respective token holder.  
         [0125]    When the respective owners of the cash handlers DCH 1  and DCH 2  agree upon a transaction involving the transfer of an amount of digital token from the cash holder DCH 1  to the cash holder DCH 2  the process of FIG. 3 continues from step  46 . At step  46  DCH 1  sends its identification ID 1  to DCH 2 . At step  48  DCH 2  receives ID 1 . It is not essential that ID 1  be encrypted, although it is preferred that at least a basic level of encryption be used. This may be for example to use a public key and private key set common to all digital cash handlers within the cash handling domain  12 . In addition to the cash holder&#39;s identification, the name of the respective trusted authority may be provided.  
         [0126]    Each cash holder can generate or has stored a symmetrical encryption key and symmetrical decryption key. The symmetrical decryption key is the same as or is derived from the symmetrical encryption key. The symmetrical keys may be fixed for each holder or may be generated each time a symmetrical key set is required. At step  50  the symmetrical encryption key (Sym.Key 2 ) and the identification of DCH 2 , ID 2  are encrypted using a public key derived from the identification of DCH 1 , ID 1  and the current date to form a first encrypted message (MSG 1 ). At step  52  the first encrypted message, MSG 1  is sent to the first cash holder DCH 1 . The public key derived from ID 1  and today&#39;s date is written as PuK (Id 1 , date).  
         [0127]    At step  54 , the first cash holder DCH 1  receives the first encrypted message MSG 1 . At step  56  DCH 1  decrypts the first encrypted message using private key PrK 1  to obtain, at step  58 , the symmetrical key, Sym.Key 2  and the identification of DCH 2 , ID 2 .  
         [0128]    At step  60  the user of DCH 1  enters the amount of digital cash to be transferred to the second cash holder DCH 2 , such as by keying the amount into a key pad of DCH 1 . This step may occur earlier in the process, such as prior to step  46 . At step  62 , the amount of digital cash entered is displayed to the user to receive confirmation of the transfer. Confirmation may simply be in the form of pressing an OK button or may involve the entry of a personal identification number. Once a confirmation of the transfer is received the first token holder, DCH 1  encrypts the amount using the symmetrical key Sym.Key 2  obtained from the second cash holder, to produce a second encrypted message (MSG 2 ) at step  64 .  
         [0129]    The second encrypted message MSC 2  is then encrypted using a public key derived from ID 2  and the current date (PuK (ID 2 ), date)), at step  66 , to produce a third encrypted message MSG 3 .  
         [0130]    At step  68  the third encrypted message MSG 3  is sent to a second cash holder DCH 2 . AT step  70  the amount is deducted from the of digital token within the d-cash slot  30 .  
         [0131]    Second cash holder DCH 2  receives the third encrypted message MSG 3  at step  72 . The second cash handler decrypts the message MSG 3  using second cash holder&#39;s private key PrK 2  to produce the second encrypted message MSG 2  at step  74 . The private key may be deleted if the system is configured to download a new private key every time it is used (or as determined). This way private keys are only used once, which provided added security. A private key may not be destroyed immediately upon receipt of a new key, but may be stored for a period of time. This can avoid problems caused by instantaneous key destruction and communication failures.  
         [0132]    At step  76 , the second encrypted message MSG 2  is decrypted using the second symmetrical key or second symmetrical decryption key to produce the amount. Now that the amount has been received by DCH 2  this amount can be added to the store of digital cash kept in DCH 2 &#39;s d-token slot at step  78 . The amount of token received is displayed to the user at  80  to confirm that the transfer of d-cash has occurred. Preferably the second cash handler DCH 2  sends an acknowledgement of the receipt at step  82 . The receipt may be encrypted using the same level of encryption as transfer of ID 1  from DCH 1  to DCH 2 . The receipt is received at step  84  and displayed by DCH 1  at step  86 . Optionally the amount of d-cash transferred may only be deducted from the store of c-cash once the receipt has been received.  
         [0133]    Variations on this procedure may occur. A first variation may be where the user of DCH 2  enters the amount in a “please pay me this amount request”. This procedure is substantially the same with the differences being listed as follows. DCH 2  may initiate the process by asking for the ID of DCH 1 . The process then proceeds with step  46 . At step  50  the amount may be encrypted within the first encrypted message along with Sym.Key 2  and ID 2 . Step  60  is therefore not required as the amount has been sent by DCH 2 , although the confirmation of the transfer of the amount is still required at step  62 . The process then continues as described above.  
         [0134]    Another variation may be where it is desired to asynchronously send token from DCH 1  to DCH 2 . This procedure occurs as follows. The identification of DCH 2  must be known to the user of DCH 1 . This may be, for example, in the form of a mobile phone number of the cash handler is in the form of a mobile telephone. Steps  46  to  58  are omitted from the process. At step  60  in addition to the entry of the amount of d-cash to transfer to DCH 2  the identification of DCH 2 , ID 2  will have to either be entered by the user or, for example, recalled from the telephone or SIM card&#39;s memory. Step  64  is omitted in this process, as is step  76 . Step  74  is varied in that the message sent from DCH 1  is decrypted using PrK 2  to produce the amount as the symmetrical key is not used in this process. The transfer of information in this manner may occur by text transfer, such as using short message service (SMS).  
         [0135]    The method of deriving the identity specific private key (PrK 1  and PrK 2 ) and public key PuK 1  and PuK 2  may be, for example, are derived from the token holder&#39;s identification use the algorithm/method described in the identity directory-less public key cryptographic system described in UK patent Application GB2370471. A description of this (IDPKC) is also provided at the URL www.cesg.gov.uk/technology/id-pkc/. This cryptography method allows for the generation of the cash holder (identity) specific private key by the trusted authorities and the public key derived from a cash holder identification and the current date by the cash holder. Another identity based encryption method that may be used is described at the URL http://crypto.stanford.edu/ibe/.  
         [0136]    The exchange of digital tokens other than cash is similar to the method outlined above. Where the tokens are non-cash currencies such as air mileage points, loyalty or reward points, redemption points, bonus points, etc. the manner is identical to handling cash except instead of amounts of cash being exchanged amounts of points are being exchanged. Where a digital token holder is capable of storing more than one type of token, a record of each type of token is stored against or within the token so that for example, loyalty points are not added to cash. In addition, where the currencies are different national currencies, such as for example US dollars and Singapore dollars, these forms of currency are kept separate by using an identifier identifying the type of token, ie. US dollar cash and Singapore dollar cash.  
         [0137]    Where the tokens are tickets, gift vouchers etc. that are discrete items that can only be exchanged intact, again the method is similar to those outlined above, with the exception that each digital token is kept separate from other digital tokens so that the value of each token is discrete and intact.  
         [0138]    It may be desirable for each token to contain a digital signature so that the authenticity of the item represented by the token can be verified when it is exchanged at a token sink for the item it represents. Furthermore, when a digital token is transferred to a second digital token holder, it may be desirable to look inside the token so that the user of the second digital token holder can confirm what the token represents. It may also be desirable to protect the digital token from damage/interference, in which case a fixed symmetrical key may be stored within each digital token holder in a tamper resistant manner so that the contents of each token can be encrypted. A hash can be taken of the encrypted token and kept in the hardware. The encrypted version of the token can then be stored anywhere inside the cash holder or left with a service provider. When the encrypted token is retrieved and transferred out of the token holder the hash of the encrypted token can be matched against the record stored in the token holder as proof of authenticity. The hash record will then be removed when the digital token is transferred out. Should there be any replication of the encrypted digital token the replication is sent to the same digital cash holder, the replication will not be considered valid due to its hash not being there anymore.  
         [0139]    The authenticity of a token can be checked using its distal signature, where if the digital signature is invalid the token will not be accepted. Upon verification of the authenticity of a token, it is added to the digital token slot. At this point an acknowledgment may be sent confirming that the digital token can be removed from the first digital token holders token slot.  
         [0140]    Where a receiver initiated transfer of a digital token occurs, the method is similar to that outlined above. In the place of requesting an amount of digital cash, the second digital token holder requests a specific digital token. The first digital token holder looks up a list of tokens its possesses and finds the appropriate digital token and requests confirmation of the transfer of the token. The rest of the procedure is the same with the amount of digital cash being transferred substituted with the token.  
         [0141]    This process can be further enhanced by the sender rendering the token invalid by damaging data contained within the digital token, such as by modification of the digital signature. If the damage is conducted in a known manner, the validity of the token can still be assessed but it can also be determined that it has been handed over/used. If, for example, the token is used as entrance to an event, the damage digital token can be used to allow re-entry into the event without having to pass a new entry token to the person leaving. Once the event is over the entire digital token can be deleted.  
         [0142]    Where a token is valid for multiple redemptions, it can be represented as a number of single use digital tokens. In this case the redemption process is identical to that of a single token.  
         [0143]    Conditions associated with the token can be represented as information in accompanying the token. For example, if a season ticket is represented then the digital token can include an appropriate accompanying condition. Other conditions might include a digital token that is non-transferable, a digital token that represents single entry for a group of people, or a digital token with conditions on the entrants such as age, membership or some other qualification of the token holder etc.  
         [0144]    The digital token with an associated set of condition, can represent the condition as additional data, for example, using XML, RDF or simply name and value pairs.  
         [0145]    In the simplest cases where the condition is attached to the identity of the token owner, the token will include a representation of the requirement prior to digital signing. For example, non-transferable condition may be represented by the inclusion of the identity of the digital token holder. Before token transfer can take place, a check is conducted to ascertain the token transferability. Only the digital token holder with a correct identity or a special redemption device (such as a specific digital token sink) is allowed to accept the transfer.  
         [0146]    When the condition relates to attributes of the owner of the token, then it will be necessary for the owner to show the redeemer a digitally signed attribute certificate or a physical equivalent to prove satisfaction of the conditions. For example, a digitally signed age certificate may be provided if the token represents entrance to an event which is restricted by age. Alternatively the token holder may show their drivers licence or some other form of physical identification to satisfy this requirement.  
         [0147]    This may result in some digital tokens not being able to be transferred within the secure digital token environment and only from a token source to a token sink.  
         [0148]    When the condition relates to the time and place of redemption, then additional functionality can be included for the digital token holder to check the validity of redemption in collaboration with the redeeming token sink.  
         [0149]    An example of a sequence of events for a token to go from token holder one to token holder two to an entrance to an event is provided below:  
         [0150]    DTH 2  sends a request for a specific digital token T.  
         [0151]    DTH 1  receives the request and looks up the list of tokens it possesses and finds the appropriate digital token T.  
         [0152]    The user of DTH 1  confirms both the token to be transferred and the recipient of the token.  
         [0153]    Using the public encryption key derived from DTH 2 &#39;s ID 2  and the current date the token is encrypted, which is represented as PB(ID 2  date)(T).  
         [0154]    When DTH 2  receives the encrypted token it will send a request Q for the necessary attributes of the digital token owner using public encryption key derived from the identification of DTH 1 , ID 1 , and the current date. Optionally, DTH 2  could first encrypt the request within symmetric key so that the answer can be encrypted with the symmetric key so that it remains confidential.  
         [0155]    Having received the encrypted message from DTH 2 , DTH 1  sends the requested information to DTH 2 . If the symmetric key is included, DTH 1  can use his key to encrypt the requested information and send it encrypted back to DTH 2 . When the conditions are verified the digital token is redeemed.  
         [0156]    If the request needs physical proof to show the attribute of the user of DTH 1 , then the request and response can take the form of inspection of a document by a person or a machine scanning a magnetic strip of a card or smart reader reading the information within a smart card or so forth.  
         [0157]    Modifications and variations may be made to the present invention without departing from the basic inventive concept. Such modification may include the timing of receiving the private key from the trusted authority. Rather than it being downloaded at the start of the day or upon power-up of the token holder, it may be downloaded as and when required and/or at predetermined intervals.  
         [0158]    Such modifications and variations are intended to be included within the concept of the present invention, the nature of which is to be determined from the foregoing description and appended claims.