WO2016202952A1 - Système d'échange de jetons numériques - Google Patents

Système d'échange de jetons numériques Download PDF

Info

Publication number
WO2016202952A1
WO2016202952A1 PCT/EP2016/063948 EP2016063948W WO2016202952A1 WO 2016202952 A1 WO2016202952 A1 WO 2016202952A1 EP 2016063948 W EP2016063948 W EP 2016063948W WO 2016202952 A1 WO2016202952 A1 WO 2016202952A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
server
user
digital
hash
Prior art date
Application number
PCT/EP2016/063948
Other languages
English (en)
Inventor
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 (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by The Provost, Fellows, Foundation Scholars, & The Other Members Of Board, Of The College Of The Holy & Undiv. Trinity Of Queen Elizabeth, Near Dublin filed Critical The Provost, Fellows, Foundation Scholars, & The Other Members Of Board, Of The College Of The Holy & Undiv. Trinity Of Queen Elizabeth, Near Dublin
Publication of WO2016202952A1 publication Critical patent/WO2016202952A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/381—Currency conversion

Definitions

  • 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.
  • 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.
  • the blinding factor was a random number used to obfuscate the serial number of the electronic coin from the bank.
  • 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).
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 128 or 4 x 10 38 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.
  • 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.
  • 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
  • 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.
  • this approach also allows each digital token to be re-used by successive users to whom it is transferred during its active life.
  • 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.
  • 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.
  • 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.
  • PoW Proof of Work
  • 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.
  • 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.
  • a method of encoding one or more digital tokens exchanged within a peer-to-peer network comprisin the network comprises a plurality of user terminals operated by respective users and a plurality of servers.
  • the method comprises the step of instantiating a respective cryptographic key pair comprising at least one public key.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the block chain comprises a series of transaction blocks stored on the token.
  • 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.
  • 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.
  • 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.
  • a digital token exchange system 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.
  • 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.
  • 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.
  • each user terminal may be further configured to transfer at least one instantiated token within the network to a remote user terminal.
  • 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.
  • 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.
  • 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.
  • each server may then be further configured to transfer the or each endorsed token from at least one server to the remote second user.
  • 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.
  • a computer program 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.
  • 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.
  • Figure 2 illustrates a typical hardware structure of data processing terminals shown in Figure 1.
  • 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.
  • 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.
  • 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.
  • 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.
  • Figure 7 further details data processing sub-steps of the digital token comparing step of Figure 6.
  • 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
  • FIG. 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.
  • WAN Wide Area Network
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • RAM volatile random-access memory
  • NVRAM non-volatile random-access memory
  • 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.
  • WNIC wireless network interface card
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • EFT electronic funds transfer
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • An application user interface 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.
  • a cryptographic module 305 of the application 303 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.
  • 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 2 and the respective public key 306 2 of the remote user terminal 102 involved in the exchange.
  • 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.
  • a token API 311 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.
  • 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.
  • FIG. 4 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.
  • 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.
  • the cryptographic module 305 of the application 403 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step 509 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 2 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.
  • step 513 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 2 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.
  • step 514 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.
  • 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 4 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.
  • step 606 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.
  • step 609 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.
  • 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 2 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.
  • 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.
  • the database application 403 then tries to match the computed hash (Hi) with the hash (H 2 ) 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 2 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 2 ) 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 2 ). 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.
  • 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
  • step 613 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.
  • 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.
  • 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.
  • each 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.
  • the embodiments in the invention described with reference to the drawings comprise a computer apparatus and/or processes performed in a computer apparatus.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un système d'échange de jetons numériques et un procédé de codage d'un ou plusieurs jetons numériques échangés au sein du système en question, le système comportant un réseau de poste à poste doté d'une pluralité de terminaux d'utilisateurs exploités par des utilisateurs respectifs et une pluralité de serveurs. Une paire de clés cryptographiques respectives comportant au moins une clé publique est instanciée pour chaque utilisateur et serveur dans le système. Chaque utilisateur dans le système inscrit sa clé publique respective et un identifiant unique respectif auprès d'au moins un serveur, et demande l'instanciation d'un ou plusieurs jetons numériques par le serveur en question. Un ou plusieurs jetons numériques sont instanciés au niveau du serveur, le ou chaque jeton comportant une pluralité de codes définissant une chaîne de blocs, la chaîne de blocs comportant une série de blocs de transactions stockés sur le jeton. Le serveur signe numériquement le ou chaque jeton d'après la pluralité de codes avec sa clé privée.
PCT/EP2016/063948 2015-06-16 2016-06-16 Système d'échange de jetons numériques WO2016202952A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1510528.1 2015-06-16
GB1510528.1A GB2539430A (en) 2015-06-16 2015-06-16 Digital token exchange system

Publications (1)

Publication Number Publication Date
WO2016202952A1 true WO2016202952A1 (fr) 2016-12-22

Family

ID=53784794

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/063948 WO2016202952A1 (fr) 2015-06-16 2016-06-16 Système d'échange de jetons numériques

Country Status (2)

Country Link
GB (1) GB2539430A (fr)
WO (1) WO2016202952A1 (fr)

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3062499A1 (fr) * 2017-02-02 2018-08-03 Ingenico Group Procede de reduction de la taille d'une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant
WO2018223125A1 (fr) * 2017-06-02 2018-12-06 Visa International Service Association Procédés et systèmes de vérification de propriété à l'aide d'une chaîne de blocs
CN109391619A (zh) * 2018-10-22 2019-02-26 昧来网络科技（上海）有限公司 基于权限的跨链通证交换方法及计算机可读介质
CN109525648A (zh) * 2018-10-26 2019-03-26 全链通有限公司 区块链共识机制、设备及计算机可读存储介质
WO2019147736A1 (fr) * 2018-01-23 2019-08-01 Iannaccone Philip Michael Système et procédé pour une transmission de données sécurisée
KR20190090832A (ko) * 2017-04-28 2019-08-02 알리바바 그룹 홀딩 리미티드 합의 검증 방법 및 디바이스
CN110445612A (zh) * 2018-05-02 2019-11-12 万事达卡国际公司 用于经由区块链增强登录凭证安全性的方法和系统
JP2020014193A (ja) * 2018-05-07 2020-01-23 ブロードリッジ・ファイナンシャル・ソリューションズ・インコーポレイテッドＢｒｏａｄｒｉｄｇｅ Ｆｉｎａｎｃｉａｌ Ｓｏｌｕｔｉｏｎｓ， Ｉｎｃ． 暗号学的に保護されたトークンベースの代替管理を行うためのコンピュータネットワークシステム、および当該システムを利用する方法
CN111461468A (zh) * 2019-01-02 2020-07-28 中国移动通信有限公司研究院 数据处理方法及装置、数据节点及存储介质
US10880072B2 (en) * 2018-06-20 2020-12-29 Verizon Patent And Licensing Inc. Systems and methods for controlled random endorsement in a blockchain network
CN113728351A (zh) * 2019-02-20 2021-11-30 恩佩弗尼集团 区块链系统中的可信通证化交易
US20220029810A1 (en) * 2019-03-01 2022-01-27 Capital One Services, Llc Identity and electronic signature verification in blockchain
WO2022089518A1 (fr) * 2020-10-31 2022-05-05 华为技术有限公司 Procédé de génération d'adresse, procédé de traitement d'informations de chaîne de blocs, et dispositif associé
US11403628B2 (en) 2017-10-20 2022-08-02 Hewlett Packard Enterprise Development Lp Authenticating and paying for services using blockchain
US11431477B2 (en) 2018-05-14 2022-08-30 nChain Holdings Limited Computer-implemented systems and methods for using a blockchain to perform an atomic swap
US11455694B2 (en) 2020-05-20 2022-09-27 Jambb Inc. System and methods for building a digital asset based social media application and reward platform
US11463241B2 (en) 2017-10-20 2022-10-04 Hewlett Packard Enterprise Development Lp Transmitting or receiving blockchain information
US11489672B2 (en) 2018-11-06 2022-11-01 International Business Machines Corporation Verification of conditions of a blockchain transaction
US11538001B2 (en) 2017-04-03 2022-12-27 Safran Passenger Innovations, Llc Systems and methods for cryptocurrency transactions in aircraft
WO2023014525A1 (fr) * 2021-08-02 2023-02-09 Mastercard International Incorporated Procédé et système de versements par chaîne de blocs
US11582040B2 (en) 2017-10-20 2023-02-14 Hewlett Packard Enterprise Development Lp Permissions from entities to access information
US11604890B2 (en) 2017-10-20 2023-03-14 Hewlett Packard Enterprise Development Lp Accessing information based on privileges
US12032716B2 (en) 2023-01-24 2024-07-09 Hewlett Packard Enterprise Development Lp Accessing information based on privileges

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10700861B2 (en) 2016-07-29 2020-06-30 Workday, Inc. System and method for generating a recovery key and managing credentials using a smart blockchain contract
US10637665B1 (en) 2016-07-29 2020-04-28 Workday, Inc. Blockchain-based digital identity management (DIM) system
US11336432B2 (en) 2016-07-29 2022-05-17 Workday, Inc. System and method for blockchain-based device authentication based on a cryptographic challenge
US10735197B2 (en) * 2016-07-29 2020-08-04 Workday, Inc. Blockchain-based secure credential and token management across multiple devices
US11088855B2 (en) 2016-07-29 2021-08-10 Workday, Inc. System and method for verifying an identity of a user using a cryptographic challenge based on a cryptographic operation
US10715312B2 (en) * 2016-07-29 2020-07-14 Workday, Inc. System and method for blockchain-based device authentication based on a cryptographic challenge
US10715311B2 (en) * 2017-07-28 2020-07-14 Workday, Inc. System and method for blockchain-based user authentication based on a cryptographic challenge
DE102017204536B3 (de) * 2017-03-17 2018-03-08 Bundesdruckerei Gmbh Ausstellen virtueller Dokumente in einer Blockchain
US20200374131A1 (en) * 2019-05-23 2020-11-26 Mastercard International Incorporated Method and system for generalized provenance solution for blockchain supply chain applications
CN114221771B (zh) * 2021-12-02 2024-01-30 上海健交科技服务有限责任公司 一种面向深度学习的安全令牌传输及校验加速方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5903880A (en) * 1996-07-19 1999-05-11 Biffar; Peter C. Self-contained payment system with circulating digital vouchers
US20040019571A1 (en) * 2002-07-26 2004-01-29 Intel Corporation Mobile communication device with electronic token repository and method
WO2005109359A1 (fr) * 2004-04-30 2005-11-17 Combots Product Gmbh & Co. Kg Systeme de paiement electronique a unites monetaires numeriques
US20140164251A1 (en) * 2012-08-16 2014-06-12 Danny Loh User generated autonomous digital token system

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000010068A2 (fr) * 1998-08-13 2000-02-24 Fuisz Richard C Procede et dispositif de generation, de virement et de rachat de monnaie electronique
US6748367B1 (en) * 1999-09-24 2004-06-08 Joonho John Lee Method and system for effecting financial transactions over a public network without submission of sensitive information

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5903880A (en) * 1996-07-19 1999-05-11 Biffar; Peter C. Self-contained payment system with circulating digital vouchers
US20040019571A1 (en) * 2002-07-26 2004-01-29 Intel Corporation Mobile communication device with electronic token repository and method
WO2005109359A1 (fr) * 2004-04-30 2005-11-17 Combots Product Gmbh & Co. Kg Systeme de paiement electronique a unites monetaires numeriques
US20140164251A1 (en) * 2012-08-16 2014-06-12 Danny Loh User generated autonomous digital token system

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
HARSH PATEL: "A pure block chain based decentralized exchange", INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH,, vol. 20141225:065012, 18 December 2014 (2014-12-18), pages 1 - 9, XP061017563 *
HITESH TEWARI ET AL: "Netcoin - A Traceable P2P Electronic Cash System", INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH,, vol. 20150628:192456, 19 June 2015 (2015-06-19), pages 1 - 7, XP061018753 *
PRATIK SARKAR: "Multiple-Use Transferable E-Cash", INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH,, vol. 20140207:181435, 7 February 2014 (2014-02-07), pages 1 - 4, XP061015358 *
SATOSHI NAKAMOTO: "Bitcoin: A Peer-to-Peer Electronic Cash System", 31 October 2008 (2008-10-31), XP055131503, Retrieved from the Internet <URL:https://bitcoin.org/bitcoin.pdf> [retrieved on 20140724] *

Cited By (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3062499A1 (fr) * 2017-02-02 2018-08-03 Ingenico Group Procede de reduction de la taille d'une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant
US11538001B2 (en) 2017-04-03 2022-12-27 Safran Passenger Innovations, Llc Systems and methods for cryptocurrency transactions in aircraft
KR20210081444A (ko) * 2017-04-28 2021-07-01 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 합의 검증 방법 및 디바이스
KR102541219B1 (ko) * 2017-04-28 2023-06-08 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 합의 검증 방법 및 디바이스
KR20190090832A (ko) * 2017-04-28 2019-08-02 알리바바 그룹 홀딩 리미티드 합의 검증 방법 및 디바이스
KR102281558B1 (ko) * 2017-04-28 2021-07-27 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 합의 검증 방법 및 디바이스
WO2018223125A1 (fr) * 2017-06-02 2018-12-06 Visa International Service Association Procédés et systèmes de vérification de propriété à l'aide d'une chaîne de blocs
US20220321359A1 (en) * 2017-06-02 2022-10-06 Visa International Service Association Methods and systems for ownership verification using blockchain
US11394559B2 (en) 2017-06-02 2022-07-19 Visa International Service Association Methods and systems for ownership verification using blockchain
US11403628B2 (en) 2017-10-20 2022-08-02 Hewlett Packard Enterprise Development Lp Authenticating and paying for services using blockchain
US11463241B2 (en) 2017-10-20 2022-10-04 Hewlett Packard Enterprise Development Lp Transmitting or receiving blockchain information
US11582040B2 (en) 2017-10-20 2023-02-14 Hewlett Packard Enterprise Development Lp Permissions from entities to access information
US11604890B2 (en) 2017-10-20 2023-03-14 Hewlett Packard Enterprise Development Lp Accessing information based on privileges
WO2019147736A1 (fr) * 2018-01-23 2019-08-01 Iannaccone Philip Michael Système et procédé pour une transmission de données sécurisée
US11233792B2 (en) 2018-05-02 2022-01-25 Mastercard International Incorporated Method and system for enhanced login credential security via blockchain
CN110445612A (zh) * 2018-05-02 2019-11-12 万事达卡国际公司 用于经由区块链增强登录凭证安全性的方法和系统
CN110445612B (zh) * 2018-05-02 2022-06-10 万事达卡国际公司 用于经由区块链增强登录凭证安全性的方法和系统
JP2020014193A (ja) * 2018-05-07 2020-01-23 ブロードリッジ・ファイナンシャル・ソリューションズ・インコーポレイテッドＢｒｏａｄｒｉｄｇｅ Ｆｉｎａｎｃｉａｌ Ｓｏｌｕｔｉｏｎｓ， Ｉｎｃ． 暗号学的に保護されたトークンベースの代替管理を行うためのコンピュータネットワークシステム、および当該システムを利用する方法
JP7385371B2 (ja) 2018-05-07 2023-11-22 ブロードリッジ・ファイナンシャル・ソリューションズ・インコーポレイテッド 暗号学的に保護されたトークンベースの代替管理を行うためのコンピュータネットワークシステム、および当該システムを利用する方法
US11838407B2 (en) 2018-05-14 2023-12-05 Nchain Licensing Ag Computer-implemented systems and methods for using a blockchain to perform an atomic swap
US11764947B2 (en) 2018-05-14 2023-09-19 Nchain Licensing Ag Systems and methods for storage, generation and verification of tokens used to control access to a resource
US11431477B2 (en) 2018-05-14 2022-08-30 nChain Holdings Limited Computer-implemented systems and methods for using a blockchain to perform an atomic swap
US11917051B2 (en) 2018-05-14 2024-02-27 Nchain Licensing Ag Systems and methods for storage, generation and verification of tokens used to control access to a resource
US11985225B2 (en) 2018-05-14 2024-05-14 Nchain Licensing Ag Computer-implemented systems and methods for using veiled values in blockchain
US11695545B2 (en) 2018-06-20 2023-07-04 Verizon Patent And Licensing Inc. Systems and methods for controlled random endorsement in a blockchain network
US10880072B2 (en) * 2018-06-20 2020-12-29 Verizon Patent And Licensing Inc. Systems and methods for controlled random endorsement in a blockchain network
US20210099280A1 (en) * 2018-06-20 2021-04-01 Verizon Patent And Licensing Inc. Systems and methods for controlled random endorsement in a blockchain network
CN109391619B (zh) * 2018-10-22 2021-08-03 上海幼鸢网络科技有限公司 基于权限的跨链通证交换方法及计算机可读介质
CN109391619A (zh) * 2018-10-22 2019-02-26 昧来网络科技（上海）有限公司 基于权限的跨链通证交换方法及计算机可读介质
CN109525648A (zh) * 2018-10-26 2019-03-26 全链通有限公司 区块链共识机制、设备及计算机可读存储介质
US11489672B2 (en) 2018-11-06 2022-11-01 International Business Machines Corporation Verification of conditions of a blockchain transaction
CN111461468B (zh) * 2019-01-02 2023-10-31 中国移动通信有限公司研究院 数据处理方法及装置、数据节点及存储介质
CN111461468A (zh) * 2019-01-02 2020-07-28 中国移动通信有限公司研究院 数据处理方法及装置、数据节点及存储介质
CN113728351A (zh) * 2019-02-20 2021-11-30 恩佩弗尼集团 区块链系统中的可信通证化交易
US20220029810A1 (en) * 2019-03-01 2022-01-27 Capital One Services, Llc Identity and electronic signature verification in blockchain
US11455694B2 (en) 2020-05-20 2022-09-27 Jambb Inc. System and methods for building a digital asset based social media application and reward platform
WO2022089518A1 (fr) * 2020-10-31 2022-05-05 华为技术有限公司 Procédé de génération d'adresse, procédé de traitement d'informations de chaîne de blocs, et dispositif associé
WO2023014525A1 (fr) * 2021-08-02 2023-02-09 Mastercard International Incorporated Procédé et système de versements par chaîne de blocs
US11989703B2 (en) 2021-08-02 2024-05-21 Mastercard International Incorporated Method and system of blockchain disbursements
US12032716B2 (en) 2023-01-24 2024-07-09 Hewlett Packard Enterprise Development Lp Accessing information based on privileges

Also Published As

Publication number Publication date
GB2539430A (en) 2016-12-21
GB201510528D0 (en) 2015-07-29

Similar Documents

Publication Publication Date Title
WO2016202952A1 (fr) Système d&#39;échange de jetons numériques
US11790370B2 (en) Techniques for expediting processing of blockchain transactions
KR102050129B1 (ko) 블록 검증을 위한 복수의 일방향 함수를 지원하는 블록 체인
Saad et al. Exploring the attack surface of blockchain: A systematic overview
EP3812992B1 (fr) Procédé et appareil de transaction de chaîne de blocs
CN107306183B (zh) 客户端、服务端、方法和身份验证系统
EP3073670B1 (fr) Système et procédé d&#39;identification personnelle et de vérification
RU2719311C1 (ru) Система и способ защиты информации
Averin et al. Review of blockchain technology vulnerabilities and blockchain-system attacks
CN101651675B (zh) 通过认证码对客户端进行验证的方法和系统
CN110177124B (zh) 基于区块链的身份认证方法及相关设备
CN111523890A (zh) 基于区块链的数据处理方法、装置、存储介质及设备
CN111815321A (zh) 交易提案的处理方法、装置、系统、存储介质和电子装置
CN111461852A (zh) 一种基于区块链的数据处理方法、装置及可读存储介质
US11811945B2 (en) Blockchain identities
EP3659060B1 (fr) Protocole de consensus pour registres accrédités
CN111507839A (zh) 基于区块链的数据处理方法、装置、存储介质及设备
CN110266676A (zh) 一种预防恶意攻击的方法及装置
CN111833062B (zh) 数字资产数据包的可信性验证系统
CN111768199A (zh) 数字货币交易方法和本地钱包系统
Singh et al. IoT–Blockchain Integration-Based Applications Challenges and Opportunities
CN113901519A (zh) 基于区块链的数据处理方法、装置、设备及介质
Maheswari et al. Blockchain technology and its applications-an overview
NS et al. Security Attacks and Key Challenges in Blockchain Technology: A survey
CN117040929B (zh) 一种访问处理方法、装置、设备、介质及程序产品

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16736003

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16736003

Country of ref document: EP

Kind code of ref document: A1