Method and system for controlling the execution of a contract

Abstract

To provide a method and a system implemented by a computer that controls execution of a smart contract.SOLUTION: A method includes storing a contract in a computer-based repository. The contract relates to a license between a first user (U1) and a second user (U2). The method further includes receiving a transaction including transfer of a token from an agent (first computer) to the U1 or the U2 via a communication network. The transaction has metadata that includes an identifier indicating a place to store the contract. The method also includes making an inquiry to a peer-to-peer distributed ledger (that is, block-chain) to determine whether the transaction has at least one unused output (UTXO) and determining whether to modify execution of the contract in response to making an inquiry to the peer-to-peer distributed ledger. The block-chain may be the Bitcoin block-chain.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to methods for securing computer software and granting access to the computer software using distributed hash tables and peer-to-peer distributed ledgers. [Background technology]

[0002] In this document, the term "blockchain" is used to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. For convenience and illustrative purposes, Bitcoin may be referenced herein, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and other blockchain implementations and protocols are within the scope of the present invention. The term "user" herein may refer to a human or a processor-based resource.

[0003] A blockchain is a computer-based, decentralized, peer-to-peer electronic ledger realized as a distributed system of blocks, which are made up of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block for which the blocks are chained together to create a permanent, immutable record of all transactions that have been written to the blockchain since inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs that specify how and by whom the transaction's outputs can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be "validated". Network nodes (miners) perform the work to ensure that each transaction is valid, by which invalid transactions are rejected from the network. A software client installed on the node performs this validation on unspent transactions (UTXOs) by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, then the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be validated by the first node that receives the transaction, and if the transaction is validated, the node relays it to other nodes in the network, ii) be added to a new block constructed by miners, and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in enabling cryptocurrencies, digital entrepreneurs have begun to explore the use of both the cryptographic security system on which Bitcoin is based, and the data that can be stored on the blockchain, to enable new systems. It would be very effective if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency realm. Such solutions would be able to take advantage of the benefits of blockchain (e.g., a permanent, tamper-resistant record of events, distributed processing, etc.) while making them more versatile in their applications.

[0006] One area of ​​current research is the use of blockchain for the implementation of "smart contracts". These are computer programs designed to automate the execution of machine-readable documented agreements such as contracts or agreements. Unlike traditional contracts, which are written in natural language, smart contracts are machine-executable programs that contain rules capable of processing inputs to produce outcomes, and perform actions depending on these outcomes.

[0007] Another area of ​​blockchain-related interest is the use of "tokens" (or "colored coins") to represent and transfer real-world entities through the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Thus, the tokens act as identifiers that allow the real-world items to be referenced from the blockchain.

[0008] These areas of technical research may be applied to effects related to the control of digital assets such as software, for example. A traditional approach to securing the integrity and sharing of computer software involves digitally signing executable files of the computer software. For example, signing the executable files or other related code with a cryptographic key pair, such as a public and private key. The public key is often obtained from a trusted central authority, such as a certification authority.

[0009] Computer software is often accompanied by a license that contains contractual obligations. The license may contain agreements governing the use or redistribution of the software. Problems may arise where computer software or an associated license is illegally transferred to another user.

[0010] Any discussion of documents, acts, materials, devices, articles or the like included in this specification should not be taken as an admission that any or all of that subject matter forms part of the prior art base or was common general knowledge in the field relevant to the present disclosure as existing prior to the priority date of each claim of this application.

[0011] Throughout this specification the word "comprise" or derivatives thereof will be understood to imply the inclusion of a stated element, integer or step or group of elements, integers or steps but not the exclusion of any other element, integer or step or group of elements, integers or steps. Summary of the Invention

[0012] The present invention may include a computer-implemented control method. It may be configured to control the execution of a computer-implemented process. The process may be specified by a contract. The contract may be a smart contract, which is a machine-executable document. The term "user" may be used herein to refer to a human user or a machine (computer). Additionally or alternatively, the present invention may be described as providing a security measure (method / system). It may be configured to preserve the integrity of a controlled resource or digital asset. It may be configured to control the movement of a controlled resource or digital asset. The resource or asset may be software.

[0013] The method comprises: - storing (smart) contracts in a computer-based repository, the contracts relating to a first user (U1) and a second user (U2); receiving a blockchain transaction including at least one output and including a token transferred from an agent or a first computer (A) to a first user (U1) or a second user (U2) (the second user being a second computer) via a communication network, the transaction including metadata including an identifier indicating where the contract is stored; querying a peer-to-peer distributed ledger to determine if the transaction contains at least one unspent output (UTXO); determining whether to modify execution of the contract in response to querying the peer-to-peer distributed ledger; may have the following structure:

[0014] The unspent output (UTXO) may have a representation of a contract. Querying the peer-to-peer distributed ledger may include scanning the peer-to-peer distributed ledger (blockchain) to determine if a transaction includes at least one unspent output (UTXO) that represents a contract. The contract may be associated with a license between a first user and a second user.

[0015] The transaction may further include a definitive redeemscript address, which may be a pay-to-script hash (P2SH) address. Thus, the existence of the contract may be made publicly available using a transaction published on a peer-to-peer distributed ledger (e.g., a blockchain) using a pay-to-script hash address, which may be determined or provided by the contract's issuer and / or the contract's metadata.

[0016] The determining step may include terminating the contract if at least one unspent output (UTXO) is not identifiable from the peer-to-peer distributed ledger, or maintaining the contract if at least one unspent output (UTXO) is identifiable from the peer-to-peer distributed ledger.

[0017] Terminating the contract may include broadcasting a further transaction to consume the at least one unspent output (UTXO). Further, in the step of broadcasting the further transaction, the further transaction may include an instruction to consume the at least one unspent output (UTXO) at a specified date and / or time. For example, the instruction may be a CheckLockTimeVerify instruction.

[0018] The further transaction may include an input being at least one unspent output (UTXO) and a redeem script including a signature, metadata, an agent public key (PA) associated with the agent and a first user public key (PU1) associated with the first user (U1). This provides the advantage of automatic termination of the contract and therefore the license by enabling the transaction to spend the unspent output (UTXO) on the peer-to-peer distributed ledger.

[0019] A contract may define at least one condition regarding the transaction of a license between a first user (U1) and a second user (U2) and at least one action whose execution depends on evaluation of the condition. A condition may be a test that can be evaluated as true or false. A condition may be part of a contract (e.g., a clause). Completion or execution of a condition may be required for execution of the contract. A condition may be completed if it is evaluated as true.

[0020] The metadata may include an address or a representation of the address where the agreement is stored in a computer-based repository and / or a hash of the agreement.

[0021] Querying the peer-to-peer distributed ledger may further include checking if the contract has terminated by determining if at least one unspent output (UTXO) is present in a list of unspent transaction outputs in the peer-to-peer distributed ledger.

[0022] The computer-based repository may be or may include a server. The repository may be a database or storage facility located on a computer-based resource. The repository may be indexed and made searchable. The repository may include a distributed hash table (DHT). The contracts may be stored within or associated with the DHT.

[0023] A contract may include a deterministic finite automaton (DFA) that implements the contract. Further, the deterministic finite automaton (DFA) may be defined using an encoding scheme.

[0024] The method may further include updating the contract by generating a subkey for a previous key associated with the contract, generating a further redeem script that includes the subkey, a location of the contract and a hash of the contract, and paying an amount of virtual currency to the further redeem script.

[0025] The method may further comprise generating a sub-agreement derived from the agreement, the sub-agreement being generated by utilizing a new public key associated with the deterministic address and derived using the seed; storing the sub-agreement in a computer-based repository along with a reference to the agreement; broadcasting the sub-agreement transaction including the reference to the agreement to the peer-to-peer distributed ledger; and adding a reference to the sub-agreement to metadata associated with the agreement.

[0026] The license between a first user (U1) and a second user (U2) may be for one or more of computer software and digital media including music, video and e-books.

[0027] The peer-to-peer distributed ledger may be a blockchain. Further, the virtual currency may be Bitcoin.

[0028] The present invention may also include a computer-implemented system configured to carry out any of the embodiments of the invention described above.

[0029] A computer software program having machine readable instructions that cause a processing device to implement the method described above.

[0030] The invention may include a computer system corresponding to any embodiment of the method described above, which may be configured to control execution of a computer-implemented process as defined in a (smart) contract, the system storing the contract in a computer-based repository, the contract may relate to a license between a first user (U1) and a second user (U2), receiving a blockchain transaction including at least one output and including a movement of tokens transferred from an agent (A) (e.g., a first computer) to a second computer (which may be a first user (U1) or a second user (U2)) via a communication network, the transaction including metadata including an identifier indicating where the contract is stored; Querying a peer-to-peer distributed ledger to determine if the transaction contains at least one unspent output (UTXO); The system may include a processing device configured to determine whether to modify execution of the contract in response to querying the peer-to-peer distributed ledger.

[0031] The unspent output (UTXO) may include a representation of a contract. Querying a peer-to-peer distributed ledger (blockchain) may include scanning the peer-to-peer distributed ledger to determine whether a transaction has at least one unspent output (UTXO) that represents a contract.

[0032] Any feature described above with respect to one aspect or embodiment may also be utilized with any other aspect or embodiment. Any feature described with respect to a system of the present invention may be applicable to a corresponding method. [Brief description of the drawings]

[0033] [Figure 1] A concrete example of a hash table is shown below. [Diagram 2] 1 shows a schematic diagram of an example system that utilizes a distributed hash table to determine metadata (M) for securing computer software. [Diagram 3] 1 shows a flowchart of a computer-implemented method for determining metadata (M) for securing computer software using a distributed hash table. [Figure 4] Here is a concrete example of a Merkle tree: [Diagram 5] An example of a Merkle tree is provided with reference to computer software and licenses relating to computer software. [Figure 6] 1 shows a flowchart of a computer-implemented method for determining an identifier that indicates the location of computer software using a distributed hash table. [Figure 7] 1 illustrates a schematic of an example processing device. [Figure 8] 1 shows a flowchart of a computer-implemented method for controlling execution of contracts using a distributed hash table and a peer-to-peer distributed ledger. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0034] The present disclosure relates generally to methods and systems that enable securing and authorizing access to computer software using peer-to-peer (P2P) distributed ledgers (blockchains) and distributed hash tables, such as the Bitcoin blockchain.

[0035] Although the embodiments described below may specifically refer to transactions taking place on the Bitcoin blockchain (referred to herein as the blockchain), the present invention may be implemented using other P2P distributed ledgers. Due to its high level of standardization and the large amount of related public literature, blockchain is used below to describe aspects of the present invention for simplicity only. [Distributed Hash Table] In a typical client / server model, a central server may be responsible for the majority of resources. This means that if there is an attack or failure on the central server, the majority of the resources stored on the central server may be compromised. Conversely, in a distributed model, resources are shared ("distributed") among the participating nodes. In this way, the capacity of all participating nodes is utilized and the failure of one server does not compromise the majority of resources.

[0036] Figure 1 shows an example of a hash table. A hash table consists of key-value pairs. The key of each key-value pair is mapped to an index by a hash function. The index specifies the location of the stored value in the key-value pair.

[0037] A DHT is an example of the distributed model applied to a hash table. Like a hash table, a DHT has key-value pairs and provides an efficient way to locate ("look up") the value of a key-value pair, given the key. However, in contrast to a hash table, the key-value pairs are distributed and stored by several participating nodes. In this way, the responsibility for storing and maintaining the key-value pairs is shared by the participating nodes.

[0038] Similar to a hash table, each key-value pair in a DHT is mapped to an index. The index is determined for each key-value pair by running a hash function on the key. For example, the Cryptographically Secure Hash Algorithm SHA-1 may be used to determine the index.

[0039] Each participating node is assigned at least one index by a partition of the key space. For each index assigned to a participating node, the participating node stores the value of that key-value pair.

[0040] The advantage is that the value of a key-value pair can be extracted efficiently. To extract the value associated with a key, a node may perform a "lookup" to determine a responsible node (via an index). The responsible node can then be accessed to determine the value. [Bitcoin and Blockchain] As is well known in the art, a blockchain is a database transaction-type ledger whose storage capacity is distributed among networked nodes participating in the system according to the Bitcoin protocol. Each Bitcoin transaction is broadcast to the network, where the transaction is approved and then aggregated into a block. The block is then included on the blockchain by storing the block on multiple participating nodes.

[0041] A complete copy of a cryptocurrency's P2P distributed ledger would contain every transaction ever executed in the cryptocurrency, thus providing a continuously growing list of transaction data records. Because each transaction put into the blockchain is cryptographically enforced, the blockchain is difficult to tamper with and change, even by operators of participating nodes.

[0042] Due to the transparency of the blockchain, the history is publicly available for each transaction.

[0043] A further benefit of the blockchain is that the transaction and the record of the transaction are the same.

[0044] In this way, information about the transaction is captured during the actual transaction, and this record is permanent and immutable, thus removing the requirement for a third party to maintain transaction records in a separate database. [Pay-to-script hash and multi-signature] The following examples may specifically refer to transactions utilizing the Pay-to-Script Hash (P2SH) method of the Bitcoin protocol, although the invention may be implemented using other methods of the Bitcoin protocol, such as Pay-to-Public Key Hash.

[0045] Each transaction record on the blockchain has a script containing information describing the transaction and several public keys. These public keys may be associated with the sender and receiver of the virtual currency. The script may be viewed as a list of instructions recorded with each transaction record on the blockchain that describes how a user can gain access to the virtual currency specified in the transaction record. The script may also describe the requirements for accessing the virtual currency, for example, the required signature.

[0046] By way of background, in the standard P2SH method of the Bitcoin protocol, the output script, i.e. the redeem script, <NumSigs PubK1 PubK2...PubK15 NumKeys OP_CHECKMULTISIG> It can take the form:

[0047] where NumSigs is the number of valid signatures “m” needed to satisfy the redeem script to unlock the transaction, PubK1 PubK2...PubK15 are the public keys corresponding to the signatures that unlock the transaction (up to a maximum of 15 public keys), and NumKeys is the number of public keys “n”.

[0048] In the Bitcoin protocol, a signature based on a user's private key may be generated using an elliptic curve digital signature algorithm. The signature is then used to redeem the virtual currency associated with the output script or redeem script. When a user redeems an output script or redeem script, the user provides the signature and a public key. The output script or redeem script then verifies the signature against the public key.

[0049] To redeem the above redeem script, at least "m" number of signatures corresponding to the public keys are required. In some implementations, the order of the public keys is important and "m" number of signatures from "n" signatures for signing must be executed in order. For example, consider the case where "m" is 2 and "n" is 15. If there are two signatures available, Sig1 (corresponding to PubK1) and Sig15 (corresponding to PubK15), the redeem script must be signed first by Sig1 and then by Sig15. [System Overview] 2 shows a system 1 including a first node 3 in communication with a second node 7 via a communications network 5. The first node 3 has an associated first processing device 21, and the second node 5 has an associated second processing device 27. Examples of the first node 3 and second node 7 include electronic devices such as computers, tablet computers, mobile communications devices, computer servers, etc.

[0050] Also shown in Figure 2 is a DHT 13 for recording and storing key-value pairs. The DHT 13 may be associated with one or more processing devices 19 for receiving, recording and storing the values ​​of the key-value pairs. The processing devices 19 may be utilized by "participating nodes" of the DHT 13. As described above, the DHT 13 provides an efficient method for identifying values ​​of key-value pairs.

[0051] 2 also illustrates a P2P distributed ledger 14 for recording transactions. The P2P distributed ledger 14 may be associated with one or more processing devices 20 for receiving and recording transactions. As mentioned above, an example of a P2P distributed ledger 14 is the Bitcoin blockchain. Thus, in terms of blockchain, the processing devices 20 associated with the P2P distributed ledger 14 may be processing devices referred to as "miners."

[0052] The first node 3 is associated with a first user 23 and the second node 7 is associated with a second user 24. In one example, the first node 3 may represent a vendor of computer software. In another example, the first node 3 may represent an agent or service provider. In yet another example, the first node 3 may represent a user of the computer software.

[0053] Similarly, the second node 7 may represent an agent, a service provider, a vendor of computer software, or a user of computer software.

[0054] In one example, the first node 3 performs the method 100, 500 as named in Figures 3 and 6. In another example, the second node 7 performs the method 100, 500. It should be understood that although the following examples may refer to the first node 3 as performing these methods, the present disclosure may also be adapted or modified to be performed by other nodes.

[0055] 3 includes determining (110) data (D1) associated with the computer software. The data (D1) may further include a license associated with the computer software. The method 100 also includes determining (120) a first hash value (H1) based on the computer software. In one example, the first hash value (H1) may be for an executable file of the computer software.

[0056] The method 100 also includes determining (130) a second hash value (H2) based on the data (D1) and the computer software. In one example, the second hash value (H2) may represent details of the computer software and a license associated with the computer software. In a further example, the second hash value (H2) may include additional information.

[0057] The method 100 further includes transmitting (140) the data (D1), the first hash value (H1) and the second hash value (H2) over the communications network 5 to an entry on the distributed hash table 13, where the second hash value (H2) is assigned to a key of a key-value pair and the data (D1) and the first hash value (H1) are assigned to a value in the key-value pair. The value in the key-value pair may further include an identifier indicating a location of the computer software or license.

[0058] The method 100 also includes determining (150) metadata (M) based on the second hash value (H2) for inclusion in the peer-to-peer distributed ledger 14. In one example, the metadata (M) may be included in a first redeem script (RS1) for inclusion in the peer-to-peer distributed ledger 14. [Determination of Data Related to Computer Software (110)] As mentioned above, the method 100 includes determining (110) data (D1) related to the computer software. Determining (110) the data (D1) may include receiving the data (D1) from a user, a node, or a data store. Determining (110) the data (D1) may further include generating the data (D1) at the first node 3.

[0059] In one example, the first node 3 may receive data (D1) from a first user 23 via a user interface 15. In another example, the first node 3 may receive data (D1) from a second user 24. In yet another example, the first node 3 may receive data (D1) from a data store 17.

[0060] The data (D1) is associated with the computer software, and the data (D1) may identify the computer software, additional information, a license for the computer software, or a location of the computer software. For example, the data (D1) may include a string or data structure that identifies the computer software. The string or data structure may include a collection of keywords and / or additional information that identify the computer software. An example of additional information may be an identifier for a version of the computer software. For example, if the computer software is named BobSoftware and is version 3.0, the string or data structure (D1) may include "BobSoftware / 3.0".

[0061] In a further example, the data (D1) may comprise an identifier of a license associated with the computer software, which may be a software license identification number (ID) or a software license key, hi another example, the identifier of the license may comprise a cryptographic hash of the contents of the license.

[0062] The data (D1) may further comprise an identifier indicating the storage location of the computer software. In one example, the identifier may comprise a URL of an object on the internet. In a further example, a link may be provided to the storage location of the computer software on a repository such as a hash table or a distributed hash table.

[0063] In yet another example, the data (D1) may include information identifying a vendor of the computer software, which may include a name, address, contact details or personal details such as a public key associated with the vendor. [Determining (120) a first hash value (H1) based on computer software] As discussed above, the method 100 further includes determining (120) a first hash value (H1) of the computer software. Determining (120) the first hash value (H1) may include receiving the first hash value (H1) from a user or alternatively accessing the first hash value (H1) from a data store. Determining (120) the first hash value (H1) may further include calculating the hash value at the first node 3.

[0064] In one example, the first node 3 may receive the first hash value (H1) from the first user 23 via the user interface 15. In another example, the first node 3 may receive the first hash value (H1) from the second user 24. In yet another example, the first node 3 may access the first hash value (H1) from the local data store 17 or a remote data store.

[0065] In one example, the first hash value (H1) is of an executable file of computer software. The executable file of computer software may be extracted from a communications network 5, such as the Internet. In another example, the executable file may be provided by a first user 23 or a second user 24. In yet another example, the executable file may be extracted from a data store 17. In yet another example, the executable file may be extractable from a repository, such as a hash table or DHT.

[0066] The hash of the software executable file may be determined utilizing the SHA-256 algorithm to generate a 256-bit representation of the information. It should be understood that hash algorithms may be utilized, including other algorithms in the Secure Hash Algorithm (SHA) family. Some specific examples include instances in the SHA-3 subset, including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256. Other hash algorithms may include those in the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) family. A specific example may include RIPEMD-160. Other hash functions may include families based on Zemor-Tillich hash functions and knapsack-based hash functions. [Determining (130) a second hash value (H2) based on the data (D1) and computer software] The method 100 also includes determining (130) a second hash value (H2) based on the data (D1) and the computer software.

[0067] In one example, the second hash value (H2) may be determined based on a hash of the concatenation of the data (D1) and the executable file of the computer software (or a hash of the executable file, i.e., the first hash value (H1)). In a further example, the second hash value (H2) may be determined based on a hash of the concatenation of the data (D1), the executable file of the computer software (or a hash of the executable file) and the additional information.

[0068] The additional information may include a public key of the first user 23 (PU1) or the second user 24 (PU2). In a further example, the additional information may include an identifier of an entity associated with the first user 23 or the second user 24. For example, the entity may be an employer of the first user 23 or the second user 24. In another example, the entity may be a service provider of the first user 23 or the second user 24.

[0069] The additional information may further include a device identifier of a device associated with the first node 3, the second node 7, the first user 23 or the second user 24. An example of a device is the first processing device 21 as shown in FIG. 2. The device identifier may include at least one of a MAC address, a motherboard serial number or a device identification number. The device identifier may further be a concatenation of at least two of the MAC address, the motherboard serial number or the device identification number. In a further example, the device identifier may include a hash value associated with the MAC address, the motherboard serial number, the device identification number or the concatenation mentioned above.

[0070] In a further example, the additional information may include an expiration date for a license associated with the computer software. [Agreements relating to computer software (e.g. licenses)] In a further example, the second hash value (H2) may be determined based on a concatenation of the data (D1), the executable file of the computer software (or a hash value of the executable file), additional information or a contract (e.g., a license) associated with the computer software.

[0071] The representation of the agreement (e.g., license) may be a file or document that specifies the contents of the license, for example plain ASCII text, a PDF document, or a Word document. The second hash value (H2) may contain the license in its original form, or it may provide a link to the location of the license in a publicly accessible communications network, such as the Internet, for example. In a further example, a link to the location of the license on a repository, such as a hash table or DHT, may be provided. In a further example, a link to the location of the license on a computer-based resource, such as data store 17, may be provided.

[0072] In one example, the license may include a first hash value (H1) associated with the computer software.

[0073] A license associated with computer software may further include additional information as described above. In one example, the license may be associated with a first user 23 or a second user 24. The license may include a public key of the first user 23 (PU1) or the second user 24 (PU2). In a further example, the license may include an identifier of an entity associated with the first user 23 or the second user 24.

[0074] The license associated with the computer software may further include a device identifier of a device associated with the first node 3, the second node 7, the first user 23 or the second user 24. An example of a device is the first processing device 21 as shown in FIG. 2. The device identifier may include at least one of a MAC address, a motherboard serial number or a device identification number. The device identifier may further be a concatenation of at least two of the MAC address, the motherboard serial number or the device identification number. In a further example, the device identifier may include a hash value associated with the MAC address, the motherboard serial number, the device identification number or the concatenation mentioned above.

[0075] First user 23 may be a vendor of computer software and second user 24 may be a recipient of the computer software (an "end user"). In other examples, second user 23 may be a vendor of computer software and second user 24 may be an end user of the computer software.

[0076] In one example, the license associated with the computer software may authorize only one end user (a "single user license"). In a further example, the license associated with the computer software may authorize one end user device (a "single device license"). In another example, the license associated with the computer software may authorize multiple end user devices (a "multiple device license").

[0077] In other examples, there may be multiple end users (a "multiple user license"). In a further example, a license associated with the computer software may permit one device per end user. In other examples, a license associated with the computer software may permit multiple devices per end user.

[0078] If the license is associated with a first user 23 or a second user 24, the license may have a first user public key (PU1) associated with the first user 23 and a second user public key (PU2) associated with the second user 24. [Merkle Tree] In another example, the license may be the hash value of the top of a Merkle tree. An example of a Merkle tree is shown in FIG. 4. In a Merkle tree, the hash values ​​at each node are the hash of their respective "child" nodes. For example, the hash value Hash-A 305 is the hash of the hash values ​​at two "child" nodes 309, 311. The hash value Hash-AB 303 at the top of the Merkle tree contains all the hash values ​​in the Merkle tree; that is, it captures the hash values ​​of the four "leaves" at the bottom of the tree, A1 317, A2 319, B1 321, and B2 323.

[0079] In the examples of the present disclosure, each "leaf" of the Merkle tree may represent an aspect of information in the license. An exemplary license is shown in Figure 5. Data (D1) 417 is captured in hash value Hash-D 409, public key 421 of user 23 and / or 24 is captured in hash value Hash-P 413, and expiration date 423 is captured in hash value Hash-E 415. It can be seen that nodes 405 and 407 capture the hash values ​​associated with the leaves of data (D1) 417, software 419, public key 421, and expiration date 423, respectively.

[0080] It should be understood that other information not described above may include additional information upon which the hash value (H2) is based. [Transmitting data (D1), first hash value (H1), and second hash value (H2) to the distributed hash table (140)] The method 100 also includes transmitting (140) the data (D1), the first hash value (H1), and the second hash value (H2) to an entry on the distributed hash table 13 over the communication network 5.

[0081] In one example, the second hash value (H2) may be the key of a key-value pair, and the data (D1) and the first hash value (H1) may be the value of the key-value pair.

[0082] In further examples, additional information as described above may also be part of the value in a key-value pair, including, but not limited to, a public key of the first user 23 or the second user 24, a device identifier of a device associated with the first node 3, the second node 7, the first user 23 or the second user 24, an identifier indicating the location of the computer software or the license, or further additional information related to the license.

[0083] As mentioned above, the DHT 13 is composed of key-value pairs, with each key-value pair being assigned to an index. In one example, a second hash value (H2) may be used to generate the index. A hash function or a cryptographic hash function may be performed on the second hash value (H2). For example, the cryptographic function SHA-1 may be used.

[0084] Index=SHA-1(H2) The second hash value (H2) becomes the key of a key-value pair in the DHT 13, and the data (D1) and the first hash value (H1) become the value of the key-value pair, so that the key and value are sent to any participating node of the DHT 13.

[0085] In one example, a message such as put(key,value) may be sent to participating nodes of the DHT 13, where key is the second hash value (H2) and value is the data (D1) and the first hash value (H1). The message may be sent to all participating nodes until it is received by a participating node that is assigned to an index as indicated by the partitioning of the key space. The participating node that is assigned to the index indicated in the message may then assume responsibility for storing the key-value pair on the DHT 13 and maintaining the entry associated with the key-value pair.

[0086] It is advantageous that the value of any given key may be extracted from the DHT 13. In one example, the first user 23 or the second user 24 may wish to extract that value. The first user 23 or the second user 24 may provide a request message such as get(key) to any participating node of the DHT 13 via the first node 3, the second node 7, or another node not shown. The request message may then be sent to all participating nodes until it is received by a participating node that is assigned to an index as indicated by the partitioning of the key space. [Determining Metadata (M) (150)] The method 100 further includes determining (150) metadata (M) having the second hash value (H2). Determining (150) the metadata (M) may include receiving the metadata (M) from a user, node, or data store. The metadata (M) may be included, for example, in one or more of 15 locations available for a public key in a first redeem script (RS1) of a P2SH multisignature of a transaction on the P2P distributed ledger 14.

[0087] A first redeployment script (RS1) of a transaction on the P2P distributed ledger 14 may represent the issuance or creation of a tokenized transaction (an "issued token") that represents content contained in the metadata (M). In one example, the token may be issued by an agent (A).

[0088] In the P2SH method of the Bitcoin protocol, metadata may be included in the redeem script in a manner first introduced in commonly owned UK patent application number 1603125.4 entitled "Universal tokenisation system for blockchain based cryptocurrencies", the entire contents of which are incorporated by reference. A process for including metadata in a redeem script is described therein. However, a brief summary of the process is provided below. [Metadata] The metadata (M) may be embedded in one or more of the 15 locations available for the public key in the P2SH multi-signature redeem script (RS1). For example, the redeem script (RS1) may be: <NumSigs,Metadata1 Metadata2...PubK1 PubK2...NumKeys OP_CHECKMULTISIG> where Metadata1 and Metadata2 each contain metadata that takes the place of a public key in the redeem script, and PubK1 and PubK2 are public keys.

[0089] The metadata (M) may include a second hash value (H2). The metadata (M) may further include descriptions or keywords describing the computer software or terms associated with the license, such as the date of the license, the name, birth date, address, contact details or other details of the user associated with the license, etc. In a further example, information related to the quantity of virtual currency may be included.

[0090] The metadata (M) may include information in a number of ways. In one example, the contents of the information may be included. In a further example, a cryptographic hash of the information may be included. The hash of the information may be determined utilizing the SHA-256 algorithm to create a 256-bit representation of the information. It should be understood that other hash algorithms may be used, including other algorithms in the Secure Hash Algorithm (SHA) family. Some examples may include instances of the SHA-3 subset, including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256. Other hash algorithms may include those in the RACE Integrity Primitives Evalution Message Digest (RIPEMD) family. A particular example may include RIPEMD-160. Other hash functions may include families based on Zemor-Tillich hash functions and knapsack-based hash functions.

[0091] In further embodiments of the present disclosure, a combination including one or more of the above may be included in the metadata (M). Because the metadata (M) may be made publicly available via a P2P distributed ledger 14 such as a blockchain, or may be transmitted over an insecure network, it may be desirable for specific details of the metadata (M) to be kept secret or hidden for privacy reasons.

[0092] Thus, the use of multi-signature P2SH Bitcoin transactions in embodiments of the present disclosure provides advantages because they enable the transport and persistent recording of information related to computer software and licenses, for example, by including metadata in the output script of the transaction, such as a redeem script. [First Redeem Script] As mentioned above, the redeem script is an instantiation of an output script in the standard P2SH method of the Bitcoin protocol, and describes how a user can gain access to the cryptocurrency specified in a transaction record.

[0093] In the present disclosure, a first redeem script (RS1) for the issued token may be based on the metadata (M). The first redeem script (RS1) may further include an agent's public key (PA) that is cryptographically paired with the agent's private key (VA). In this manner, the agent's private key (VA) is required to "unlock" or spend the cryptocurrency associated with the transaction.

[0094] In one example, the first redeem script (RS1) for the issued token may include metadata (M). The first redeem script (RS1) may further include the agent's public key (PA). In this example, the first redeem script may include: <OP_1 PA Metadata1 Metadata2 OP_3 OP_CHECKMULTISIG> where OP_1 indicates the number of signatures ("NumSigs") required to satisfy a first redeem script (RS1) to unlock the transaction, and OP_3 indicates the number of public keys ("NumKeys") in the redeem script.

[0095] In this example, a first redeem script (RS1) may have two designated fields for metadata: Metadata1 and Metadata2. Specific examples of Metadata1 and Metadata2 are shown in Table 1 below.

[0096] [Table 1] This example involves providing a pointer to a license in Metadata1 which could be useful, and the size of the license precludes including such details in the metadata (M). Furthermore, because metadata (M) may be publicly available or may be transmitted over insecure networks, it may be desirable for the specific details of the token to be kept secret or hidden for privacy reasons.

[0097] The first 4 bytes of Metadata1 indicate the type of license. For example, the license type may indicate the name of the computer software, such as BobSoftware. In a further example, the license type may indicate the permission type of the license, such as "single user" or "multiple devices" as described above. The next 16 bytes hold the IP address of the location of the actual electronic license file, taking into account IPv6 addresses. Note that in some embodiments, this value may point to the seed of a torrent file, so that the license file is not centralized and can be distributed across the cloud. The next 12 bytes contain data specific to the type of license.

[0098] The first 20 bytes of Metadata2 are a hash of the actual license file using RIPEMD160 to SHA256 applied to the actual contents of the license file. This allows for verification of the transaction against the contract, since the actual license file may be extractable. Note that the license file itself may be completely public (unencrypted and human readable) or encrypted for privacy, depending on the needs of a particular implementation. The remaining 12 bytes of content of Metadata2 may be used depending on the type of license.

[0099] From the example of the first redeem script (RS1) provided above, it can be seen that the issued token needs to be signed by the agent (A) in order to be used. In Table 2, an example of an issued token transaction is given, and for simplicity, the miner's costs are not shown.

[0100] [Table 2] Rows 4-8 of Table 2 represent the input to the transaction, which is the first virtual currency amount (C1) to be included in the issued token (i.e., "tokenized"). In this example, the first virtual currency amount (C1) is the result of a previous transaction (ID-110) that moved the first virtual currency amount to the interest of the agent (A), and therefore the output script (Redeem Script ID-110) of the previous transaction (ID-110) contains the agent's public key (PA). Thus, to unlock this previous output, the script (Redeem Script ID-110) needs to be signed by the first user's private key (VA). Finally, row 8 of Table 2 indicates that the first virtual currency amount (C1) is the first output in this transaction (ID-600).

[0101] Lines 9-13 of Table 2 represent the first (and only) output of a transaction (ID-600), in this case an issued token being created and returned to the agent. Line 10 shows the output value, which is a first cryptocurrency amount (C1). Line 11 shows the output script, which includes "<hash of redeem script>" as used in the P2SH method of the Bitcoin protocol. In this example, the redeem script is the first redeem script (RS1) of the format described above.

[0102] The output of the transaction (ID-600) shown in Table 2 is then recorded in the P2P distributed ledger 14 along with a first data output (O1). In particular, the first data output (O1) may include an indication of the first cryptocurrency amount (C1) moved in the transaction. The first data output (O1) may further include a hash of the first redeem script (RS1).

[0103] For example, in a subsequent transaction of the first virtual currency amount (C1), such as a transfer of tokens to the first user 23 or the second user 24, the script (e.g., input ScriptSig of the subsequent transaction) for unlocking the first virtual currency amount (C1) may be: Sig-VA Sig-VU1<OP_1 PA PU1 Metadata1 Metadata2 OP_4 OP_CHECKMULTISIG> where Sig-VU1 indicates the signature of the first user 23. Note that the above script requires only one signature from the agent (A) or the first user 23 to unlock the first virtual currency amount (C1).

[0104] The issued token may be transferred to another user by a second redeem script (RS2). [Second Redeem Script] Tokens associated with computer software and licenses may be transferred from the agent (A) to another user, such as the first user 23 or the second user 24. In one example, the transfer of tokens may be represented as granting the user access to the computer software or license. The transfer may be accomplished by a second redeem script (RS2).

[0105] In one example, an agent (A) wishes to transfer an issued token to a first user 23. The first user 23 may represent, for example, a vendor of computer software.

[0106] In this example, the second redeem script (RS2) may be based on the metadata (M), an agent public key (PA) associated with the agent (A) and a first user public key (PU1) associated with the first user 23.

[0107] The second Redeem Script (RS2) is <OP_1 PA PU1 Metadata1 Metadata2 OP_4 OP_CHECKMULTISIG> It may take the form of:

[0108] In this example, the second redeem script (RS2) has the same two metadata fields as the first redeem script (RS1). The second redeem script (RS2) also has an agent public key (PA) associated with the agent and a first user public key (PU1) associated with the first user.

[0109] It can be seen from the above example of the second redeem script (RS2) that the transferred token needs to be signed by the agent (A) or the first user 23 in order to be used. An example of a transaction for the transfer of an issued token is provided in Table 3, where for simplicity the miner's costs are not shown again.

[0110] [Table 3] Similar to Table 2, rows 4-8 of Table 3 represent the input for transaction (ID-610). In this example, the input is the issued token, i.e., the output of transaction (ID-600) shown in Table 2. It can be seen that the redeem script in row 7 corresponds to the redeem script of the issued token, i.e., the first redeem script (RS1). Therefore, to unlock the output of transaction (ID-600), the first redeem script (RS1) needs to be signed by the agent's public key (PA).

[0111] Lines 9-13 of Table 3 represent the output of the transaction (ID-610), in this case the issued token being moved to the agent (A) or first user 23 (U1). Line 10 shows the output value, which is the first cryptocurrency amount (C1). Line 11 shows the output script, which includes "<hash of redeem script>" as used in the P2SH method of the Bitcoin protocol. In this example, the redeem script is a second redeem script (RS2) of the format described above.

[0112] The output of the transaction (ID-610) is then recorded in the P2P distributed ledger 14 along with a second data output (O2). The second data output (O2) may include an indication that the first cryptocurrency amount (C1) from the first data output (O1) should be moved in the transaction. The second data output (O2) may further include a hash of the second redeem script (RS2). [Controlling Contract Execution] Smart contracts built on the blockchain can be enforced through logic embedded directly into Bitcoin transactions (i.e., within lock / unlock scripts) and / or through external computer-based applications. Such external computer-based applications may be referred to as "agents," "oracles," or "bots." Additionally, some contract terms can be enforced through other Bitcoin transaction elements, such as the nLockTime field.

[0113] The present disclosure relates to controlling the execution of contracts by providing that a contract (e.g., a license) remains valid as long as there is a valid unspent transaction output (UTXO) on the blockchain that represents the contract. It will be appreciated that this unspent state may be affected and changed as a result of various mechanisms (e.g., programmed computational agents) whose behavior is controlled by conditions or provisions in the contract itself. For example, a contract may specify that it will expire on a particular date or when a particular value reaches a specified threshold.

[0114] This principle of using unspent transaction outputs to represent a contract can be used in combination with other features such as cryptography. This allows for complex scenarios and activities to be realized. Effectively, the context in the unsigned transaction output UTXO and associated metadata in the script that allows it to be used allows the transaction to act as a pointer or reference to an off-chain repository that contains the formal details of the contract. Here, off-chain means that it is not part of the blockchain itself. This provides a mechanism by which anyone can determine if a contract has ended or is still valid / open by looking at the blockchain. When a contract ends, it is recorded on the blockchain as an output used in the transaction and is available for public inspection. The blockchain transaction becomes a permanent, immutable and public record of the existence and current state of the contract.

[0115] The method 800 as illustrated by FIG. 8 includes storing (810) an agreement in a computer-based repository, the agreement relating to a license between a first user (U1) and a second user (U2). The computer-based repository (which may also be called a "registry" or "register") may be implemented in a variety of ways, including, for example, a distributed hash table (DHT). A hash of the agreement (e.g., license) may be generated and stored as metadata in a blockchain transaction, which may serve as a lookup key to reference the agreement from the blockchain. A reference to the location of the agreement is also provided in the transaction metadata. For example, a URL for the repository may be provided. The metadata is open for public viewing, but the agreement itself may be unprotected or partially protected.

[0116] Standard Bitcoin features such as CheckLockTimeVerify (CLTV) may allow a contract to have a formal automatic expiration at some point in the future. The use of the blockchain allows this expiration to be a secure (immutable) subject of public record. This concept, combined with the use of multiple cryptographic keys described below, allows the CLTV model to automatically roll-on or renew contracts if not explicitly cancelled.

[0117] The method 800 also includes receiving (820) a transaction including a transfer of tokens from the agent (A) to the first user (U1) or the second user (U2) over the communications network, the transaction having metadata including an identifier indicating where the agreement is stored.

[0118] The use of deterministic sub-keys, in combination with the tokenization mechanisms described herein, allows sub-agreements or schedules to be created for an agreement.

[0119] Furthermore, the use of off-block computational agents (also known as "oracles") allows contracts to be conditionally configured and modified by trusted third parties, meaning that the actions of the agents can be influenced by conditions (e.g., "IF" statements) provided within the contract's definition. [Key terms] The following terms may be used herein: Contract Issuer This entity represents the actor responsible for novating a contract onto the blockchain. Stakeholders Such an entity represents an actor that needs to determine whether a particular contract still exists. Repository This entity represents a place to secure / store a structured representation of the agreement that a blockchain smart contract references. Contracting Party The entity represents the counterparty to a particular contract. Note that in many cases the entity does not exist. ·contract It is a structured document or file that is stored in a repository and referenced from the blockchain. A contract can be any type of contract or agreement. It may include, for example, a financial contract, a title deed, a service agreement, etc. A contract can be public or private in terms of its content. A contract is formalized in that it is expressed in a structured way using a coding scheme. [Contract model] The basic elements of the contract model are: A coding scheme that allows the complete description of any type of contract. The scheme may be a new construct or may make use of existing facilities such as XBRL, XML, JSON, etc. DFA (Deterministic Finite Automata) for realizing fully definable contracts within the coding scheme. This is A collection of parameters and a location that is the source of these parameters ○A set of state definitions A set of transitions between states, including the triggers for the transitions and the rules to follow during the transitions Rule definition table It consists of: Definition of parameters specific to this instance of the contract Mechanisms for securing and protecting contracts A “browser” to allow contracts to be made human-readable in formal legal language "Compilers" for converting coding methods into scripts such as oracle code and / or Bitcoin script [Fulfillment of the contract] Once a contract is registered in a computer-based repository, its associated address, such as its URL and hash, can be used as metadata within a blockchain transaction to associate the controlling contract with the transaction on-chain. This can be accomplished in a variety of forms, but suitable encoding schemes are provided in full in the section entitled "Encoding Schemes".

[0120] There are several different ways in which the DFA contained within the contract definition can be realized. As a blockchain transaction or sequence of transactions. There are several separate white papers covering how to realize various forms of DFA directly within the Bitcoin scripting language. As an agent-based (e.g., oracle) process or series of processes. The following section "Exemplary Computational Agents for Use with the Invention" describes a basic process for defining and executing an agent suitable for monitoring the blockchain and possibly other external sources. As an instruction set for a smart wallet. In this context, a smart wallet is effectively just a local oracle process capable of handling certain contractual conditions such as the allocation of transaction inputs to blockchain transactions.

[0121] Note that a given contract definition can be realized as a combination of the above three mechanisms. Each contract state transition is effectively a separate realization. There are several ways to create an realization from a contract definition, including the creation of the associated transactions / code. [Disclosure of the existence of the contract] To publish the existence of a contract (or a defined element within a contract), a transaction (involving a movement of tokens from an agent (A) to a first user (U1) or a second user (U2)) is published to the blockchain using a pay-to-script hash address (P2SH). A P2SH transaction requires the recipient to provide a script that matches the script hash and data that allows the script to be evaluated as authentic for the transaction to be used. For embodiments of the present disclosure, the pay-to-script hash (P2SH) is readily determinable from the issuer of the contract (e.g., the first user (U1) or the second user (U2)) and the metadata of the contract.

[0122] This output remains in the UTXO list on the blockchain (i.e. the transaction is still unspent), indicating the validity of the contract, which is contained within the metadata itself: the contract is considered complete once the output has been spent. [Sub-agreement / conditions] A sub-agreement is an agreement that is directly related to an existing agreement. A condition is a clause within an existing agreement that must be publicly realized to fulfill the contractual promise. According to embodiments of the present disclosure, both sub-agreements and conditions can be realized in the same way, i.e., as an agreement realized as a UTXO with a deterministic redemption script address. In both cases, an entity is considered complete once the UTXO has been spent (in the case of a condition, this indicates that the condition has been satisfied).

[0123] There are several mechanisms available for creating a definitive address for a condition or sub-agreement. - Derive a new public key using the seed information Create and publish sub-agreements in the repository with reference to the master agreement and use this as a metadata reference Add terms / sub-agreement references to metadata of existing agreements [Securing the contract] The formal representation of the contract (i.e. a document or file specifying the contents of the contract) is in all cases published on the blockchain where a public record of the contract’s existence is contained in a metadata record (see section “Encoding” for details on the specific metadata structure), but can be secured in various ways depending on the formal requirements of the specific contract.

[0124] From this blockchain record, an authorized entity can know the location of the formal representation along with its hash to determine that the transaction has been made public and has not been modified.

[0125] However, the formal representation itself can be made more secure through several methods. The document repository itself can provide access control mechanisms; · The contract itself can be secured through standard encryption techniques that limit access to the entity in question through access to the associated decryption key. [Termination of Contract] Since the blockchain provides a permanent and immutable record of transactions, a contract cannot be terminated by simply deleting the associated contract document. This means that the secure repository needs to have the same storage and persistence rules as the blockchain itself, supported through some standard mechanism. This means that the solution needs to provide a mechanism for detecting the expiration of contracts that initiate blockchain records directly.

[0126] This is handled through the use of UTXOs that represent the contract. For some contract types, the expiration time of the contract can be published at the same time as the publication of the contract itself. Effectively, two transactions are created, one to publish the contract and obtain a transaction output that represents the contract, and a second one that consumes that output. This second transaction has CheckLockTimeVerify set to consume the output at a given future date (representing the end of the contract).

[0127] This automatic spend can be extended to support roll-on of a contract (e.g. a contract that automatically extends for another 12 months if not cancelled). In this situation, the UTXO is spent, sending it to a “new” roll-on contract.

[0128] The method 800 also includes querying the peer-to-peer distributed ledger to determine if the transaction has at least one unspent output (UTXO) (830). The process of querying the peer-to-peer distributed ledger involves checking the blockchain to see if the UTXO associated with the contract has been spent. If the UTXO is still unspent, the contract remains valid. If the UTXO is still unspent but a locktime transaction is pending, this determines the expiration time of the contract. If the UTXO has been spent, the contract is complete in some respect.

[0129] The process of querying the peer-to-peer distributed ledger (830) assumes that an interested party (e.g., an agent, a first user (U1) or a second user (U2)) is aware of the transactions governing the contract through some other route (typically, it is either the contract issuer or the contract counterparty). However, any entity with access to the contract document and knowledge of the contract issuer may not be able to know the transaction. Derive redemption scripts for UTXO transactions, Scan the blockchain to find UTXOs with matching redemption script hashes; This can be checked by:

[0130] In another embodiment of the present disclosure, querying the peer-to-peer distributed ledger (830) is performed as part of an automated polling process whereby the blockchain is scanned at predetermined time intervals to determine whether a transaction has at least one unspent output (UTXO) (i.e., to determine whether the transaction remains unspent).

[0131] The method 800 also includes determining (840) whether to modify the execution of the contract in response to querying the peer-to-peer distributed ledger. The determining step (840) includes terminating the contract if at least one unspent output (UTXO) cannot be identified from the peer-to-peer distributed ledger or maintaining the contract if at least one unspent output (UTXO) is identified from the peer-to-peer distributed ledger. It should be understood that the determining step (840) may form part of an automated process. For example, a particular license for computer software may require payment periodically (e.g., monthly or yearly) or may be designed to run only at certain times. In each case, the software needs to be capable of polling the peer-to-peer distributed ledger and acting accordingly (e.g., requiring payment from a user to maintain an active license for the computer software). It may also be possible to have the software's ability to execute conditionally with respect to other external conditions, in which case the software may poll an oracle. If geo-lockout (i.e., geographical activation restrictions) is required, the user's IP address can be hashed and used to create another field in the distributed hash table.

[0132] Alternatively or additionally, a license may be due to expire on a given date, in which case the contract transaction may be formatted such that it is usable by the signature of an oracle (or agent (A)), and other transactions are formatted with a lock time set to the expiration date that automatically refunds the unspent output (UTXO) of the transaction to the oracle (or agent (A)).

[0133] If at least one unspent output (UTXO) cannot be identified from the peer-to-peer distributed ledger, the contract issuer (e.g., agent or vendor) or the contract counterparty (e.g., licensee) may wish to close the existing contract (i.e., terminate the license for the computer software, etc.). The instigator of the closure (in most cases, the computer software vendor or an agent (A) for the vendor) checks the blockchain (per step 830 of method 800) to determine if the contract has been canceled by verifying whether the previous UTXO has been spent. If so, the contract is considered to be closed and the process ends. However, it should be understood that if at least one unspent output (UTXO) cannot be identified from the peer-to-peer distributed ledger, the user (e.g., licensee) may be connected to the vendor's server via a distributed hash table (DHT) and given the opportunity to, for example, make a payment to renew the license.

[0134] If there is an existing closure transaction, the instigator simply signs the transaction and submits it to the blockchain. If there is no existing closure transaction, the instigator creates a transaction where the transaction inputs are the UTXOs of the last contract, and the unlock script are their signatures, metadata associated with the contract, and the public key.

[0135] Once the transaction is confirmed on the blockchain, it becomes public knowledge that the contract is closed (although only the participants know the specific reasons why).

[0136] In Table 4, an example of a transaction for terminating a contract (e.g., a license) by spending at least one unspent output (UTXO) is provided, and for simplicity, miner fees are again not shown.

[0137] [Table 4] Similar to Table 3, rows 4-8 of Table 3 represent the inputs for transaction (ID-610). In this example, the inputs are the output of a 1-of-4 multi-signature P2SH transaction, i.e., transaction (ID-610) shown in Table 3. It can be seen that the redeem script in row 7 corresponds to the redeem script of the 1-of-4 multi-signature P2SH transaction, i.e., the second redeem script (RS2). Therefore, to unlock the output of transaction (ID-610), the second redeem script (RS2) needs to be signed by either the agent's public key (PA) or the first user's public key (PU1).

[0138] Rows 9-13 of Table 3 represent the outputs of transaction (ID-620), which in this case represent that an unspent output (UTXO) was spent (i.e., the cryptocurrency amount (C1) was paid back to agent (A) or the oracle). Row 10 shows the output value, which is the first cryptocurrency amount (C1). [Identifier indicating location of computer software or license] As mentioned above, the data (D1) or license may comprise an identifier indicating the location of the computer software or license, respectively.

[0139] In one example, the identifier may be determined independently of the data (D1) or the license and remain separate for the data (D1) or the license. The identifier may further be assigned to the value of a key-value pair together with the data (D1) and the first hash value (H1) as described above in method 100. In this manner, the identifier may be included in the value field of the message put(key,value) and transmitted to participating nodes in the DHT 13 as described above.

[0140] In one example, the location identifier may comprise a URL of an object on the internet. In another example, the location identifier may comprise an address of a repository such as a hash table or DHT 13. In yet another example, the location identifier may comprise an address of a computer-based repository such as a server, database or storage facility provided on a computer-based resource such as a data store 17 associated with the first processing device 21 of the first node 3.

[0141] 6 illustrates a method 500 for determining a location of computer software or a license. The method 500 includes determining (510) metadata (M) from a first redeem script (RS1). As described above, the metadata (M) may be embedded in one or more of the 15 locations available for the public key in the first redeem script (RS1).

[0142] In the P2SH method of the Bitcoin protocol, when the output of a transaction is used in a subsequent transaction, the redeem script becomes visible in the subsequent transaction. As described above with reference to Table 2, the transaction (ID-600) of the issued token is redeemed to the agent (A). In this manner, the agent (A) may use this issued token to publish the first redeem script (RS1). Thus, the metadata (M) based on the second hash value (H2) is visible on the P2P distributed ledger 14. In this manner, the second hash value (H2) can be extracted (520) from the metadata (M) in the first redeem script (RS1). In one example, the value associated with the key of the key-value pair can be extracted from the DHT 13 using the request message get(key).

[0143] The method 500 further includes transmitting (530) the second hash value (H2) over the communications network 5 to a processor associated with a participating node of the DHT 13. As discussed above, the second hash value (H2) may be the value of a key-value pair. Also as discussed above, the value for a given key may be derived by providing a message including the key to any participating node of the DHT 13. Thus, in examples where an identifier is included in the value field of the key-value pair, the method 500 may determine (540) an identifier indicative of the location of the computer software or license from a processor of the participating node. [Processing device] As mentioned above, the first node 3 and the second node 7 may be electronic devices such as computers, tablet computers, mobile communication devices, computer servers, etc. The electronic devices may comprise processing devices 21, 27, a data store 17 and a user interface 15.

[0144] FIG. 7 shows an example of a processing device 21, 27. The processing device 21, 27 may be used in the first node 3, the second node 7 or other nodes not shown. The processing device 21, 27 includes a processor 1510, a memory 1520 and an interface device 1540 that communicate with each other via a bus 1530. The memory 1520 stores a computer software program including machine-readable instructions and data for implementing the above-mentioned methods 100, 500, and the processor 1510 executes instructions from the memory 1520 for implementing the methods 100, 500. The interface device 1540 may include a communication module that enables communication with the communication network 5 and, in some examples, with peripherals such as the user interface 15 and the data store 17. It should be noted that the processing device 1510 may be an independent network element, but the processing device 1510 may also be part of other network elements. Furthermore, some functions performed by the processing device 1510 may be distributed among multiple network elements. For example, the first node 3 may have a number of processing devices 21 for executing the methods 100, 500 in a secure local area network associated with the first node 3.

[0145] When this disclosure describes a user, employer, employee, issuer, merchant, provider, or other entity performing a particular action (including signing, issuing, determining, calculating, sending, receiving, creating, etc.), such words are used for ease of description, and it should be understood that these actions are performed by computing devices operated by these entities.

[0146] It will be understood by those skilled in the art that numerous variations and / or modifications may be made to the above-described embodiments without departing from the broad general scope of the present disclosure, and the present embodiments are therefore to be considered in all respects as illustrative and not restrictive.

[0147] (Appendix 1) 1. A computer-implemented method for controlling execution of a contract, comprising: storing a contract in a computer-based repository, the contract relating to a license between a first user and a second user; receiving a transaction involving a transfer of a token from an agent to the first user or the second user over a communications network, the transaction including metadata including an identifier indicating where the agreement is stored; querying a peer-to-peer distributed ledger to determine if the transaction includes at least one unspent output; determining whether to modify execution of the contract in response to querying the peer-to-peer distributed ledger; The method according to claim 1, (Appendix 2) 2. The method of claim 1, wherein the transaction further includes a deterministic redemption script address. (Appendix 3) 3. The method of claim 1 or 2, wherein the redeem script address is a pay-to-script hash (P2SH) address. (Appendix 4) The determining step includes: terminating the contract if the at least one unspent output is not identifiable from the peer-to-peer distributed ledger; or maintaining the agreement if the at least one unspent output is identified from the peer-to-peer distributed ledger. 4. The method of any one of claims 1 to 3, comprising: (Appendix 5) 5. The method of claim 4, wherein terminating the contract comprises broadcasting a further transaction to use the at least one unspent output. (Appendix 6) 6. The method of claim 5, wherein in the step of broadcasting the further transaction, the further transaction includes instructions to use the at least one unused output at specified data and / or time. (Appendix 7) The further transaction is an input, the at least one unused output; a redeem script including the signature, the metadata, an agent public key associated with the agent, and a first user public key associated with the first user; 7. The method of claim 5 or 6, comprising: (Appendix 8) The said contract: at least one condition regarding the transaction of the license between the first user and the second user; and at least one action, the execution of which depends on the evaluation of said condition; 8. The method of any one of claims 1 to 7, further comprising: (Appendix 9) The metadata includes: an address or representation of the address at which the agreement is stored in the computer-based repository; and / or 9. The method of any one of claims 1 to 8, comprising a hash of the contract. (Appendix 10) The step of querying the peer-to-peer distributed ledger further comprises: 10. The method of any one of claims 1 to 9, further comprising checking whether the contract has terminated by determining whether the at least one unspent output is present in a list of unspent transaction outputs on the peer-to-peer distributed ledger. (Appendix 11) The method of any one of claims 1 to 10, wherein the agreements are stored in a distributed hash table. (Appendix 12) 12. The method of any one of claims 1 to 11, wherein the contract comprises a deterministic finite automaton that implements the contract. (Appendix 13) 13. The method of claim 12, wherein the deterministic finite automaton is defined using an encoding scheme. (Appendix 14) generating a sub-key for a previous key associated with the agreement; generating a further redeem script including the subkey, the location of the agreement and a hash of the agreement; paying an amount of virtual currency to said further redeem script; 14. The method of any one of claims 1 to 13, further comprising updating the contract by executing: (Appendix 15) generating a sub-agreement derived from the agreement; The sub-agreement is associated with a deterministic address; utilizing a new public key derived using the seed; storing the sub-agreement in the computer-based repository along with a reference to the agreement; broadcasting a subagreement transaction including a reference to the agreement onto the peer-to-peer distributed ledger; adding a reference to the sub-agreement to the metadata associated with the agreement; 15. The method of any one of claims 1 to 14, wherein the method is generated by executing the (Appendix 16) The license between the first user and the second user comprises: Computer software; Digital media, including music, video and e-books; 16. The method of any one of claims 1 to 15, wherein said method further comprises one or more of the following: (Appendix 17) 17. The method of any one of claims 1 to 16, wherein the peer-to-peer distributed ledger is a blockchain. (Appendix 18) 18. The method of any one of claims 1 to 17, wherein the virtual currency is Bitcoin. (Appendix 19) A computer software program having machine readable instructions for causing a processing device to implement the method of any one of claims 1 to 18. (Appendix 20) A computer system for controlling execution of a contract, comprising: storing a contract in a computer-based repository, the contract relating to a license between a first user and a second user; receiving a transaction comprising a transfer of a token from an agent to the first user or the second user over a communications network, the transaction comprising metadata including an identifier indicating where the agreement is stored; Querying a peer-to-peer distributed ledger to determine if the transaction includes at least one unspent output; determining whether to modify the execution of the contract in response to querying the peer-to-peer distributed ledger; A system having a processing device configured to:

Claims

1. 1. A computer-implemented method for controlling execution of a contract, comprising: storing a contract in a computer-based repository, the contract relating to a license between a first user and a second user, the contract defining a condition that can be evaluated to true or false; receiving a transaction involving a transfer of a token from an agent to the first user or the second user over a communications network, the transaction including metadata including an identifier indicating where the agreement is stored; querying a peer-to-peer distributed ledger to determine whether the transaction includes at least one unspent output; determining whether to modify execution of the contract in response to querying the peer-to-peer distributed ledger; The method according to claim 1,

2. The method of claim 1 , wherein the transaction further comprises a deterministic redemption script address.

3. The method of claim 1 or 2, wherein the contract is a smart contract.

4. The determining step includes: terminating the agreement if the at least one unspent output cannot be identified from the peer-to-peer distributed ledger; or maintaining the agreement if the at least one unspent output is identified from the peer-to-peer distributed ledger.

4. The method according to claim 1, further comprising:

5. 5. The method of claim 4, wherein terminating the contract comprises broadcasting a further transaction to use the at least one unspent output.

6. 6. The method of claim 5, wherein in the step of broadcasting a further transaction, the further transaction includes an instruction to use the at least one unused output at a specified data and / or time.

7. The further transaction is an input, the at least one unused output; a redeem script including the signature, the metadata, an agent public key associated with the agent, and a first user public key associated with the first user; The method of claim 5 or 6, comprising:

8. The said contract: at least one condition regarding the transaction of the license between the first user and the second user; and at least one action, the execution of which depends on evaluation of said condition; 8. The method according to claim 1 , further comprising defining:

9. The step of querying the peer-to-peer distributed ledger further includes:

9. The method of any one of claims 1 to 8, comprising checking whether the contract has terminated by determining whether the at least one unspent output is present in a list of unspent transaction outputs of the peer-to-peer distributed ledger.

10. The agreements are stored in a distributed hash table.

10. The method according to any one of claims 1 to 9.

11. The method of claim 1 , wherein the contract comprises a deterministic finite automaton that implements the contract.

12. The method of claim 11 , wherein the deterministic finite automaton is defined using an encoding scheme.

13. The deterministic finite automaton is (i) a blockchain transaction or series of transactions; (ii) an agent-based process or series of processes; (iii) Instruction set for smart wallets 13. The method according to claim 11 or 12, implemented as at least one of the following:

14. generating a sub-key for a previous key associated with the agreement; generating a further redeem script including the subkey, the location of the agreement, and a hash of the agreement; paying an amount of virtual currency to the further redeem script; 14. The method of claim 1, further comprising updating the contract by executing:

15. generating a sub-agreement derived from the agreement; The sub-agreement is associated with a deterministic address and: utilizing a new public key derived using the seed; storing the sub-agreement in the computer-based repository along with a reference to the agreement; broadcasting a subagreement transaction including a reference to the agreement onto the peer-to-peer distributed ledger; adding a reference to the sub-agreement to the metadata associated with the agreement; 15. The method of claim 1 , wherein the method is generated by executing:

16. The license between the first user and the second user comprises: Computer software, and Digital media, including music, video, and e-books; 16. The method according to claim 1 , wherein the first and second inputs are connected to a first input port.

17. 17. The method of any one of claims 1 to 16, wherein the peer-to-peer distributed ledger is a blockchain.

18. 18. The method of any one of claims 1 to 17, wherein the virtual currency is Bitcoin.

19. A computer software program having machine readable instructions for causing a processing device to implement the method of any one of claims 1 to 18.

20. A computer system for controlling the execution of a contract, the computer system having a processing device, the processing device is configured to store a contract in a computer-based repository, the contract relating to a license between a first user and a second user, the contract defining a condition that can be evaluated to true or false; the processing device is configured to receive a transaction comprising a movement of a token from an agent to the first user or the second user over a communications network, the transaction comprising metadata including an identifier indicating where the agreement is stored; the processing device is configured to query a peer-to-peer distributed ledger to determine whether the transaction includes at least one unspent output; The processing device is configured to determine whether to modify execution of the contract in response to querying the peer-to-peer distributed ledger.

Images