WO2016202952A1

WO2016202952A1 - Digital token exchange system

Info

Publication number: WO2016202952A1
Application number: PCT/EP2016/063948
Authority: WO
Inventors: Hitesh Tewari; Eamonn O'nuallain
Original assignee: The Provost, Fellows, Foundation Scholars, & The Other Members Of Board, Of The College Of The Holy & Undiv. Trinity Of Queen Elizabeth, Near Dublin
Priority date: 2015-06-16
Filing date: 2016-06-16
Publication date: 2016-12-22
Also published as: GB2539430A; GB201510528D0

Abstract

A digital token exchange system and a method of encoding one or more digital tokens exchanged within that system are disclosed, wherein the system comprises a peer-to-peer network with a plurality of user terminals operated by respective users and a plurality of servers. A respective cryptographic key pair comprising at least one public key is instantiated for each user and server in the system. Each user in the system registers their respective public key and a respective unique identifier with at least one server, and requests instantiation of one or more digital tokens by that server. One or more digital tokens are instantiated at the server, wherein the or each token comprises a plurality of codes defining a block chain wherein the block chain comprises a series of transaction blocks stored on the token. The server digitally signs the or each token based on the plurality of codes with its private key.

Description

DIGITAL TOKEN EXCHANGE SYSTEM

Field

[0001 ] The present invention relates to a digital token exchange system. More particularly, the present invention relates to a peer-to-peer network in which digital tokens are instantiated and encoded by network users for use as currency.

Background

[0002] Currencies exist in tangible form as coins and notes and as digital records in electronic ledgers, in each case originally created by official mints or central banks. A longstanding, fundamental aspect of any currency is that parties to any transaction in which a currency is exchanged must both believe in the authenticity of that currency, namely that it is real and therefore has a value, to the contrary of e.g. a forged banknote, and must both agree to the intrinsic value of that currency at the time of the transaction, which value is defined at any one time by a vast combination of factors miscellaneously including the volume of that currency in circulation, the exchange rate of that currency relative to others, inflationary effects, and more.

[0003] In the field of electronic transactions, a relatively recent development is the advent of virtual currencies that are not minted by national mints or central banks, but which exist as stateless and non-denominated electronic tokens, that are nevertheless still exchanged as currency for goods and services. The fact that such virtual currencies exist outside traditional financial systems all having official mints and central banks as their common origin has caused a number of administrative problems about the aforementioned fundamental characteristics of currency, namely the resilience to fraudulent tampering and the intrinsic value of the virtual currency, and a comparable number of technical problems in implementing electronic solutions, particularly in the fields of token creation, token encryption and token exchange traceability, all contributing to a continuing sub-optimal use of networking and computing resources.

[0004] Physical financial instruments are used to transact for goods and services. In order for the general public to have confidence in these instruments, security measures are required to ensure that notes and coins cannot be easily forged. In the digital world, strings of bits are used to embody financial information and these can be easily stored and replicated. There is therefore a clear need to ensure that digital currency cannot be forged or double spent. Public key cryptographic techniques such as digital signatures are used to solve this problem. However, unlike fiat currencies, a recipient cannot accept a digital coin based solely on a digital signature. Additional third-party verification is required to ensure that a digital coin is not being double spent by its owner. Addressing this double spending problem is at the heart of the design of the two most prominent electronic cash schemes of the past thirty years, ecash and Bitcoin ®.

[0005] Virtual currencies first gained prominence in the form of ecash, attributed to David Chaum and implemented in 1995. In the ecash system, a user could withdraw digital coins from a commercial bank against an existing account and the digital coins were authenticated with a blind signature protocol. This protocol allowed the user to mint a number of digital coins and forward these unsigned digital coins to a bank. As long as these digital coins met certain criteria, the bank signed them with its private key without knowledge of the serial numbers associated with the digital coins. On receiving the digital coins back from the bank, the user removed the blinding factor and used the digital coins to pay for goods at any merchant participating in the system. On receipt of digital coins, a merchant had to immediately forward them to the bank for verification. The bank maintained a database of the serial numbers of all coins that had been spent in the system, and was thus able to detect any instance of double spending.

[0006] In the ecash implementation, the blinding factor was a random number used to obfuscate the serial number of the electronic coin from the bank. Mathematically, the RSA Blind Signature scheme can be illustrated with the following steps. Let m be the serial number of the digital coin, r be the blinding factor, and e and n be the public key exponents of the bank. The sender raised r to the public key exponent e and computed the product of the serial number and blinding factor: m'≡ m (mod n). The bank signed the blinded serial number with its private key: s'≡ (m')^d(mod n). The bank returned the digital coin to the user, who then removed the blinding factor: s≡ s '- r ^~l(mod n). The user then had a digital coin signed with the private key of the bank: s≡ (m ')^d r ^~x≡ m^d f^d r ^~x≡ m^d rr ^Λ≡ m^d (mod n).

[0007] The main technical disadvantage of the ecash system and implementation was the server-centric nature of the protocol, under which the bank server had to remain permanently available, thus wherein a hardware failure, network outage of any sort, cyber attack or any other happenstance taking the bank server offline would effectively paralyze the exchange of ecash digital coins. Another significant technical disadvantage of ecash was that ecash digital coins were not re-usable in the manner of existing physical or digital currency being exchanged in successive transactions: after an ecash token was used in a transaction, the bank server would still need to maintain its serial number recorded in an ever-growing database of spent digital coins, and check that database before accepting any new coins and for double- spending detection.

[0008] Virtual currencies gained most prominence in the form of Bitcoin, attributed to Satoshi Nakamoto and implemented in 2009. Bitcoin is a networked and decentralized virtual currency system, in which there is no central authority such as a central bank or server: the networked users collectively embody the bank.

[0009] There are two main categories of networked users in the Bitcoin network, namely users with digital wallets, and bitcoin miners. To use the Bitcoin system, a user terminal is configured with a digital wallet used to send, receive and store Bitcoins. A user, whether a merchant or a purchaser, needs to generate a Bitcoin ® address to which bitcoins can be sent. The digital wallet generates an asymmetric key pair including a public key and a private key. A cryptographic hash of the public key is used as the user's Bitcoin address, which is publicised as a payment address. A hash of the public key, as opposed to the key itself, is used because a hash is much smaller (e.g., 256 bits) in length than a public key (e.g., a RSA public key is typically 2048 bits).

[00010] A user who wishes to transfer bitcoins to another user inputs the transfer amount and instructs their digital wallet to complete the electronic transaction. The digital wallet initiates a transaction and identifies the recipient using their Bitcoin ® address. The transaction format starts with a transaction identifier, which is a hash of the rest of the transaction data. The version number of the set of rules under which the transaction is to be evaluated follows this. This allows for the Bitcoin protocol rules to be updated and for different versions to coexist. The third and fourth fields of the format specify the number of inputs and outputs for the transaction. This is followed by the size of the transaction block in bytes. The actual details for each of the inputs and outputs for the transaction then follow. For example an output transaction would contain the number of bitcoins being paid to a third- party, along with the signature of the sender as well as their public key. It also contains the signature of the sender as well as their public key. The last entry is the only output for the transaction and consists of the value of the amount being transferred and the address of the recipient. The digital wallet digitally signs the transaction with the private key of the sender. Such a system is described in US patent publication number US2004/019571 (Hurwitz).

[00011 ] The transaction is then broadcast to all networked users on the Bitcoin ® network. The transaction can then be verified by any such networked user using the public key of the sender, to ensure that the transaction is legitimate and that the user spending the bitcoins is actually the owner of these coins. Bitcoin ® miners are the second category of Bitcoin ® networked users, and whose main task it is to try and be the first to verify a next transaction block. A transaction block consists of all transactions that have been broadcast on the Bitcoin network in the ten minutes preceding the transaction broadcast.

[00012] There is no requirement for mutual trust between users, or the need to employ two-phase commit protocols to verify transactions in the network: all Bitcoin transactions are stored in a public ledger known as the block chain. The block chain is a time stamped public ledger of all transactions that have ever been conducted in the Bitcoin network. The first block in the chain is known as the genesis block, and is followed by blocks that have been verified by bitcoin miners. Each new block contains one or more new transactions that have been received by the miner. These are repeatedly hashed in pairs to form a Merkel Tree. The root of the Merkel Tree along with the hash of the previous block is stored in the block header, thereby chaining all the blocks together. This ensures that a transaction cannot be modified without modifying the block that records it and all following blocks. This property of the block chain makes double spending of bitcoins very difficult.

[00013] Problematically, however, the data storage required for storing the block chain, and the corresponding amount of bandwidth required to transfer same within the Bitcoin network, scales in direct proportion to the number of transactions recorded therein, and has already reached a non-trivial level, only to grow further in years to come.

[00014] Furthermore, a problem inherent to the collective verification approach, is that a digital wallet user could theoretically attempt to defraud recipients by introducing a large number of nodes into the network that are controlled by that digital wallet user. Such nodes could then be made to reply to recipients, to the effect that the bitcoins given to them are legitimate, and thus defraud those recipients into accepting the transactions. The Bitcoin protocol employs the Hashcash "Proof-of-Work" concept to inhibit this problem. A cryptographic hash function, e.g. SHA-256, takes an arbitrary length input and produces a fixed length output. Hash functions are designed to be collision resistant wherein, for SHA- 256, this would require on average 2¹²⁸ or 4 x 10³⁸ attempts to find a collision, which is a near impossible task given current computational capabilities. Hashcash simplifies this requirement considerably by only looking for partial collisions, i.e. wherein a k-bit partial collision would be where only the first k most significant bits match. In practice, the Bitcoin proof-of-work approach requires the hash of a block's header to be lower than or equal to a number known as the target, a 256-bit number that all Bitcoin ® clients share. The SHA-256 hash of a transaction block's header must be lower than or equal to the current target for the block to be accepted by the network. The lower the target, the more difficult it is to generate a block. [00015] This approach is nevertheless particularly computing-intensive, to the extent that bitcoin miners, after repurposing graphical processing units (GPUs) to process hashes faster and with less energy requirements than central processing units (CPUs), have since taken to form syndicates for pooling computing resources, and whilst purpose-specific FPGA- based and more recently ASIC -based hardware has been developed, for instance as marketed by Buttefly Labs, Antminer, Bitfury and KFC.

[00016] An object of the present invention is to provide an alternative networked token exchange system which overcomes at least some of the above problems and disadvantages. Summary

[00017] The inventors have realised that both the significant storage requirements for a single electronic ledger of all digital transactions for all digital tokens and the computationally expensive proof-of-work implementation of the Bitcoin ® system can be mitigated by encoding a respective block chain in each digital token. The invention provides a technical encoding method and system such that a series of transaction blocks are stored directly in the token, and can be digitally signed by a remote server. Advantageously, this approach also allows each digital token to be re-used by successive users to whom it is transferred during its active life. [00018] A feature of the present invention is to prevent a large and unmanageable ledger which is both memory and bandwidth wasteful that is associated with the Netcoin protocol. To solve this problem the invention provides a system and method to move the 'blockchain' to a per token basis. This conveniently allows one to be able to remove tokens from the system that become too large in terms of the number of transactions that have been conducted.

[00019] The invention defines the 'blockchain' on a per token basis. Although there is a global ledger the system and method of the invention is able to control its size by limiting the size of the 'blockchain' associated with a token and removing tokens from the ledger that exceed a maximum system defined length. The system and method also dispenses with the concept of Proof of Work (PoW) and represents a significant improvement on prior art.

[00020] The system and method of the invention does not employ PoW in the Netcoin protocol for the reason given above. Unlike Bitcoin there is no first-to-the-post type competition in Netcoin. All the Mint operators independently verify the transaction and endorse it. It is then up to the Merchant to randomly select one of the responding Mints for reward.

[00021 ] It will be appreciated that in the context of the present invention the token is the means for the transfer of value in the blockchain. It is issued by any mint on receipt of fiat currency. In other words it exists for as long as the associated blockchain does not become too large at which point can be 'recalled' (like a banknote) and reissued. It will be further appreciated that upon widespread acceptance of Netcoin in the art Netcoin could be floated as an unpegged currency and considered a currency in its own right. Moreover the token system and method of the present invention can be applied to any virtual currency. [00022] Thus, according to an aspect of the present invention, a method of encoding one or more digital tokens exchanged within a peer-to-peer network is provided, wherein the network comprises a plurality of user terminals operated by respective users and a plurality of servers. For each user and server in the peer-to-peer network, the method comprises the step of instantiating a respective cryptographic key pair comprising at least one public key. For each user in the peer-to-peer network, the method comprises the steps of registering the respective at least one public key and a respective unique identifier with at least one server, and requesting instantiation of one or more digital tokens by the at least one server. The method then comprises the steps of instantiating one or more digital tokens at the at least one server, wherein the or each token comprises a plurality of codes defining a block chain, and digitally signing the or each token at the at least one server, based on the plurality of codes and a private key of the at least one server.

[00023] In an embodiment of the method, the plurality of codes may comprise a unique identifier of the at least one server, the respective unique identifier of a user, a code representative of the instantiation operation and a unique serial identifier of the token.

[00024] An embodiment of the method may comprise the further steps of broadcasting the or each digitally- signed token from the at least one server to a plurality of remote servers, each being adapted to register public keys and unique identifiers of users and to instantiate and digitally sign tokens, and storing the or each digitally- signed token at each of the plurality of remote servers.

[00025] An embodiment of the method may comprise the further step of transferring at least one instantiated token within the network from a first user to a remote second user. In a variant of this embodiment, the method may comprise the further step of replacing a code of the block chain of the or each transferred token with a hash of the previous bloc chain including the previous digital signature. The step of digitally signing the or each transferred token may then further comprise digitally signing the or each transferred token based on the plurality of codes including the hash and a private key of the first user.

[00026] In one embodiment the block chain comprises a series of transaction blocks stored on the token. [00027] A further variant may then comprise the further steps of broadcasting the or each digitally- signed transferred token from the remote second user to the plurality of servers and, at each server, processing the block chain of the transferred token and comparing the output with stored digitally-signed tokens for validating the transfer. [00028] In a preferred embodiment of the method, for the or each transferred token, the step of processing the block chain may further comprise computing a first hash of a plurality of codes of the stored token, concatenating the first hash with a plurality of codes of the transferred token, computing a second hash of the concatenated result, comparing the second hash with the hash contained in the digital signature associated with the transferred token, and instantiating an endorsed token and digitally signing same. An embodiment of the method may then comprise the further step of transferring the or each endorsed token from at least one server to the remote second user. [00029] Any embodiment of the method may usefully comprise the further step of re- instantiating a token when a data size of its bloc chain exceeds a predetermined threshold.

[00030] According to another aspect of the present invention, a digital token exchange system is provided, which comprises a peer-to-peer network having a plurality of user terminals operated by respective users and a plurality of servers; wherein each terminal is configured to instantiate a respective cryptographic key pair comprising at least one public key for its user, register the respective public key and a respective unique identifier of its user with at least one server, and request instantiation of one or more digital tokens by the at least one server; and wherein each server is configured to instantiate a respective cryptographic key pair comprising at least one public key, instantiate one or more digital tokens, wherein the or each token comprises a plurality of codes defining a block chain, and digitally sign the or each token based on the plurality of codes and a private key of the at least one server.

[00031 ] In an embodiment of the system, the plurality of codes may comprise a unique identifier of the at least one server, the respective unique identifier of a user, a code representative of the instantiation operation and a unique serial identifier of the token.

[00032] In an embodiment of the system, each server may be further configured to broadcast the or each digitally- signed token to a plurality of remote servers, each being adapted to register public keys and unique identifiers of users and to instantiate and digitally sign tokens, and store the or each digitally-signed token at each of the plurality of remote servers. [00033] In an embodiment of the system, each user terminal may be further configured to transfer at least one instantiated token within the network to a remote user terminal. In a variant of this embodiment, each user terminal and server may be further configured to replace a code of the block chain of the or each transferred token with a hash of the previous bloc chain including the previous digital signature. Each user terminal and server may usefully be further configured to digitally sign the or each transferred token based on the plurality of codes including the hash and a private key of the first user.

[00034] In still another variant, each user terminal may be further configured to broadcast the or each digitally- signed transferred token to the plurality of servers, and wherein each server is further configured to process the block chain of the transferred token and compare the output with stored digitally- signed tokens for validating the transfer.

[00035] In a preferred embodiment of the system, each server may be further configured to compute a first hash of a plurality of codes of the stored token, concatenate the first hash with a plurality of codes of the transferred token, compute a second hash of the concatenated result, compare the second hash with the hash contained in the digital signature associated with the transferred token, and instantiate an endorsed token and digitally signing same. In an embodiment of the system, each server may then be further configured to transfer the or each endorsed token from at least one server to the remote second user.

[00036] Any embodiment of the system may usefully comprise at least one server further configured to re-instantiate a token when a data size of its bloc chain exceeds a predetermined threshold.

[00037] According to a further aspect of the present invention, a computer program is provided, which comprises program instructions for causing a data processing terminal operably connected to a network to perform an embodiment of the method described herein, thus to instantiate an embodiment of the digital token exchange system described herein.

[00038] According to yet another aspect of the present invention, there is also provided a digital token encoded according to an embodiment of the method described herein, for use in an embodiment of the digital token exchange system described herein.

[00039] Other aspects of the invention are as set out in the appended claims. Brief Description of the Drawings

[00040] The invention will be more clearly understood from the following description of an embodiment thereof, given by way of example only, with reference to the accompanying drawings, in which:-

[00041 ] Figure 1 shows a networked computing environment including a plurality of data processing terminals communicating data, each including a set of instructions for embodying the token exchange system according to an embodiment of the present invention and wherein the terminals comprise user terminals and servers.

[00042] Figure 2 illustrates a typical hardware structure of data processing terminals shown in Figure 1.

[00043] Figure 3 illustrates the memory contents of each user terminal of Figures 1 and 2 at runtime, including a token application at runtime and token bloc chains.

[00044] Figure 4 illustrates the memory contents of each server of Figures 1 and 2 at runtime, including a token database application at runtime and token bloc chains. [00045] Figure 5 details data processing steps performed by either user terminal of Figures 1 to 3 in networked connection with the servers, for instantiating and exchanging digital tokens according to an embodiment of the present invention.

[00046] Figure 6 details data processing steps performed by either server of Figures 1, 2 and 4 in networked connection with the user terminals, for instantiating and exchanging digital tokens according to an embodiment of the present invention, including a step of comparing digital tokens.

[00047] Figure 7 further details data processing sub-steps of the digital token comparing step of Figure 6.

[00048] Figure 8 illustrates a plurality of codes constituting the bloc chain of a digital token over the course of several exchanges, when processed according to the data processing steps of Figures 5 to 7. Detailed Description of the Drawings

[00049] There will now be described by way of example a specific mode contemplated by the inventors. In the following description numerous specific details are set forth in order to provide a thorough understanding. It will be apparent however, to one skilled in the art, that the present invention may be practiced without limitation to these specific details. In other instances, well known methods and structures have not been described in detail so as not to unnecessarily obscure the description.

[00050] The words "comprises/comprising" and the words "having/including" when used herein with reference to the present invention are used to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

[00051 ] Referring now to the figures and initially Figure 1, there is shown a network environment in which several data processing terminals 101, 102, 103 A, 103B are connected to one another over a Wide Area Network (WAN) 104, in the example the Internet.

[00052] Data processing terminal 101 is a mobile communication device which receives or emits data, including voice and/or text data, encoded as a digital signal over a wireless data transmission 105, wherein said signal is relayed respectively to or from the device 101 by the geographically-closest communication link relay 106 of a plurality thereof. The plurality of communication link relays 106N allows digital signals to be routed between mobile devices 101 and their intended recipient by means of a remote gateway 107. Gateway 107 is for instance a communication network switch, which couples 110 digital signal traffic between wireless telecommunication networks, such as the network within which wireless data transmissions 105 take place, and the WAN 104. The gateway 107 further provides protocol conversion if required, for instance if the device 101 uses a Wireless Application Protocol ('WAP') or Secure Hypertext Transfer Protocol ('HTTPS') to communicate data. [00053] Data processing terminal 102 is a mobile tablet - format device which receives or emits data encoded as a digital signal over a wireless data transmission 108, wherein said signal is related respectively to or from the computer 102 by a local wireless router 109 operating according to the 802.11 wireless transmission protocol ('WiFi'). The router 109 is itself connected to the WAN 104 via a conventional ADSL or optical fibre connection over a wired telecommunication network 110.

[00054] Data processing terminals 103A and 103B are respective personal computers connected to the WAN 105 substantially as described in connection with devices 101, 102, however wherein a wired connection 111 to their respective routers 109 is preferred so as to maximise data communication bandwidth in the network

[00055] In the environment of Figure 1 therefore, the respective user of each terminal 101, 102 therefore has the use of a networked data processing device configured to receive and communicate digital token data encoded as a digital signal over a wireless data transmission, respectively from and to either or both of the terminals 103A, 103B.

[00056] A typical hardware architecture of either of the networking devices 101, 102 is shown in Figure 2 in further detail, by way of non-limitative example. The mobile phone 101 and the tablet device 102 each include a data processing unit 201, for instance a general- purpose microprocessor, acting as the main controller of the data processing terminal and which is coupled with memory means 202, comprising volatile random-access memory (RAM), non-volatile random-access memory (NVRAM) or a combination thereof.

[00057] Each device further includes networking means. Communication functionality in mobile phone 101 is provided by a modem 203, which provides the interface to external communication systems, such as the GPRS, 3G or 4G cellular telephone network 106, 107 shown in Figure 1, associated with or containing an analogue-to-digital converter 204, which receives an analogue waveform signal through an aerial 205 from the communication link relay 106 and processes same into digital data with the data processing unit 201 or a dedicated signal processing unit. Communication functionality in tablet device 102 is provided by a wireless network interface card (WNIC) 206 interfacing the tablet device 102 with the wireless local area network generated by router 109, and/or likewise by a 3G or 4G modem 203 as described above.

[00058] The CPU 201, NVRAM 202 and networking means 203 to 206 are connected by a data input/output bus 207, over which they communicate and to which further components of each device 101, 102 are similarly connected in order to provide wireless communication functionality and receive user interrupts, inputs and configuration data.

[00059] Accordingly, user input may be received from a data input interface 208, which for mobile phone 101 is a keypad with a limited number of multi-functional keys and/or a capacitive or resistive touch screen feature of the display unit 209 and, for tablet device 102, is a capacitive or resistive touch screen feature of the display unit 209.

[00060] Further input data may be received as analogue sound wave data by a microphone 210, digital image data by a digital camera lens 211 and digital data via a Universal Serial Bus (USB) 212. Processed data is output as one or both of display data output to the display unit 209 and audio data output to a speaker unit 213.

[00061 ] Power is supplied to the above components by the electrical circuit 214 of devices 101, 102, which is interfaced with an internal battery module 215, which itself may be recharged on an ad hoc basis by an electrical converter 216.

[00062] The terminals 103 A, 103B are referred to as servers herein to facilitate understanding and, in a typical embodiment, each will comprise a desktop computer, which not described herein so as not to obscure the present description unnecessarily. Moreover, it will be readily understood from the foregoing that either or both of the terminals 103 A, 103B may comprise a wireless networked data processing device similar to that described with reference to Figure 2 above, instead of a desktop computer. [00063] With reference generally to Figures 3 to 8 hereafter, in the digital token exchange system of the invention, the data processing terminals configured as servers 103 A, 103B are configured as digital token creating and validating entities. Each server 103A, 103B has a cryptographic key pair comprising both a public key and a private key. The public key is publicised and known in the system. Each user terminal 101, 102 generates its own cryptographic key pair and registers the public key component and a user identifier of its user with at least one server 103 A, 103B in the system. A user must first obtain digital tokens, which must be instantiated by a server 103A, 103B, before tokens can be exchanged. A user terminal 101, 102 accordingly contacts a server 103 A, 103B to instantiate one or more digital tokens, optionally against payment via an electronic funds transfer (EFT) process. The server 103 A, 103B will then accordingly generate one or more digital tokens. Each instantiated digital token comprises a starting block chain entry 801 which uniquely associates the digital token to the requesting user terminal e.g. 101. The starting block chain has four fields, including user identifier fields, a transaction type field, a token serial number initially, and a digital signature performed on all the four fields with a private key of the server 103 A.

[00064] At a later time, when a user operating a user terminal 101 tries to exchange one or more digital tokens with another user operating a remote user terminal 102, , which like before contains the user identifier fields and the type of transaction field. When a digital is exchanged between two users, it is the first terminal (101) that creates the new block chain entry (802). The serial number is however replaced with a hash of the previous block chain codes 801. This links the previous token transaction to the current transaction, thereby creating a chain of transactions. The final field of the second block chain entry 802 is again a digital signature on all the above fields by the first terminal 101. The second user terminal 102 then broadcasts the new version of the digital token block chains 802 to all servers 103 A, 103B in the system with a token endorsement request, to verify the legitimacy of the digital token(s).

[00065] Each server 103 A, 103B in the system maintains a respective token database and processes the endorsement request against same to ensure that the digital tokens actually belong to the user terminal 101 that initiated the exchange. Provided the checking operation returns a match, each server 103A, 103B creates a third block chain entry 803, substantially as a signed endorsement to the second digital token block chain 802 with its private key, and communicates the endorsed token back to the second, recipient user terminal 102. This process is performed substantially in real-time and almost instantaneously, because there is no 'proof-of-work' computations to perform.

[00066] The second user terminal 102 receives the endorsed token from each server 103A, 103B and elects one at random, wherein the elected server e.g. 103B may optionally be rewarded for the validation, in which case a fourth block chain entry 804 is be created at the second user terminal 102 as a reward block chain 804, by signing the third digital token block chain 803 with the private key of the second user terminal 102, and communicating the reward token back to all servers 103 A, 103B, as a public acknowledgement of the fact that the first user 101 has exchanged the digital token 801 with the second user 102 and that the server 103B that helped endorse the digital token 802 is the beneficiary of a reward 804 from the second user 102. The servers 103 A, 103B then update their respective database to reflect the latest version of the digital token. This broadcast mechanism maintains a distributed and resilient record of all digital tokens in the system and to which user 101, 102 they belong at any point in time.

[00067] Accordingly, with reference now to Figure 3, a logical diagram shows the contents of the memory means 202 of either data processing terminal 101, 102 at runtime, when the terminal is configured to request, obtain and exchange digital tokens according to the present invention.

[00068] An operating system is shown at 301 which, if the device 101 is for instance an iPhone® mobile phone handset manufactured by Apple® Inc. of Sunnyvale, California, or if the device 102 is for instance an iPad® tablet computer likewise manufactured by Apple® Inc., is iOS® likewise distributed by Apple® Inc. The OS 301 includes communication subroutines 302B to configure the data processing terminal for bilateral network communication via the modem 203 and NIC 206.

[00069] A digital token exchange application is shown at 303, which configures the terminal 101, 102 to perform data processing steps described hereafter with reference to Figure 5, which embody a method of exchanging digital tokens in a peer-to-peer network. The application 303 is interfaced with the OS 301, particularly subroutines 302A of the OS reading and processing the two-dimensional user input to the touchscreen interface 209, and the network communication subroutines 302B of the OS, via one or more suitable Application Programmer Interfaces.

[00070] An application user interface (UI) is shown at 304, which the application 303 outputs to the VDU 209 and in which the application 303 renders digital token-related data and communication requests and replies with remote user terminal 102, servers 103A, 103B, and reads two-dimensional X, Y user input effecting selections therein on the touchscreen interface or digitizer via the relevant OS subroutine 302A.

[00071 ] When a user first installs the application 303 on a terminal e.g. 101, a cryptographic module 305 of the application 303 generates a cryptographic key pair, comprising a public key 306i and a private key 307i, and associates the key pair with a unique user identifier 3081 of the terminal user 101. On any next subsequent running of the application 303, the module 305 verifies the key pair 306, 307 and user ID 308 and maintains same in memory at runtime.

[00072] The application 303 data further comprises digital tokens 309N instantiated by one or each of remote servers 103 A, 103B, subsequently endorsed by both remote servers 103A, 103B, and exchanged with at least one other user terminal e.g. 102 such that the application 303 data also includes a dataset 310 comprising the respective remote user ID 308₂ and the respective public key 306₂ of the remote user terminal 102 involved in the exchange.

[00073] The application 303 also is interfaced, via a token API 311, with other applications 312 that may require use of the digital token exchange system of the invention at runtime, for instance a browser application in which e.g. the website of the remote user operating user terminal 102 offering goods and/or services can be accessed, and in respect of which digital tokens 309 may be exchanged as described herein, or a repository application in which new applications and/or digital multimedia data can be selected for installation on the terminal 101 and in respect of which digital tokens 309 may again be exchanged as described herein.

[00074] Further local data 313 and network data 314 may be stored in the memory means 202 of the data processing terminal 101, 102 at runtime, some or all of which may be processed either by the application 303 or by or for another application 312 being processed in parallel with application 303. An example of further local data is for instance local user input 311 read by the OS 301 in real time from the hardware interface 209, but which user input lies outside the user interface 304 of the application 303. An example of further network data is for instance remote application updating data 314 communicated by the remote server 103 over the WAN 104.

[00075] With reference now to Figure 4 now, and by contrast with Figure 3, a logical diagram shows the contents of the memory means 202 of either server 103 A, 103B at runtime, when the terminal is configured to instantiate and endorse digital tokens according to the present invention. [00076] A digital token exchange database application is shown at 403, which configures the server 103A, 103B to perform data processing steps described hereafter with reference to Figures 6 and 7, which embody a method of exchanging digital tokens in a peer- to-peer network. The application 403 is again interfaced with the OS 301, particularly network communication subroutines 302B of the OS, via one or more suitable Application Programmer Interfaces.

[00077] When a user first installs the application 403 on a server terminal e.g. 103A, the cryptographic module 305 of the application 403 generates a cryptographic key pair, comprising a public key 306si and a private key 307si, and associates the key pair with a unique server identifier 308si of the server 103A, in the manner done for user terminals 101, 102. On any next subsequent running of the application 403, the module 305 verifies the key pair 306, 307 and user ID 308 and maintains same in memory at runtime.

[00078] The database application 403 data further comprises digital token requests 410N received from one or each of remote user terminals 101, 102, subsequently processed for instantiating digital tokens 309, such that each request 41 ON includes a dataset comprising the respective remote user ID 308N and the respective public key 306N of the remote user terminal 102, 103 that has issued that instantiation request.

[00079] The database application 403 data further comprises a token database 412. The database 412 is adapted to store registered user identifiers 308N with their respective user public key 306 N and, for each digital token 309, a plurality of data fields 811, 813, 815, 817, 819 in which to respectively store the several codes composing the block chain 801-801N of the token 309 and comprising, in this embodiment: a network origin identifier code, in the example a user ID or server ID 308N; a network destination identifier code, in the example again a user ID or server ID 308N; a transaction code, in the example representing either an instantiation (INST), or a transfer (TX), or an endorsement (ED), or a reward (RD); a token unique identifier populated with a unique serial number at token instantiation and thereafter populated with a hash of the preceding version e.g. 801 of the block chain e.g. 802; and finally a digital signature. [00080] The digital token block chain 801 is based around an individual digital token 309 in the system, under the reasoning that having a block chain per digital token unit removes the need for an ever-growing ledger of transactions in the system: if the block chain for a particular digital token 309 grows beyond a certain data size or length, a server 103 A or 103B can easily removed the digital token 309 from the system and instantiate a new digital token with a new 'starting' block chain 801 in its place. All transactions in the digital token block chain remain linked by including a hash 802 of the previous transaction 80 IN therein, thereby preventing unauthorised changes to the digital token transaction list. [00081 ] Accordingly, at any one time during use, and in accordance with principles described herein, the database 412 comprises data records 414 representative of tokens 309 instantiated locally by the database application 403, data records 416 representative of tokens 309 instantiated remotely by the database application 403 running at a remote server e.g. 103B, data records 418 representative of transferred tokens 309 exchanged between users operating respective remote terminals 101 , 102, and data records 420 representative of endorsed tokens 309 corresponding to transferred tokens 309 successfully processed by the database application 403 to validate the exchange. It will be appreciated that the system and method of the invention can provide separate storage for different types of digital tokens. A single or a plurality of databases can be used to store the digital tokens.

[00082] Further local data 424 and network data 426 may be stored in the memory means 202 of the data processing terminal 103 A, 103B at runtime, some or all of which may be processed either by the database application 403 or by or for another application 422 being processed in parallel with database application 403. An example of further local data is for instance local user input 424 read by the OS 301 in real time from a hardware interface, e.g. a mouse or keyboard input device. An example of further network data is for instance remote application updating data 426 downloaded by the server 103 A over the WAN 104.

[00083] With reference to Figures 5 to 8 now, after powering up a user terminal 101 , 102 at step 501 , and optionally accessing and downloading the digital token exchange 303 from one of the remote servers 103 A, 103B across the network described in Figure 1 , the digital token exchange application 303 is started locally at step 502 and the user interface 304 instantiated on the VDU 209 at step 503. A first question is asked at step 504, as to whether the starting of the application at step 502 is the first such start. The question may for instance be answered by polling the cryptographic module 305 for a key pair 306, 307 and a user ID 308, which do not yet exist if the user has never used the digital token exchange application 303 heretofore. [00084] Accordingly, if the question of step 504 is answered positively, then at step 505, the cryptographic module 305 generates a key pair 306, 307 and a user ID 308, then the user next registers, via the application 303 across the network, at either server 103A or 103B for instantiating one or more digital tokens 309 at step 506. [00085] After step 506, or alternatively if the question of step 504 is answered negatively, control proceeds to a next question at step 507, as to whether the user has input a network request for instantiation of one or more tokens in the UI 304. If the question of step 507 is answered positively, then at step 508 the application 303 communicates a token instantiation request to the remote server 103 A or 103B with which the user has registered at step 506. Accordingly, one or more digital tokens 309 are eventually received by the application 303 at the user terminal 101 at step 509.

[00086] After step 509, or alternatively if the question of step 507 is answered negatively, control proceeds to a next question at step 510, as to whether the user has received a digital token from a remote user terminal e.g. 102 across the network. If the question of step 510 is answered positively, then at step 511 the token block chain is processed and generates a next block chain based on the respective user identifiers 3081, 308₂ of the token recipient and the token sender, which it then broadcasts to all the servers 103 A, 103B of the network at step 512 for endorsement. It will be appreciated that the new entry in the block chain is created by the initiator of the transaction. The application eventually receives an endorsed token from each of the servers 103 A, 103B of the network at step 513 and elects one therefrom.

[00087] After step 513, or alternatively if the question of step 510 is answered negatively, control proceeds to a next question at step 514, as to whether the user has input a network request for exchanging one or more tokens with another user in the UI 304. If the question of step 514 is answered positively, then at step 515 the application 303 processes the token block chain and generates a next block chain based on the respective user identifiers 3081, 308₂ of the token sender and the token recipient, which it then sends to the remote application 303 of the remote recipient user terminal 102, at which it will be processed according to steps 510 to 513.

[00088] Alternatively, the question of step 514 is answered negatively, whereby a final question is asked at step 516, as to whether the user has input an application closing command in the UI 304. If the question of step 516 is answered negatively, then the application logic loops and control returns to the question of step 507. Alternatively, the application 303 is unloaded from the memory 202 and the user terminal 101 may eventually be switched off. [00089] With reference to Figures 5 to 8 still, after powering up a server 103 A, 103B at step 601, and optionally accessing and downloading the digital token exchange database application 403 from another remote server across the network described in Figure 1, the digital token exchange database application 403 is started locally at step 602 and a user interface 404 is instantiated on the server VDU at step 603. A first question is asked at step 604, as to whether the starting of the application 403 at step 602 is the first such start. The question may for instance be answered by polling the cryptographic module 305 for a key pair 306, 307 and a server ID 408, which do not yet exist if the server has never processed the digital token exchange database application 403 heretofore. [00090] Accordingly, if the question of step 604 is answered positively, then at step 605, the cryptographic module 305 generates a key pair 306, 307 and a server ID 408, then the server next instantiates a digital token database 412 at step 606. The database is instantiated to store user identifiers 308N with respective user public keys 306 N and, for each digital token 309₄i4-*2o, a plurality of data fields in which to store the codes of token block chain comprising, in this embodiment, a network origin identifier code field 811, a network destination identifier field code 813, a transaction code field 815, a token unique identifier code 817 populated with a unique serial number at token instantiation and thereafter populated with a hash , and a digital signature field 819. [00091 ] After step 606, or alternatively if the question of step 604 is answered negatively, control proceeds to a next question at step 607, as to whether the server has received a network request 410 for instantiation of one or more tokens. If the question of step 607 is answered positively, then at step 608 the database application 403 receives the public key 306 and the user ID 308 with the request from the requesting terminal and updates the database 412 with one or more new tokens 414, which it then instantiates at step 609, by populating the respective fields of each new token database entry with a plurality of codes 811 to 819, by way of example in the form shown at the top of Figure 8. The application 403 digitally signs each new token with its private key 407 wherein the digital signature is recorded in the database field 819 for each such instantiated token 414. The application lastly broadcasts data representative of the newly-instantiated token(s) 414 to all other remote servers 103B in the network, at each of which it is received as a remotely instantiated token 416 and the subject of a local database update as a corresponding new entry and recordal therein.

[00092] After step 609, or alternatively if the question of step 607 is answered negatively, control proceeds to a next question at step 610, as to whether the server has received a digital token exchange notice 418 from a remote user terminal e.g. 102 across the network. If the question of step 610 is answered positively, then at step 611 the application 403 processes the token block chain 418 and, subject to a comparison between data of the exchanged token received at step 610 and data of the database entry for that token of step 609 returning a match or not, a decision to endorse the exchanged token or to broadcast a warning is taken at step 612, whereby the application 403 either generates a next block chain 420 based on the respective unique identifiers 4081, 308₂ of the server and the token recipient, which it then communicates back to the notifying user terminal 102 as en endorsed token at step 613, or generates a warning about the exchanged token which it then communicates back to the notifying user terminal 102 at said step 613.

[00093] With reference to Figure 7, the processing step 611 begins with hashing the fields 811, 813, 815, 817 and 819 of the previous version 801 (T-i) of the digital token 309 that it has stored in its database 412 at step 701 then, at a next step 702, concatenating the hash with the first three fields 811, 813, 815of the queried version 802 (To) of the digital token 309 that it has identified at step 610. The result of the concatenated result is then hashed (Hi) at step 703.

[00094] The database application 403 then tries to match the computed hash (Hi) with the hash (H₂) contained within the digital signature 819 associated with the queried version 802 (To) of the digital token 309 to endorse. The database application 403 thus extracts the contents of the first field 811 identifying the endorsement request initiator e.g. 102 of the exchange at step 704 and obtains the public key 306₂ of the initiator 102 at step 705 by using the extracted contents as an index into the database 412 of public keys 306. The database application 403 next extracts the hash the (H₂) contained within the digital signature 819 associated with the queried version 802 (To) of the digital token 309 to endorse at step 706 and, at a next step 707, attempts a match of the two hashes (Hi, H₂). If there is a match, then the database application 403 assumes the exchange is valid at step 612 and adds a further 'endorsement' entry (ED) into the digital token block chain using the endorsement field 815. It will be appreciated that in one embodiment a digital signature is the encryption of a hash computed on a number of fields and then encrypted with the private key of the sender. To reverse this transaction one applies the public key to obtain the original hash. One then independently computes a hash over the same fields and then compares the two quantities. If they are exactly same bit for bit then one has a good digital signature

[00095] In a further embodiment also shown in Figure 6, after step 613, or alternatively if the question of step 610 is answered negatively, control proceeds to a next question at step 614, as to whether the server 103 A has received a reward token notification from a remote user terminal 101, 102, which in this embodiment occurs whenever a recipient user terminal 101, 102 receives an endorsed token according to steps 611 to 613. If the question of step 614 is answered positively, then at step 615 the data record for the token the subject of the reward is updated in the database 412.

[00096] After step 615, or alternatively if the question of step 614 is answered negatively, a final question is asked at step 616, as to whether the user of the server 103 A has input an application closing command in the UI 404. If the question of step 616 is answered negatively, then the application logic loops and control returns to the question of step 607. Alternatively, the application 403 is unloaded from the terminal memory and the server 103 A may eventually be switched off.

[00097] The present invention thus provides a fast and simple token exchange system, in which security is inherent to the distributed mechanisms maintaining the integrity and validity of the digital tokens in the system. The broadcast mechanism described herein between networked terminals, some of which configured as instantiating and endorsing servers are trusted, effectively enlists the help of multiple entities to verify transactions but, unlike prior art systems, does not use or require a computationally-intensive process such as the proof-of-work algorithm to validate token exchanges. Since the token data structure in the system is transaction-based and updated iteratively, all digital token transactions are continually reusable until a block chain data size may require the deletion and re-instantiation of a token, and moreover broadcast to the entire network, whereby it is not be possible to double-spend digital tokens in the system as, unlike prior art systems, each token data structure inherently implements full traceability for that token, which is a major deterrent to abuse such as money-laundering, smuggling and other nefarious activity.

[00098] The embodiments in the invention described with reference to the drawings comprise a computer apparatus and/or processes performed in a computer apparatus. However, the invention also extends to computer programs, particularly computer programs stored on or in a carrier adapted to bring the invention into practice. The program may be in the form of source code, object code, or a code intermediate source and object code, such as in partially compiled form or in any other form suitable for use in the implementation of the method according to the invention. The carrier may comprise a storage medium such as ROM, e.g. CD ROM, or magnetic recording medium, e.g. a memory stick or hard disk. The carrier may be an electrical or optical signal which may be transmitted via an electrical or an optical cable or by radio or other means. [00099] In the specification the terms "comprise, comprises, comprised and comprising" or any variation thereof and the terms include, includes, included and including" or any variation thereof are considered to be totally interchangeable and they should all be afforded the widest possible interpretation and vice versa. [000100] The invention is not limited to the embodiments hereinbefore described but may be varied in both construction and detail.

Claims

1. A method of encoding one or more digital tokens exchanged within a peer-to-peer network, wherein the network comprises a plurality of user terminals operated by respective users and a plurality of servers, the method comprising the steps of:

for each user and server in the peer-to-peer network, instantiating a respective cryptographic key pair comprising at least one public key;

for each user in the peer-to-peer network,

registering the respective at least one public key and a respective unique identifier with at least one server, and

requesting instantiation of one or more digital tokens by the at least one server; and at the at least one server,

instantiating one or more digital tokens at the at least one server, wherein the or each token comprises a plurality of codes defining a block chain, wherein the block chain comprises a series of transaction blocks stored on the token, and

digitally signing the or each token based on the plurality of codes and a private key of the at least one server.

2. A method according to claim 1, wherein the plurality of codes comprises a unique identifier of the at least one server, the respective unique identifier of a user, a code representative of the instantiation operation and a unique serial identifier of the token.

3. A method according to claim 1 or 2, comprising the further steps of

broadcasting the or each digitally-signed token from the at least one server to a plurality of remote servers, each being adapted to register public keys and unique identifiers of users and to instantiate and digitally sign tokens, and

storing the or each digitally-signed token at each of the plurality of remote servers.

4. A method according to any of claims 1 to 3, comprising the further step of transferring at least one instantiated token within the network from a first user to a remote second user.

5. A method according to claim 4, comprising the further step of replacing a code of the block chain of the or each transferred token with a hash of the previous block chain including the previous digital signature.

6. A method according to claim 5, wherein the step of digitally signing the or each transferred token further comprises digitally signing the or each transferred token based on the plurality of codes including the hash and a private key of the first user.

7. A method according to claim 6, comprising the further steps of

broadcasting the or each digitally- signed transferred token from the remote second user to the plurality of servers; and

at each server, processing the block chain of the transferred token and comparing the output with stored digitally-signed tokens for validating the transfer.

8. A method according to claim 7 wherein, for the each or each transferred token, the step of processing the block chain further comprises

computing a first hash of a plurality of codes of the stored token;

concatenating the first hash with a plurality of codes of the transferred token;

computing a second hash of the concatenated result;

comparing the second hash with the hash contained in the digital signature associated with the transferred token; and

instantiating an endorsed token and digitally signing same.

9. A method according to claim 8, comprising the further step of transferring the or each endorsed token from at least one server to the remote second user.

10. A method according to any of claims 1 to 9, comprising the further step of re- instantiating a token when a data size of its bloc chain exceeds a predetermined threshold.

11. A digital token exchange system, comprising:

a peer-to-peer network having a plurality of user terminals operated by respective users and a plurality of servers;

wherein each terminal is configured to

instantiate a respective cryptographic key pair comprising at least one public key for its user,

register the respective public key and a respective unique identifier of its user with at least one server, and

request instantiation of one or more digital tokens by the at least one server; and wherein each server is configured to

instantiate a respective cryptographic key pair comprising at least one public key instantiate one or more digital tokens, wherein the or each token comprises a plurality of codes defining a block chain wherein the block chain comprises a series of transaction blocks stored on the token, and

digitally sign the or each token based on the plurality of codes and a private key of the at least one server.

12. A system according to claim 11, wherein the plurality of codes comprises a unique identifier of the at least one server, the respective unique identifier of a user, a code representative of the instantiation operation and a unique serial identifier of the token.

13. A system according to claim 11 or 12, wherein each server is further configured to broadcast the or each digitally- signed token to a plurality of remote servers, each being adapted to register public keys and unique identifiers of users and to instantiate and digitally sign tokens, and

store the or each digitally- signed token at each of the plurality of remote servers.

14. A system according to any of claims 11 to 13, wherein each user terminal is further configured to transfer at least one instantiated token within the network to a remote user terminal.

15. A system according to claim 14, wherein each user terminal and server is further configured to replace a code of the block chain of the or each transferred token with a hash of the previous block chain including the previous digital signature

16. A system according to claim 15, wherein each user terminal and server is further configured to digitally sign the or each transferred token based on the plurality of codes including the hash and a private key of the first user.

17. A system according to claim 16, wherein each user terminal is further configured to broadcast the or each digitally- signed transferred token to the plurality of servers, and wherein each server is further configured to process the block chain of the transferred token and compare the output with stored digitally- signed tokens for validating the transfer.

18. A system according to claim 17, wherein each server is further configured to compute a first hash of a plurality of codes of the stored token;

concatenate the first hash with a plurality of codes of the transferred token;

compute a second hash of the concatenated result;

compare the second hash with the hash contained in the digital signature associated with the transferred token; and

instantiate an endorsed token and digitally signing same.

19. A system according to claim 18, wherein each server is further configured to transfer the or each endorsed token from at least one server to the remote second user.

20. A system according to any of claims 11 to 19, wherein at least one server is further configured to re-instantiate a token when a data size of its block chain exceeds a predetermined threshold.

21. A computer program product comprising program instructions for causing a data processing terminal operably connected to a network according to any of claims 11 to 20 to perform the method of any of claims 1 to 10.

22. A digital token for use with the method of any of claims 1 to 10 and/or the network of any of claims 11 to 20.