Blockchain-based universal tokenisation system

Abstract

To provide a method with respect to creating, redeeming, and transferring tokens associated with tokens on a peer-to-peer distributed ledger.SOLUTION: This method includes metadata associated with a token in a redeem script and the redeem script is associated with a transaction on a peer-to-peer distributed ledger. One aspect of the invention provides a method of issuing and / or transferring a token, comprising the steps of generating a blockchain transaction (Tx) having an output (Tx O) related to a quantity such as Bitcoin and a hash of a redeem script. The redeem script comprises metadata which in turn comprises a token. The token is a representation of, or a reference to, a tokenised entity. The redeem script also comprises at least one (preferably two or more) public cryptographic keys. The metadata is provided in the redeem script at a location which is designated in an underlying blockchain protocol as a location for a cryptographic key.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure generally relates to solutions for the control and / or transfer of assets, or the transfer of ownership of assets. In particular, it relates to a method of generating, transferring, and redeeming tokens representing assets. The present disclosure has particular applications in creating tokens related to transactions on a peer-to-peer distributed ledger, such as the Bitcoin blockchain. Tokens can represent contractual rights, smart contracts, or other forms of assets.

Background Art

[0002] Commercial transactions may involve the transfer of property rights. Such rights can include real estate, or personal property (including both tangible and intangible property). Additionally, a contract between parties may include contractual rights that bind both parties. In the digital economy, there can be an expectation for transactions to be executed in a timely manner and on a wide scale. This expectation, along with practical limitations, refers to traditional forms of transferring property, such as the physical delivery of documents representing a contract, securities, etc., or the tangible assets themselves that have no value. More recently, the blockchain has been used for the transfer of digital assets.

[0003] A blockchain is an electronic ledger implemented as a computer-based, decentralized, distributed, peer-to-peer system that builds blocks which in turn build transactions sequentially. Each transaction (Tx) is a data structure that encodes the transfer of control of digital assets between participants in a blockchain system. Each block contains the hash of the previous block, and the blocks are chained together to create a permanent and immutable record of all the transactions written to the blockchain from the beginning. Transactions contain small programs known as scripts embedded within their inputs and outputs that specify how and by whom the outputs of a transaction can be accessed. On the Bitcoin platform, these scripts are written in a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "validated". Network nodes (miners) perform work to ensure that each transaction is valid and that invalid transactions are rejected from the network. The software client installed on a node performs this validation work on unspent transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true (TRUE), the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, i) it must be validated by the first node that receives it - if the transaction is validated, the node relays it to other nodes within the network, ii) it is added to a new block built by a miner, and iii) it is mined, i.e., added to the public ledger of past transactions.

[0005] In the implementation of encryption, blockchain technology is the most widely known, but both the use of data that can be stored on the blockchain for Bitcoin's encryption security system and new systems are beginning to be considered. For automated tasks and processes regardless of the field, if the blockchain can be used, it can be very advantageous. Such solutions would be more versatile in such applications and at the same time be able to take advantage of the benefits of the blockchain (e.g., permanent recording of events, distributed processing, etc.).

[0006] One area of current research is the use of the blockchain for the implementation of "smart contracts". These are computer programs designed to automate the conditional execution of machine-readable contracts or agreements. Unlike traditional contracts written in natural language, smart contracts are machine-executable programs that contain rules for processing inputs to generate results and execute actions based on those results.

[0007] Another area of interest related to the blockchain is the use of "tokens" (or "colored coins") to represent and transfer real-world or virtual entities via the blockchain. Potentially sensitive or secret matters can be represented by tokens that have no recognizable meaning or value. Tokens can thus be used as identifiers that enable assets to be referenced from the blockchain.

[0008] Discussions of documents, acts, materials, devices, articles, etc. contained in this specification should not be construed as an admission that any or all of these matters form part of the basis of the prior art or are common general knowledge in the relevant field of the disclosure that existed before the priority date of each claim of this application. In this specification, the term "blockchain" is used, including all forms of electronic, computer-based, peer-to-peer, distributed ledgers. These include, without limitation, consensus-based blockchain and transaction chain technologies, permissioned, non-permissioned ledgers, shared ledgers, and variations thereof. A more well-known application of blockchain technology is the Bitcoin ledger, while proposals and developments of other blockchain implementations are also underway. Although Bitcoin can be referred to herein for convenience and explanation, it should be noted that the present invention is not limited to use in the Bitcoin blockchain, and alternative blockchain implementations and protocols are also included within the scope of the present invention. Throughout this specification, the word "comprise", or variations such as "comprises" or "comprising", is understood to mean including the stated element, integer or step, or group of elements, integers or steps, and not to exclude an integer or step, or group of elements, integers, or steps. Summary of the Invention

[0009] An invention as defined in the appended claims is provided. The present invention can provide a solution for the secure control and / or transfer of assets or rights via a blockchain. Additionally or alternatively, it can enable the control and / or transfer of ownership of assets or rights. This can be digital or virtual assets such as smart contracts, or real-world / physical assets. The present invention can use tokenization technology to facilitate this control or transfer. The present invention can enable transfers to be performed in a secure manner that includes the use of cryptographic keys, while not requiring modification of the underlying blockchain protocol.

[0010] The present invention provides, in particular, enhanced optimization of memory usage for electronic transfer, improvement of security and data integrity through the use of hash techniques, improvement of security by eliminating the need for a trusted third party, and improvement of data anonymity. This list of advantages is not limiting or exhaustive.

[0011] The present invention may require the interaction and communication of different individual separate computer-based resources, such as one or more user devices and a distributed computer system (blockchain) configured to execute blockchain-related software and protocols.

[0012] The present invention is a computer-implemented transfer method, including the step of generating a blockchain transaction (Tx) having an output (TxO) related to a digital asset (B1) and a hash (H1) of a redeem script, wherein the redeem script includes metadata including a representation of a tokenized entity, or a token that is a reference to a tokenized entity, and at least one (preferably two or more) public cryptographic keys, and The digital asset (B1) may be an amount such as Bitcoin (quantity: amount). The redeem script may be provided within the lock script of the transaction output TxO. The metadata may be provided to the redeem script at a location specified by the blockchain protocol as the location of the cryptographic key. This method may further include the step of presenting the transaction Tx to the blockchain. In practice, in relation to the token, the cryptocurrency (B1) may be locked on the blockchain. The amount (B1) can only be used (redeemed) when providing a unlocking script that meets the requirements of the lock script of the output TxO. In particular, when hashed, a redeem script that matches the hash provided by the lock script of the TxO needs to be presented. Since the lock script of the output TxO constitutes the hash of the redeem script containing the token (within the metadata), the cryptocurrency (B1) is associated with the token. When presenting the correct unlocking (redeeming) script, the ownership of the cryptocurrency (B1) is transferred to the party or user who redeems it, i.e., it is spent. The terms, "spending", "transferring", "redeeming" or "transferring ownership / control of" may be used interchangeably herein. Also, the term, "user" may refer to either a human user or a machine-based resource. The public key may be associated with the corresponding private key to form a cryptographic key pair. The corresponding private key is required to unlock the transaction output and thus enables the transfer of the digital asset and / or its ownership. The tokenized entity can be stored on or off the blockchain. It can be a digital asset such as a (smart) contract or some other form / type of asset or entity. The token can be provided by the redeem script as a cryptographic key as perceived by or interpreted by the blockchain protocol.Accordingly, the underlying blockchain protocol may not be aware of the tokens and / or other metadata provided in the redemption script. However, the metadata may be interpreted and used as tokens by users involved in the processes of the present invention. Accordingly, the present invention can include embodiments or aspects that enable the issuance of digital tokens to users in a secure manner implemented cryptographically via a blockchain. A corresponding system can be provided, which is configured to execute the method of the above-described embodiments and includes a blockchain network and related nodes.

[0013] Additional or alternative representations, features, or embodiments of the present invention will now be provided. Features described in relation to one or more aspects or embodiments of the present invention may also be used in relation to one or more other aspects or embodiments.

[0014] The present invention can provide a computer-implemented method of creating a first token (T1) by an issuer (I). The first token (T1) can be related to a first quantity (B1) of encrypted, electronic, transferable digital assets.

[0015] In addition to or instead of the above method, the method includes one or more of the following steps: receiving, via a communication network, a request from a first user (A) for a first token (T1); determining the public key (P1A) of the first user, wherein the public key (P1A) of the first user forms an encryption pair with the private key (V1A) of the first user; determining the public key (P1A) of the first user; allocating a first amount (B1) of a digital asset encrypted in relation to the first token (T1) and electronically transferable; determining a first hash (H1) of a first redemption script (RS1), wherein the first redemption script (RS1) includes at least first metadata (MD1) including information associated with the first token (T1), the public key (P1A) of the first user, and a first issuer public key (P1I) associated with the issuer (I), wherein the first issuer public key (P1I) forms an encryption pair with the private key (V1I) of the first issuer; transmitting, via the communication network, a first data output (O1) to a peer-to-peer distributed ledger, wherein the peer-to-peer distributed ledger includes a display of a transaction of the first amount (B1) of the digital asset to the first user (A) and the first hash (H1) for providing the first token (T1) associated with the first amount (B1) of the digital asset and associated with the first user (A) and the issuer (I); and determining a first hash (H1) of the first redemption script (RS1) based at least on first metadata (MD1) including information associated with the first token (T1), and transmitting the first data output (O1) including the first hash (H1) via the communication network. The method is characterized by providing many advantages. First, since the information about the token is firmly embedded in a public ledger such as a blockchain, security of data transmission is provided while avoiding the need for a trusted third party.This is because the trading parties can rely on the details of the related transactions locked in a publicly verifiable way. Also, since the anonymity of the transaction is maintained and the first redeem script is hashed, it is practically difficult to change the value of the metadata without changing the corresponding hash value of the redeem script. The advantage is also that the first metadata is embedded in one or more places available to the public key within the redeem script, so that nodes not suitable for processing the metadata can simply send the redeem script to additional nodes, as opposed to blocking the process. This also improves the computational efficiency of the related transactions. By including a pointer to the terms and conditions of the contract in the metadata, an additional advantage is provided that this information can be stored in an off-chain repository. This allows transactions to be processed without the need to send the entire transaction history, and the details of the related transactions can be reliably verified later, thus reducing the processing volume and memory resources used. Furthermore, control data can be incorporated into the metadata, for example, an access code for a barrier in the case of a token representing a venue ticket, or a travel ticket or voucher can be included. Yet another advantage is that the token can be split, enabling two or more transaction outputs, each of which can be related to tokenized or non-tokenized digital assets.

[0016] The first data output (O1) can facilitate the recording of payments to the script hash transaction.

[0017] In this method, the step of receiving a request from a first user (A) for a token (T) can include receiving an offer or acceptance of a contract. The step of receiving a request from a first user (A) for a token (T) can further include receiving at least one or more contract conditions of the contract.

[0018] The method can further include sending at least one or more contract conditions of the contract to the first user (A).

[0019] The information in the first metadata (MD1) may include at least one or more contract conditions of the contract. The information in the first metadata (MD1) includes information regarding one or more contract types, one or more contract conditions of the contract, pointers to the contract conditions of the contract, and information on how to process the transaction.

[0020] The method may further include recording a first redeem script (RS1) in a data store.

[0021] In the method, the first redeem script (RS1) may be in the following format: <NumSigs MD1 … P1A P1I … NumKeys OP_CHECKMULTISIG> Here, NumSigs is the number of signatures required to redeem the first token (T1), NumKeys is the total number of public key slots in the script, including the metadata and public keys, OP_CHECKMULTISIG is an operation that includes signatures with consecutive public key slots.

[0022] The method includes a step of determining whether a first user (A) has an account (ACA) with an issuer (I) to facilitate a transaction related to a first token (T1). If the first user (A) does not have an account, the method further sends a request to open an account (ACA) for the first user (A) via a communication network. This account (ACA) is related to a pair of cryptographic keys including a first user's private key (V1A) and a first user's public key (P1A) for the first user (A).

[0023] In this method, the step of allocating a first quantity (B1) of a digital asset related to the first token (T1) can include determining a first token value (TV1) of the first token (T1), determining a pegging rate (PR1) for the first token (T1), and determining the first quantity (B1) of the digital asset based on the pegging rate (PR1) and the first token value (TV1).

[0024] In one alternative, the step of allocating a first quantity (B1) of a digital asset (B1) related to the first token (T1) includes determining a minimum threshold (MT1) of the digital asset for the first token (T1) and determining the first quantity (B1) of the digital asset that is greater than or equal to the minimum threshold (MT1) of the digital asset.

[0025] A computer-implemented method of redeeming a first token (T1) associated with a first quantity (B1) of a digital asset, according to the method of creating the above-mentioned first token (T1), the method including the issuer, the issuer receiving a request from the first user (A) via the communication network to redeem the first token (T1), determining the first redemption script (RS1) associated with the first token (T1), receiving the private key (V1A) of the first user, using the private key (V1A) of the first user and the private key (V1I) of the first issuer to sign the first redemption script (RS1) to unlock the first quantity (B1) of the digital asset associated with the first token (T1), and transmitting a second data output (O2) to the peer-to-peer distributed ledger, including a display of a transaction of the first quantity (B1) of the digital asset to the issuer (I) via the communication network.

[0026] In a method of redeeming a first token (T1), the first token (T1) has a token value of a first part (R1) and a second part (R2), a request from a first user (A) to redeem the first token (T1) includes a request to redeem the value of the first part (R1), the method further includes determining the public key (P1A) of the first user and allocating a second amount (B2) of a digital asset associated with a second token (T2), the second token having a second token value (Tv2) based on the second part (R2). The method also includes determining a second hash (H2) of a second redeem script (RS2), the second redeem script (RS2) being based at least in part on at least second metadata (MD2) based on the first metadata (MD1) associated with the first token (T1), the public key (P1A) of the first user, and the public key (P1I) of the first issuer associated with the issuer (I), the public ledger of the second data output (O2) further includes a display of a transaction of at least the second amount (B2) of the digital asset to the first user (A) and the second hash (H2) associated with the second amount (B2) of the digital asset (B2) for providing the second token (T2) associated with the first user (A) and the issuer (I).

[0027] A computer-implemented method by which a third token (T3) is created by an issuer (I) according to the method of creating the above-mentioned first token (T1), wherein the third token is associated with a transfer of a value from the first token (T1), and to create the third token (T3), receiving a request from the first user (A) and / or the second user (B) via the communication network; determining the first redemption script (RS1) associated with the first token (T1); receiving the public key (V1A) of the first user; and signing the first redemption script (RS1) to unlock the first amount (B1) of the digital asset associated with the first token (T1) by the private key (V1A) of the first user and the private key (V1I) of the first issuer. The method further includes determining the public key (P1B) of the second user, wherein the public key (P1B) of the second user forms an encryption pair with the private key (V1B) of the second user; allocating a third amount (B3) of the digital asset in relation to the third token (T3); and determining a third hash (H3) of a third redemption script (RS3), wherein the third redemption script (RS3) is based at least in part on at least third metadata (MD3) associated with the first metadata (MD1) associated with the first token (T1), the public key (P1B) of the second user, and the public key (P1I) of the first issuer. The method further includes sending, via the communication network, a third data output (O3) to the peer-to-peer distributed ledger, wherein the peer-to-peer distributed ledger includes a display of a transaction of the third amount (B3) of the digital asset to the second user (B), and a third hash (H3) for providing the third token (T3) associated with the third amount (B3) of the digital asset and associated with the second user (B) and the issuer (I).

[0028] In a method of creating a third token (T3), the first token (T1) has token values of a first part (R1) and a second part (R2), and the request for creating the third token (T3) includes a request for creating a third token (T2) having a third token value (TV3) based on the first part (R1). The method further includes determining the public key (P1A) of the first user, and allocating a second quantity (B2) of the digital asset associated with the second token (T2), wherein the second token has a second token value (TV2) based on the second part (R2). The method further includes determining a second hash (H2) of a second redeem script (RS2), wherein the second redeem script (RS2) is based on at least partially on first metadata (MD1) associated with the first token (T1), the public key (P1A) of the first user, and the public key (P1I) of a first issuer associated with the issuer (I). In this method, a third data output (O3) for the peer-to-peer distributed ledger further includes a display of a transaction of at least the second quantity (B2) of the digital asset to the first user (A) and the second hash (H2), and the second hash (H1) is associated with the second quantity (B2) of the digital asset and provides the second token (T2) associated with the first user (A) and the issuer (I).

[0029]

[0030] ​In a method of creating a third token, the step of allocating a second quantity (B2) of digital assets may include determining a minimum threshold (MT2) of the digital assets for the second token (T2) and determining a second quantity (B2) of digital assets that is greater than or equal to the minimum threshold of the digital assets for the second token (T2).

[0031] In a method of creating a third token (T2), the second quantity (B2) of digital assets and / or the third quantity (B3) of digital assets includes at least a portion of the first quantity (B1) of digital assets.

[0032] A method of creating a third token (T3) further includes determining a fourth quantity (B4) of digital assets as a transaction fee, and the first data output (O1), the second data output (O2), and the third data output (O3) for the peer-to-peer distributed ledger further include a display of the transaction of the fourth quantity (B4) of digital assets as a transaction fee.

[0033] In the method described above, the peer-to-peer distributed ledger may include a Bitcoin blockchain.

[0034] A computer-implemented method for redeeming a first token (T1) associated with a first quantity (B1) of digital assets defined above, the method comprising the issuer, the issuer receiving a request from the first user (A) via the communication network to redeem the first token (T1), determining the first redemption script (RS1) associated with the first token (T1), transmitting the first redemption script (RS1) via the communication network for signing by the first user (A), receiving, via the communication network, the first redemption script (RS1A) signed by the first user with the private key (V1A) of the first user, signing the first redemption script (RS1A) signed by the first user with the private key (V1I) of the first issuer to unlock the first quantity (B1) of the digital assets associated with the first token (T1), and transmitting, via the communication network, a second data output (O2) to the peer-to-peer distributed ledger including a display of the transaction of the first quantity (B1) of the digital assets to the issuer (I).

[0035] A computer-implemented method by which a third token (T3) is created by an issuer (I) according to the method of creating the above-mentioned first token, wherein the third token is associated with the transfer of a value from the first token (T1), the method comprising: receiving, via the communication network, a request from the first user (A) and / or the second user (B) for creating the third token (T3); determining the first redemption script (RS1) associated with the first token (T1); transmitting, via the communication network, the first redemption script (RS1) for signing by the first user; receiving, via the communication network, the first redemption script (RS1A) signed by the first user with the private key (V1A) of the first user; signing the first redemption script (RS1A) signed by the first user with the private key (V1I) of the first issuer to unlock the first amount (B1) of the digital asset associated with the first token (T1); determining the public key (P1B) of the second user, wherein the public key (P1B) of the second user forms an encryption pair with the private key (V1B) of the second user; allocating a third amount (B3) of the digital asset in relation to the third token (T3); determining a third hash (H3) of a third redemption script (RS3), wherein the third redemption script (RS3) is based at least in part on at least third metadata (MD3) related to the first metadata (MD1) associated with the first token (T1), the public key (P1B) of the second user, and the public key (P1I) of the first issuer; transmitting, via the communication network, a third data output (O3) to the peer-to-peer distributed ledger, wherein the peer-to-peer distributed ledger displays the transaction of the third amount (B3) of the digital asset to the second user (B) and is associated with the third amount (B3) of the digital asset,Transmitting a third data output (O3) including a third hash (H3) for providing the third token (T3) associated with the second user (B) and the issuer (I) to a peer-to-peer distributed ledger.

[0036] The present invention can further provide a tokenization method. It can be implemented using a distributed peer-to-peer network such as a blockchain. Therefore, the known advantageous points of blockchain technology can be used by the present invention. The present invention can provide an improved solution for the secure transfer of data items via a blockchain platform. For example, it can be described as a solution for the efficient and secure transfer of tokens such as blockchain.

[0037] The method can provide a solution for representing a contract for the provision of at least one asset and / or service. The contract may be a transferable contract.

[0038] The present invention is not limited with respect to the nature, type, quantity, etc. of the assets and / or services transferred by the contract. The method can provide a systematic scheme for tokenizing any type of transferable contract.

[0039] The method may include the step of generating a blockchain transaction. The transaction includes two parameters or data items. This data can indicate the following: i) The amount of shares available under the contract (which can be denoted herein as "NumShares"); ii) The amount of transfer units transferred from the sender to at least one recipient (which can be denoted herein as "ShareVal"); iii) A factor for calculating a value relative to the amount of transfer units (which can be denoted herein as the "pegging rate").

[0040] An advantage of the present invention is that it can use encapsulating or representing a contract as a token on a blockchain. This can be achieved using only the three parameters described above. In fact, a contract can be specified using at least these three data items. Since the present invention provides a solution that can be used for any type of transferable contract, a general algorithm can be devised and applied.

[0041] These three data items may be provided as metadata within a transaction. Advantageously, only a small amount (in bytes) of metadata is required to represent any type of contract. Thus, the present invention provides an efficient, effective and moreover powerful mechanism for the transfer of tokens on a peer-to-peer distributed ledger such as a blockchain.

[0042] The data may further include, for example, an indication of the availability of an asset such as goods and / or services provided under the contract. Additionally or alternatively, it may include an indication of the type and / or quantity of the asset or service provided under the contract.

[0043] The transfer may actually include a fourth parameter or data item, which identifies, for example, a particular asset being transferred such as a house or racehorse associated with the transfer.

[0044] The method may further include the step of sending the transfer to at least one recipient (or an address associated with at least one recipient).

[0045] A transaction includes a contract and / or information for accessing the contract or a file containing the contract. This provides the advantage of facilitating the transfer of either the contract or information corresponding to the location of the file containing the contract via the contract or blockchain.

[0046] The transfer may include the hash of the contract. This provides the advantage of a means for verifying the authenticity of the contract.

[0047] The transfer may include at least one cryptographic signature. This provides the advantage of identifying the origin of the transfer.

[0048] The transfer may include at least one locking script and at least one public key. This provides the advantage of preventing redemption by someone other than the intended recipient of the transfer.

[0049] The unit of transfer may be associated with a cryptocurrency and may or may not be associated with Bitcoin. The unit of transfer may be an amount of Bitcoin, and the blockchain may be a Bitcoin blockchain. This provides the advantage of being able to implement the method in existing infrastructure.

[0050] Accordingly, the present invention provides a simple and efficient scheme for securely transferring contracts on a blockchain.

[0051] A computer program includes machine-readable instructions that cause a processing device to execute any one of the above-described methods.

[0052] An apparatus includes a processing device that executes a method according to any one of the above-described methods.

Brief Description of the Drawings

[0053] Examples of the present disclosure are described with reference to the following drawings:

Figure 1

Figure 2(a)

Figure 2(b)

Figure 2(c)

Figure 3(a)

Figure 3(b)

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

DETAILED DESCRIPTION OF THE INVENTION

[0054] Overview of the system A method and system for creating, redeeming, and transferring tokens will now be described. FIG. 1 illustrates a system including an issuer (I) 3, a first user (A) 5, and a second user (B) 7. The issuer (I) 3 that creates the token may be, for example, a bank, another financial institution, a mint, a company, etc. The issuer (I) 3 is associated with a first processing device 13 for executing methods 100, 200, 300 and communicates with a communication network 8. Although the first processing device 13 is shown as a single node, the methods 100, 200, 300 described herein may be executed by a plurality of processing devices 13 or nodes associated with the issuer (I) 3, or may be distributed and executed in one or more steps by different nodes. The issuer (I) may also have an associated data store 11.

[0055] The first user (A) 5 is associated with a second processing device 15 that communicates with the first processing device 13 of the issuer (I) 3 via a communication network 8. The first user (A) 5 requests the creation of a token from the issuer (I) 3, the redemption of the token with the issuer (I) 3, or requests the transfer of some or all of the value of the token to the second user (B) 7.

[0056] The second user (B) 7 is associated with a third processing device 17 that communicates with the first processing device 13 via a communication network 8. In some examples, the second processing device 15 and the third processing device 17 may be computers, mobile communication devices, or other electronic devices used by the first and second users 5, 7, respectively. In another example, the second processing device 15 and the third processing device 17 may be virtual machines accessible by the first and second users via a terminal or other interface.

[0057] A peer-to-peer distributed ledger 9 for recording transactions is also illustrated. The peer-to-peer distributed ledger 9 may be associated with one or more processing devices for receiving and recording transactions. Examples of peer-to-peer distributed ledgers include blockchains, which are distributed databases of transactions based on the Bitcoin protocol. Thus, the processing device 19 associated with the ledger may be the processing device used by the "miner".

[0058] Overview of a transaction containing a token In a non-limiting example, as illustrated in FIG. 2, there are three general types of transactions that include tokens. In this example, the issuer (I) is a financial institution that also manages the electronic wallets of the first user (A) 5 and the second user (B) 7.

[0059] The first type of transaction, shown in FIG. 2(a), involves the generation of a first token (T1) by a first user (A) transferring fiat currency (e.g., $1,000 AUD) to an issuer 3. In the exchange of fiat currency, the issuer (I) “tokenises” a first quantity (B1) such that it has the value of a token and transfers this first quantity (B1) to the first user (A) 5. The first token (T1) can represent a contract, for example, agreeing to redeem it to the bearer of the first token (T1) for a specified fiat currency amount (e.g., $1,000 AUD). As a result, the first token (T1) can be a transferable security. “Cryptocurrency” means an encrypted, electronically transferable digital asset such as Bitcoin without limitation.

[0060] The second type of transaction, as shown in FIG. 2(b), involves the first user (A) 5 redeeming the first token (T1) by the issuer (I) 3. In this transaction, the first quantity (B1) is transferred from the first user (A) to the issuer (I) 3. Next, the issuer (I) 3 sends the value redeemed in the form of fiat currency to the first user (A) 5. The first quantity (B1) transferred to the issuer (I) 3 can be used in other subsequent transactions. Whether the first quantity (B) by the issuer (I) 3 remains “tokenized” or is converted to an “untokenized” cryptocurrency is a choice for the issuer (I) 3.

[0061] As shown in FIG. 2(c), the third type of transaction involves the first user (A) 5 transferring the value of the first token (T1) to the second user (B) 7. In this example, the first quantity (B1) representing the first token (T1) is transferred from the first user (A) 5 to the second user (B) 7. Since the issuer (I) needs to sign a redemption script (described later) to permit the transaction, the issuer (I) 3 is involved in this transaction. The result of this transaction is the second user (B) 7 having the first quantity (B1) with a token value that can be "used" (in the same way as described above) by redeeming with the issuer (I) 3 or transferred to other users.

[0062] In some cases, only a portion of the value of the first token (T1) may be used by the first user (A) 5. This is described as the fourth and fifth types of transactions with reference to FIGS. 3(a) and 3(b). In these examples, the first token (T1) has a total token value including the first portion (R1) + the second portion (R2), and the first user (A) 5 desires to "use" the first portion (R1) and return the second portion (R2) as change.

[0063] In the fourth type of transaction, as shown in FIG. 3(a), the first user (A) 5 has the first quantity (B1) representing the first token (T1) from a previous transaction. Next, the first user (A) redeems the first portion (R1) of the token (T1) by transferring an amount as a token having the value of the first portion (R1), and in return, receives non-fungible currency having a value representing the first portion (RA). Only the first portion (R1) is redeemed, and the remaining second portion (R2) remains with the first user (A) 5. This is shown as the second quantity (B2) as a token having a value representing the second portion (R2). In one example, the second quantity (B2) is a first quantity (B1) less than the amount transferred to the issuer (I) 3.

[0064] The fifth type of transaction is such that, as shown in Figure 3(b), the first user also has a first amount (B1) representing a first token (T1) from a previous transaction. Next, the first user (A) transfers a third amount (B3) to the second user (B) as a token having a value of the first portion (R1), thereby transferring the first portion (R1) of the token (T1). By transferring a third encrypted amount (B3) as a token having a value of the first portion (R1) to the second user (B), the first portion of the token (T1) is transferred. Since only the first portion (R1) is transferred, the remaining second portion (R2) remains with the first user (A). This is shown as a second amount (B2) as a token having a value representing the second portion (R2). In one example, the second amount (B2) and the third amount (B3) are derived from the first amount.

[0065] The above detailed examples of transactions are described from here.

[0066] The first type of transaction - the issuer creates a first token (T1) for the first user (A)

[0067] Non-limiting exemplary applications of the method described herein are that the issuer (I) (e.g., a financial institution) deposits an amount of non-fungible currency (e.g., $1000 AUD), and the issuer (I) similarly creates a first token (T1) representing the value of the deposited non-fungible currency for the first user (A). Depending on the contractual conditions, the first user (A) can redeem the first token (T1) on a future date for the value associated with the deposited non-fungible currency. The contractual conditions may allow the first user (A) to transfer at least a portion of the value of the token to the second user (B). Such contractual conditions may be specific to this token or may be general contractual conditions among users and the issuer (I).

[0068] Overview of the method of creating tokens An example of a method 100 for creating a first token (T1) by a first processing device 13 in an issuer (I) 3 will now be described with reference to FIGS. 2(a) and 4. The method 100 receives 110 a request from a first user (A) 5 for the first token (T1) via a communication network 8. The method also includes 120 determining a public key (P1A) of the first user that forms an encryption pair with a secret key (V1A) of the first user.

[0069] The method 100 includes 130 allocating a first amount (B1) for association with the first token (T1). The method 100 further includes determining a first hash (H1) of a first redemption script (RS1), where the first redemption script (RS1) includes at least first metadata (MD1) including information associated with the first token (T1), the public key (P1A) of the first user, and a first issuer's public key (P1I) associated with the issuer (I), and the first issuer's public key (P1I) forms an encryption pair with a secret key (V1I) of the first issuer.

[0070] The method 100 also includes 150 sending a first data output (O1) to a peer-to-peer distributed ledger via the communication network 8. The first data output (O1) includes a display of a transaction of the first amount (B1) for the first user (A) 5 and the first hash (H1) associated with the first amount (B1) for cryptographic purposes for providing the first token (T1) associated with the first user (A) 5 and the issuer.

[0071] Method 100 can also generate tokens such that the record of the tokens is sent to the peer-to-peer distributed ledger 9. The advantage of recording this transaction on the peer-to-peer distributed ledger 9 is that a recipient such as the first user (A) 5 can verify the existence of the token (T1). Further, at least the first metadata (MD1) containing information related to the first token (T1) is hashed, enabling verification of the transaction (on the public record) with respect to the information related to the token. In one example, the information related to the first token (T1) can be the contract terms of a contract. Thus, including the contract terms in the first redeem script for which the hash value is calculated advantageously provides assurance to the first user (A) 5 (or any other user) that any change will change the first hash (H1), so the contract terms cannot be changed. At the time of creation of the first token (T1), the first hash (H1) is sent to and recorded in the peer-to-peer distributed ledger 9, so later it is not possible (or difficult) to change the contract terms that would provide the same first hash (H1). A detailed example of the issuer (I) 3 creating a token for the first user (A) 5 includes the initial process of registration 400, which will be described hereinafter.

[0072] Method of registration 400 The method of registration 400 will now be described with reference to FIG. 5. Method 100 may include determining whether the first user (A) 5 has an account with the issuer (I). In particular, this may include determining whether the first user (A) 5 has an account suitable for facilitating a transaction related to the first token (T1).

[0073] If the first user (A) 5 does not have an account, the method may further include transmitting 314, via a communication network 8, a request to open an account for the first user. The account opening request may include transmitting to the first user (A) 5 general details of the contractual conditions regarding the account with the issuer (I), and a request to receive the contractual conditions by the first user (A) 5. This may also include transmitting a request for details of the first user (A) 5.

[0074] Furthermore, transmitting a request to open an account may also include transmitting a request to generate an encryption pair including the first user's private key (V1A) and the first user's public key (P1A) for the first user (A) 5. In some examples, this includes transmitting a request to generate the first user's private key (V1A) and the first user's public key (P1A) to another node associated with the issuer (I), whereby, in turn, the other node generates and transmits to the first user (A) 5. In other examples, this may include transmitting a request to generate the first user's private key (V1A) and the first user's public key (P1A) to the first user (A) 5 in a second processing device 15 associated with the first user (A) 5. It should be understood that these keys associated with the first user (A) 5 may be generated by other means or in other means, as long as the first user's private key (V1A) is kept secure and used only for approval with the first user (A) 5.

[0075] The first user (A) 5 receives 714 a request to open an account and then transmits 716 information for opening an account to the issuer (I) 3.

[0076] The registration method 400 may also include creating 316 an electronic wallet associated with the account of the first user (A) 5 and storing the information related to this electronic wallet and the account in a data store 11.

[0077] In some examples, the private key (V1A) of the first user may be stored in an electronic wallet. Ideally, the private key (V1A) of the first user can only be accessed with the approval from the first user (A)5. For example, the electronic wallet can have multiple private keys associated with the first user (A)5, so that when the first user (A)5 can successfully and safely log on to the issuer (I)3 (e.g., in a virtual machine environment or a terminal), the first private key becomes available. The first user (A)5 can read these private keys from the data store 11 for a transaction and then optionally approve the issuer (3) for use. In some examples, the user's private key is not stored in the electronic wallet, but can be recreated by the issuer (I)3 with the approval from each user. In yet another example, the user's private key may be a split key, the electronic wallet has one part, and the user has the remaining part, so that they can be combined to reproduce the private key.

[0078] In another example, the private key (V1A) of the first user may remain separated from the issuer (I), the first processing device 13, and the data store 11. For example, the first user (A)5 can also keep a hard copy of the private key (V1A) of the first user in a safe or secure part of a personal electronic device, computer, or storage device.

[0079] It should be understood that the steps in method 400 may be executed during method 100, for example, after step 110 of receiving a request for the first token (T1) from the first user (A)5.

[0080] In other examples, the method or registration 400 may be executed in advance.

[0081] Detailed method for creating token 100 The method 100 of creating the first token (T1) will now be described in detail with reference to FIGS. 2(A), 4, and 6 (showing methods 100 and 500 respectively executed by the issuer (I) 3 and the first user (A) 5). In this example, creating a token is considered in the context of the first user (A) 5 depositing a cache with the issuer (I) 3 and in exchange receiving a token representing the deposited cache. However, this is a non-limiting example, and it is understood that tokens can be created in the context of other transactions. For example, a token can represent any other contract, transferable certificate, tangible property, etc. For example, in the case of a token representing a venue ticket or a travel ticket or a voucher, it can represent a transferable asset including an access code for a barrier.

[0082] Agreement on contract conditions for the token After or before the method of registration 400, the first user (A) 5 can send a request 510 for the first token (T1). In one example, the first user (A) 5 creates this request by, for example, sending a request to have this amount in the token (T1) by depositing non-convertible currency of $1000 AUD.

[0083] In one example, the request sent by the first user (A) 5 may include the presentation of a contract. This presentation may include one or more contract conditions of the contract. For example, the first user (A) 5 can include in the request that the token related to the deposit of $1000 AUD should have a fixed pegging rate for encryption. For example, the request is that the pegging rate is 1000 satoshis / cent (AUD). Other contract conditions can be included in an offer, such as account management fees, transaction fees, how the token is redeemed, etc.

[0084] As shown in FIG. 6, the first processing device 13 of the issuer (I) receives 110 from the first user (A) 5 via the communication network 8 a first token (T1) and in some cases a request for at least some of the contract terms. The issuer (I) can determine whether to accept the request, make a counter-offer modifying the contract terms of the request, or reject the request 112. The method 100 then includes, at step 112, transmitting 114 the determination result via the communication network 8.

[0085] The first user (A) 5 can then receive via the communication network 8, at step 112, the determination result including acceptance, a counter-offer, or rejection of the request.

[0086] Another example is that a request 510 sent to the issuer (I) simply includes a request for the first token (T1). In this case, the issuer (I) can send an offer including the contract terms to the first user (A) 5. The first user (A) 5 can similarly determine whether to accept the offer, propose a counter-offer, or reject the offer, which is then sent to the issuer (I).

[0087] It should be understood that steps 510, 520, and 110, 112, 114 can be modified to include multiple offers and counter-offers sent and received between the issuer (I) and the first user (A) 5 until they agree.

[0088] In some alternatives, the contract terms are standardized, and by performing the steps in methods 100, 500, the user accepts those contract terms. In one example, the issuer (I) may have a standardized offer regarding tokens for his customers including the first user (A)5. Such an offer for the tokens can also be publicly listed as a public transaction or on the issuer's website, etc. The standing offer may also be provided privately by the issuer (I) to the first user (A)5 via email, through an application, or by logging in on a secure website.

[0089] The contract terms related to the tokens are stored in the data store 11, sent to a third party for record, or torrented.

[0090] Determination of the public key of the first user 120 Method 100 includes step 120 of determining the public key (P1A) of the first user. In one example, the public key (P1A) of the first user may be sent from the first user (A)5 to the issuer (I) via the communication network 8. In another example, the public key (P1A) of the first user may be stored in relation to the data store 11 (which may be received and stored, for example, during the registration of the first user (A)5). Thus, step 120 of determining the public key (P1A) of the first user includes reading the key from the data store 11. In yet another example, the public key (P1A) of the first user may be received from a third party via the communication network 8. The third party may include a trusted third party acting as a public directory, such as a certification authority, etc.

[0091] Allocation of the first quantity related to the token 130 Method 100 includes assigning 130 a first quantity associated with a first token (T1). To record a record of a transaction including the first token (T1) on a peer-to-peer distributed ledger (a blockchain in this example), it is necessary to associate the token with a certain amount of encryption. Next, the quantity is recorded on the peer-to-peer distributed ledger as a transaction from the issuer (I) 3 to the first user (A) 5. In other words, the blockchain transaction Tx is presented to the blockchain network for inclusion in the ledger. Tx can be used to transfer an amount of cryptocurrency (or ownership / control) from one party, for example, the issuer, to another party, for example, the first user.

[0092] The assignment of the first quantity (B1) for the first token (T1) can also be based on a ratio of the value of the token. For example, a pegging rate (PR1) can be specified for the first token (T1). Thus, step 130 of assigning the first quantity (B1) can include determining the first quantity (B1) based on the pegging rate (PR1) and the value of the first token (TV1). As an example for illustration purposes, the pegging rate (RP1) could be 1000 satoshis / cent AUD, and the value of the first token (TV1) could be $1000 AUD. Thus, the first quantity (B1) could be 10,000,000.

[0093] The amount assigned to a token may be affected by some of the following considerations. First, the assigned amount should ideally have a market value (for the purposes of this, the market value itself is assumed to have value in itself without reference to the value of the token), which is less than the value of the token (the "token value"). This is desirable because there is no incentive to use the amount for a value that is more fundamental than the token. This is similar to a cash coin where it is desirable for the face value of the coin to be higher than the metal from which the coin is made, so it is not desirable to melt the coin for its value. In some cases, the value of the token is several times larger than the basic value. However, some tokens may have a fixed or not easily determinable token value. For example, it can also represent a contract for the performance of work where the value changes from day to day. In another example, the contract can also have a value determined on the day it is redeemed.

[0094] Another consideration is that since a peer-to-peer distributed ledger can record cryptocurrency amount transactions, the assigned amount should not be too large relative to the token value or the value of the transaction, such as bearing the cost of a transaction fee. In some cases, the transaction fee is based on the amount in the transaction, and as a result, it may be desirable to maintain the amount for the token at a minimum level.

[0095] On the one hand, the amount assigned in relation to a token cannot be infinitely small. First, a cryptocurrency has a minimum unit amount. For example, Bitcoin has a minimum amount of 1 satoshi (1 Bitcoin (BTC) = 10,000,000 satoshis). Second, a transaction is limited to a minimum size or else it will not be recorded (or the cost of the transaction will be close to or exceed the cost of executing the transaction). This minimum amount is, in some examples, the "dust" limit. Thus, in some examples, assigning an amount for a token must exceed the cryptocurrency minimum threshold (MT1). Therefore, method 100 can include determining a minimum threshold (MT1) suitable for the first token (T1) and determining a first amount (B1) that is greater than or equal to the minimum threshold (MT1). In one example, the minimum threshold (MT1) is 546 satoshis in the case of "Bitcoin".

[0096] Another consideration when allocating an amount to a token is the divisibility of the amount for subsequent tokens. For example, the first token (T1) may have a token value (TV1) of $1000 AUD, and the first user (A)5 may wish to transfer $800 AUD of the token value to the second user (B)7 and keep the remaining $200 AUD token. Such a transaction would involve a transaction of the first token (T1) resulting in a second token (T2) representing the $200 AUD remaining with the first user (A)5 as change, and creating a third token (T3) representing the $800 AUD transferred to the second user (B)7. Thus, as a result of this transfer, there are two tokens, the second token (T2) and the third token (T3), and each of these tokens also needs to have an amount allocated to it. For example, at the "dust" limit, if the first amount (B1) is the minimum, then the total amount needs to be sourced so that each of the newly created tokens is associated with an amount sufficient to satisfy the minimum threshold. Therefore, it may be advantageous to allocate a sufficient amount (B1) to the first token (T1) such that it is sufficient to be divided for use against the expected number of subsequent tokens. In one example, the contract terms may specify the amount, or the minimum value of the token, or the denomination of the token. For example, the contract terms can set $10 AUD as the minimum denomination of the token value. Therefore, allocating the first amount (B1) to the first token (T1) with a token value (TV1) of $1000 AUD may also involve determining the first amount such that it ensures there is sufficient cryptocurrency if the total token value (TV1) is divided into the smallest units. In this example, the token value (TV1) can be divided into 100 subsequent tokens (calculated by $1000 / $10). As a result, the appropriate first amount (B1) is a hundred times the "dust" limit.

[0097] Determination of the first hash (H1) of the first redemption script (RS1) 140 The method further includes determining 140 a first hash (H1) of a first redeem script (RS1). In one example, the hash of a redeem script can be used to provide payment to a script hash (P2SH) address for paying for a script hash transaction. The example includes a hash function used in a P2SH script in Bitcoin. This can include a combination of SHA256 followed by RIPEMD160 thereafter.

[0098] The first redeem script (RS1) is a script that can be used to unlock a first token (T1) and, as will be described later, it includes a transaction of a first amount (B1). When unlocking the first token (T1), certain conditions of the first redeem script (RS1) need to be met to unlock the transaction. In particular, the signatures of a first user (A)5 and an issuer (I) are required. An example of the first redeem script (RS1) will be described hereinafter.

[0099] The first redemption script (RS1) The first redeem script (RS1) is based on at least a first metadata (MD1) including a first token, a public key (P1A) of a first user, and a public key (P1I) of a first issuer.

[0100] (i) Generally, redeem scripts in P2SH As background, payments to a script hash method can take the following form. <NumSigs PubK1 PubK2 … PubK15 NumKeys OP_CHECKMULTISIG> Here, NumSigs is the number "m" of valid signatures required to satisfy the redeem script for unlocking 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). NumKeys is the number "n" of public keys (less than or equal to 15).

[0101] The unlocking of the above redeem script requires at least "m" signatures corresponding to the public keys. In some examples, the order of the public keys is important, and the number "m" of the "n" signatures for signing must be done in order. For example, let "m" be 2 and the number "n" of public keys be 15. If two signatures, Sig1 (corresponding to PubK1) and Sig15 (corresponding to PubK15), are available for use, the redeem script should first be signed by Sig1 followed by Sig15.

[0102] (ii) The first redemption script (RS1) using P2SH Returning to the current example, the first redeem script (RS1) that utilizes P2SH may include at least a first metadata (MD1) in the redeem script. In particular, at least the first metadata (MD1) can be incorporated into one or more of the 15 locations available for the public keys in the redeem script.

[0103] Thus, in one example, the first redeem script (RS1) can take the following form: <NumSigs Metadata1 Metadata2 PubK1 PubK2 NumKeys OP_CHECKMULTISIG> Here, NumSigs is the number "m" of valid signatures required to satisfy the redeem script for unlocking the transaction. Metadata1 and Metadata2 contain metadata taking the place of the public keys. PubK1 and PubK2 are the actual public keys. In one example, PubK1 may be the public key (P1A) of the first user and PubK2 may be the public key (P1I) of the issuer. NumKeys is the total number of positions taken by the metadata and the public keys (and should be 15 or less).

[0104] This advantage is that the metadata is included in the first redemption script (RS1), which is then hashed and the record is included in the peer-to-peer distributed ledger 9. Thus, it would be difficult, if not impossible, to change the value of the metadata without resulting in a change to the corresponding hash of the first redemption script hash (RS1).

[0105] Practical advantages can be illustrated by the following example. The first user (A) 5 and the issuer (I) 3 may wish to enter into a contract under certain conditions. The contract includes the issuer (I) generating a token, whereby certain contract conditions are included in the metadata embedded in the redemption script. The hash of the redemption script is then recorded in the peer-to-peer distributed ledger 9, which becomes a record of a transaction that is difficult or impossible to change. Suppose the issuer (I) tries to deceive the first user (A) 5, for example, by trying to change the conditions and claiming the changed conditions in the contract that was originally agreed upon. The first user (A) 5 can object to this by calculating the hash value of the redemption script with the changed clause in the metadata and then showing that it does not match the redemption script recorded on the peer-to-peer distributed ledger. As a result, including at least information related to the token in the first metadata may help to ensure the integrity of the token.

[0106] The metadata in the redemption script may itself include the hash of other information. For example, if the contract conditions are very long, the hash of the contract conditions can be used to provide shorter metadata.

[0107] The first redemption script (RS1) can be recorded in the data store 11 for redeeming the first token (T1) as a record. In some other examples, the first redemption script may be sent to the first user (A) 5 or a third party.

[0108] Metadata In the current example, the first redemption script (RS1) takes the following form: <2 Metadata1 Metadata2 P1A P1I 4 OP_CHECKMULTISIG>

[0109] Therefore, at least the first metadata (MD1) includes both Metadata1 and Metadata2 that use two places in the redemption script. This is followed by two public keys, the first public key (P1A) and the first issuer's public key (P1I) in sequence. NumSigs is 2, which means that two signatures are required to unlock the transaction.

[0110] Metadata can include information about the token in many ways. As described above, in one example, the contract conditions can be included in the metadata. In another example, the hash of the contract conditions can be included in the metadata. In yet another example, the metadata can include a pointer to a file containing the contract conditions of the contract. In further embodiments, a combination including one or more of the above can be included in the metadata.

[0111] (i) Metadata with a pointer to the contract conditions A specific example of the first metadata (MD1) is described in Table 1 below.

Table 1

[0112] This example contains a minimal amount of information regarding tokens and transactions. This example includes providing a pointer to the contract, which may be useful in cases where the size of the contract excludes such details from being included in the metadata. Moreover, since the metadata is published or transmitted over an unsecured network, it may be desirable to mask or conceal specific details of the token for privacy reasons.

[0113] The first 4 bytes of metadata1 indicate the contract type. For example, the contract type could be for "non-fungible tokens". The next 16 bytes hold the IP address of the location of the actual electronic contract file, taking into account IPv6 addresses. In some embodiments, this value points to the seed of a torrent file so that the contract file is distributed across the cloud rather than being centralized. The next 12 bytes contain data specific to the contract type.

[0114] The first 20 bytes of metadata2 are the hash of the actual contract file using RIPEMD-160 over SHA256 applied to the file. Since the actual contract file is readable, this enables verification of transactions against the contract. The contract file itself may be fully public (unencrypted and human-readable) or encrypted for privacy, depending on the requirements of a particular embodiment. The contents of the remaining 12 bytes of metadata2 can be used depending on the type of the contract.

[0115] (ii) Metadata with key parameters of the token Another specific example of the first metadata (MD1) is described in Table 2 below. [Table 2]

[0116] In this example, some key parameters of the token are included in the metadata. Depending on the key parameters, this can include information related to the token itself or information that can assist in the transfer process. In particular, the bytes assigned to the subfield "ContractTypeData1" in Table 1 above are used to indicate the file name, pegging rate, and transaction type.

[0117] Importantly, in some cases, the issuer (I) 3 can process the token in the transfer without reading the contract file for the key information required to process the transfer. Therefore, including the key parameters in the metadata can greatly assist in processing efficiency.

[0118] In addition to the information described above, other information related to the history of the token or tokens preceding the token may be included. For example, if the first user (A) 5 wants to redeem a part of the first token (T1), the issuer (I) creates a second token (T2) to represent the value of the remaining part, and the issuer can embed information in the metadata to associate the second token (T2) with the first token (T1). This can help to know the whereabouts of the token and follow its progress without incurring the cost of tracing through the history of the transaction, which is a centralized task for the issuer (I) such as a bank.

[0119] In Table 2, the metadata includes a 2-byte field indicating the fiat currency (FiatDenomination) and a 1-byte field called the pegging rate (PeggingRate). The pegging rate is set by the issuer (I). It is possible to set several different rates for the same fiat currency, but different tokens (with different contracts) are required for each different rate. The choice of rate may be at the discretion of the issuer (I), but as described above, the issuer (I) can conduct a similar consideration regarding the pegging rate with respect to the amount allocation for the token.

[0120] In one example, the PeggingRate is an 8-bit encrypted value as follows: The leftmost bit is used as a flag, 1 = rate expressed as satoshis / cent (where "cent" refers to 1 / 100 of the fiat currency and is the smallest fiat currency) 0 = rate representing cents / satoshis The rightmost 7 bits represent the rate as a power of 10 in binary, for example, as follows: USD 1000010 means a rate of 100 satoshis / cent (flag is on) PHP 00000000 means a rate of 1 centavo / satoshis (flag is off) IDR 00000001 means a rate of 10 rupiah / satoshis (flag is off)

[0121] In one example, the TransactionType is a 1-byte field indicating whether the transaction is an issue (a token is generated from a cryptocurrency), a payment (at least part of the token value is transferred from one user to another user), or a redeem (the token is transferred to the issuer and converted back to a normal cryptocurrency).

[0122] In some examples, the "Padding" in both Metadata1 and Metadata2 can include values randomly generated for each transfer. As a result, each of Metadata1 and Metadata2 changes between transfers. The advantage is that it may reduce the risk and motivation of a malicious person who tries to determine a private key that matches either or both of Metadata1 or Metadata2 as an encryption pair (for the purpose of signing a redemption script using such a private key). This can be important for standardized tokens when most of the rest of Metadata1 or Metadata2 is the same.

[0123] Public key The public key (P1A) of the first user and the public key (P1I) of the issuer are paired with the corresponding private key (V1A) of the first user and the private key (P1I) of the issuer, respectively. The public key may be widely known to the public, while in another example, it may be desirable to communicate the public key as needed. In any case, since the corresponding private key is only needed when signing and unlocking a redemption script (such as during token exchange), only the public key is required for the redemption script.

[0124] As described above, in some alternatives, the first user 5 and the second user 7 can access their electronic wallets through a virtual machine environment or a terminal. The electronic wallet may be hosted by the issuer (I) 3 (or a server associated with the issuer (I) 3), and the corresponding user's private key is stored in the data store 11 but can only be accessed (or recreated) by the issuer (I) 3 with the approval of that user. In such a case, the first and second users 5, 7 may permit their private keys to be provided to the issuer (I) 3 to unlock the redeem script. This includes permitting the user's private key to be sent to the first processing device 13 of the issuer (I) 3, and the first processing device 13 may use the user's private key (e.g., P1A, P1B) and the public key of the first issuer (P1I) to unlock the redeem script.

[0125] Transmit the first data output (O1) to the peer-to-peer distributed ledger 150 Method 100 further includes transmitting a first data output (O1) to the peer-to-peer distributed ledger 9 via the communication network 8. The first data output (O1) may include a display of the first user of the first amount (B1) of transactions. That is, it is to record that the amount underlying the cryptocurrency (B1) associated with the first token (T1) has been transferred to the first user (A) 5. The first data output (O1) also includes the first hash (H1) described above. The first hash (H1) is associated with the first amount (B1) and provides a record of the first token (T1) associated with the first user (A) 5 and the issuer (I).

[0126] Importantly, the first hash (H1) is on the peer-to-peer distributed ledger 9 that can be used to prove or verify the existence of the token (T1), the relationship between the issuer (I) and the first user (A) 5, and / or the contractual conditions of the token.

[0127] The method may also include storing a first redeem script (RS1) in the data store 11 for later use 160.

[0128] A specific example of a transaction that creates a first token (T1) will now be described with reference to FIG. 2(a).

[0129] The first user (A) 5 deposits $1000 AUD with the issuer (I) for the equivalent value in the token In this example, a first user (A) 5 wishes to deposit $1000 AUD with an issuer (I), and in exchange, the issuer (I) creates a first token (T1) with a token value (TV1) of $1000 AUD by associating it with a first quantity (B1) of 10,000,000.

[0130] To create the token, the issuer (I) needs to have cryptocurrency. This can be supplied from a previous transaction or in response to a request from the first user (A) 5 for the first token (T1). This is shown on the left side of FIG. 2(a) as the "first quantity (not tokenized)".

[0131] Table 3 below shows that a transaction output is generated in the form of transaction-ID / Satoshis amount / locking script. Generating this transaction output represents the cryptocurrency that the issuer obtained from a previous transaction and is used, at least in part, in relation to the first token. [Table 3]

[0132] The ID-201 on the first line is a transaction identifier that identifies this transaction. The next line is the satoshis of this transaction, which is 50,000,000. The third line is the locking script (output script) for this transaction. The redeem script at this output, <PubK-Issuer hash>, indicates this output locked with the public key of the first issuer (P1I). That is, this transaction can be unlocked using the corresponding private key of the first issuer (V1I) of the issuer.

[0133] As described above, method 100 includes allocating a first quantity (B1) suitable for the first token (T1). However, the quantity held by the issuer (I) may not exactly match the first quantity (B1). In the current example, the required first quantity (B1) is 10,000,000, which is much smaller than 50,000,000 in the form of transaction ID-201.

[0134] As a result, the transaction creating the first token (T1) includes providing a change back to the issuer for the excess quantity not required for the token.

[0135] Moreover, the creation of token 100 is a transaction that requires payment of a transaction fee for mining. This is explained with reference to Table 4 below which shows the transaction for the creation of the token.

Table 4

[0136] The first line "ID-210" is a transaction identifier that identifies this transaction. The second line indicates the "Version number" that declares the version of the Bitcoin protocol used. The third line indicates the number of inputs for this transaction, which indicates a single input.

[0137] Rows 4 through 7 of Table 4 are related to these of the "Input", that is, the transactions before providing funds to ID-210, which is ID-201. The 4th row is the transaction identifier of the previous transaction. "IDX-00" in the 5th row is the index of the output of the previous transaction, ID-201 (in this case, it is referred to that the first output of the previous transaction, ID-201, is used). The 6th row is "ScriptSig", which is the unlocking script for the previous transaction, ID-201. As described above, the previous transaction is locked with the public key (P1I) of the first issuer represented by PubK-Issuer. As a result, the previous transaction can be unlocked using the corresponding first issuer's private key (V1I) of the issuer represented as Sig-Issuer. The 7th row is the serial number related to the input.

[0138] In a Bitcoin transaction, each contains a 4-byte field called a "sequence number" that is no longer used by Bitcoin Core. Depending on the issuer's implementation, the option is to utilize this field to assign transaction inputs to the outputs. The sequence number can represent a string of 1-bit flags, where the position of each flag starting from the rightmost bit indicates that the input has provided a portion of the funds to a flagged output. In this example, the sequence number "000000000000000000000000000000011" indicates that the input is paid to Output 1 and Output 2 described below.

[0139] Row 8 of Table 4 indicates the number of outputs of this transaction, which is 2. Rows 9 through 11 represent the first output, and rows 12 through 14 represent the second output.

[0140] The first output reflects the first amount (B1) associated with the first token (T1). Line 9 is the value of the output of the first amount (B1), which is 10,000,000 satoshis. Line 10 indicates the length of the output script. Line 11 is the output script - that is, the locking script that locks the first amount (B1). This includes the first hash (H1) of the first redeem script (RS1) and is expressed as follows: OP_HASH160 <redeem script hash> OP_EQUAL

[0141] "OP_HASH160" is a type of hash function where the input is hashed twice, first by SHA-256 and then by RIPEMD-160. The redeem script hash is the hash of the first redeem script (RS1) in the above format and, for example, is as follows: 2 metadata1 metadata2 P1A P1I 4 OP_CHECKMULTISIG

[0142] This includes the public key of the first user (P1A) and the public key of the first issuer (P1I) as described above. metadata1 and metadata2 may include the above metadata, which includes an indication that this is an "issuance" transaction. OP_EQUAL provides a boolean result for verifying the output.

[0143] The second output reflects the change of the issuer for the transaction. Since the input, which was the previous transaction ID - 201, contained 50,000,000 satoshis, the issuer can expect the remainder with respect to the satoshis. Line 12 is the output value for the second output, which is 39,999,000. Line 13 is the length of the output script, and line 14 is the output script for the second output. The second output is the change that goes back to the issuer (I), and the issuer can freely use the second output. As a result, the output script (i.e., the locking script) contains only the public key (P1I) of the first issuer, represented as <PubK-Issuer hash>.

[0144] Generally, the output value of a transaction must be equal to or less than the input value. In the example above, the input was 50,000,000 and the output was 49,999,000 (based on 10,000,000 for the first output and 39,999,000 for the second output). Therefore, there is a loss of 1,000 satoshis. In this example, 1,000 satoshis is the transaction fee (e.g., the mining fee).

[0145] The second type of transaction - redeeming a token of the first user by the issuer (I) Overview of token redemption In this example, the issuer is a service provider that provides an electronic wallet to users 5 and 7, and the private keys of the users are securely stored in the data store 11 associated with the issuer (I) 3. As a result, in this example, users 5 and 7 (or their respective processing devices 15 and 17) do not sign the redemption script. Instead, the issuer (I) 3 signs the redemption script upon approval from users 5 and 7. This can be explained in methods 200 and 600 shown in FIG. 7, where the first user (A) 5 sends a request 610 to redeem a first token with the issuer (I) 3. This request to redeem the first token, whether implicit or explicit, may include a commitment by the first user (A) 5 to the issuer (I) 2 to use the first user's private key (P1A) to redeem the first token.

[0146] Method 200 includes receiving 210, via the communication network 8, a request 610 from the first user (A) 5 to redeem a first token. Method 200 includes determining 220 a first redemption script (RS1) associated with the first token (T1).

[0147] The method also includes the issuer (I) 3 receiving 235 the private key (V1A) of the first user. In one example, this includes receiving the private key (V1A) of the first user from the data store 11. The private keys of the users, which are included in the electronic wallet managed by the issuer, must be securely stored. In another alternative, the issuer (I) 3 may receive the private key (V1A) of the first user from another entity or node. The issuer then signs 245 the first redemption script with the private key (P1A) of the user and the private key (P1I) of the first issuer. This can be advantageous in that the issuer (I) 3, which is the service provider for the first user (A) 5, can securely perform these steps at the first processing device 13, sign via the communication network 8 without sending the first redemption script (RS1), and not sign.

[0148] Method 200 also includes step 260 of transmitting a second data output (O2) via communication network 8 to peer-to-peer distributed ledger 9 including a display of the transaction to the first quantity (B1) of the issuer (I).

[0149] Accordingly, method 200 returns the first quantity (B1) associated with the first token (T1) to the issuer (I). In one example, since the first redemption script (RS1) is signed with the private keys of both the first user (A) 5 and the issuer (I), the recipient of the first quantity (B1) in this transaction is the issuer (I) 3, and the first quantity (B1) can then be used for other transactions - whether alone or together with other related tokens. The issuer (I) 3 can then expend the encryption of the first quantity (B1) for other transactions.

[0150] A specific example of a transaction redeeming the first token (T1) will now be described.

[0151] The first user (A) 5 redeems the first token (T1) for $1000 AUD from the issuer (I) In this example, the first user (A) desires to redeem the first token (T1) by the issuer (I) for the token value shown in FIG. 2(b). This results in a transaction of the first quantity (B1) from the first user (A) 5 to the issuer (I), referred to as the following transaction ID - 510. In return, the issuer (I) provides $1000 AUD to the first user (A) 5 as non-fungible currency.

[0152] In this example, the first token is redeemed by unlocking a first amount (B1), which is transferred to the issuer (I) 3. The transfer of the first amount (B1) back to the issuer enables the next use of the first amount (B1) for future transactions. The issuer (I) 3 can also "detokenize" the first amount (B1) by means of one or more transactions that remove metadata (which can include the redemption transaction that returned the first amount (B1) to the issuer). The issuer (I) can further use this cryptocurrency without the need for consent (such as a signature) from the first user (A) 5 or other users.

[0153] Before describing the transaction that redeems the first token ID - 510, briefly describe the output that starts the transaction that is the current redemption transaction, the input to ID - 510 (from transaction IDs - 210 and - 610). The two inputs generally include a first amount (B1) associated with the first token (T1) and another amount that is at least partially used to pay the transaction fee (e.g., the miner's fee).

[0154] From the previous example, the first user (A) 5 received the first amount (B1) in transaction ID - 210. The output going to the first user (A) 5 in transaction ID - 210 can be summarized as follows: [Table 5]

[0155] The second row of Table 5 represents the first quantity (B1) associated with the first token (T1) whose number is 10,000,000 satoshis. The third row represents the output script, which is equal to row 11 of Table 4 above. From the previous example, the transaction, ID-210, which created the first token (T1), had two outputs, and only the first output corresponding to the first quantity (B1) is associated with the redemption transaction ID-510. The second output in transaction ID-210 was the change returned to the issuer (I) shown in Table 4.

[0156] The issuer must also pay a transaction fee (e.g., a mining fee) for the redemption transaction, ID-510, which is paid as a portion of the amount received from the previous transaction, ID-610. This amount is summarized as follows:

Table 6

[0157] The second row of Table 6 shows the amount from the previous transaction, which is 9,999,000. The third row of Table 6 is the output script from this previous transaction. Since the cryptocurrency from this transaction, ID-610, is not associated with a token (or the associated user), the redeem script hash is simply the hash of the public key (P1I) of the first issuer shown as PubK-Issuer. That is, to use the output from transaction ID-610, this simply requires signing with the secret key (V1I) of the first issuer.

[0158] The transaction, ID-510, for redeeming the first token (T1) will now be discussed with reference to Table 7 below.

Table 7

[0159] The third row of Table 7 indicates that there are two inputs in this transaction, ID-510, and row 14 indicates that there are two outputs.

[0160] The first input is shown in rows 4 through 8, which is an input of the first amount (B1) to be redeemed, and it is from the previous transaction, ID-210. The fifth row, which is the previous transaction output index, is marked as "IDX-00" referring to the first output of transaction ID-210, which is the first amount (B1). Row 7 shows the ScriptSig that attempts to spend the first amount (B1). This indicates that the first redeem script (RS1) requires two out of four signatures, specifically, signing with the first user's private key (V1A) and the first issuer's private key (V1I).

[0161] The second input is shown in rows 9 through 13, which is the previous transaction, ID-610, and is used to fund the current transaction, ID-510. The ScriptSig in row 12 requires signing the previous output script with the first issuer's private key (V1I) for the previous output script that includes the first issuer's public key (P1I).

[0162] The first output is shown in rows 15 through 17, which has an output of 10,000,000 satoshis. This corresponds to the first amount (B1) from the first token (T1). The output script is in row 17, and the corresponding redeem script is as follows: 1 metadata1 metadata2 PubK-Issuer 3 OP_CHECKMULTISIG

[0163] This redeem script contains metadata from the first token and the public key of the issuer (P1I) shown as PubK-Issuer. This redeem script requires one of three signatures to spend 10,000,000 satoshis. In particular, the secret key of the first issuer (V1I) can be used to sign the cryptocurrency for the next transaction and be used for spending. It is worth noting that the public key of the first user (P1A) is not present in this redeem script. This can be considered that this amount is redeemed by the issuer (I) and as a result, used by the first user (A)5. As a result, the issuer (I) should be able to freely spend this amount without a commitment (such as an implicit commitment through the signature of the first user (A)5).

[0164] Issuer 3 can then perform a further transaction to redeem the redeem script from the output script (of line 17) using the public key of the issuer (P1I).

[0165] The first output described above holds metadata from the first token (T1) within the redeem script. However, in some alternatives, it should be understood that since the first token (T1) is redeemed and thus "untokenised", there is no need to include this metadata in the first output. That is, by removing the corresponding first and / or second metadata (MD1 / MD2), the first amount (B1) can be separated between the first token (T1) and the redeem transaction. Additionally, it is understood that the output script may be in another format specified by the user (I).

[0166] The second output is shown from lines 18 to 20 and it has an output of 9,998,000 satoshis. This is targeted at the input corresponding to transaction ID-610 which has 9,999,000 satoshis. The difference of 1,000 satoshis reflects the mining fee for this transaction.

[0167] In the above example, the first user (A) 5 redeemed all the values of the first token.

[0168] Fourth type of transaction - The first user (A) redeems the first portion by the issuer Redeem a portion of the value of the first token (T1) In the above example, the first user (A) 5 redeemed the entire value of the first token (T1). However, in some examples, the first user (A) 5 may only want to redeem a portion of the value of the first token (T1).

[0169] Referring to FIGS. 3(a) and 8, the first token (T1) has a token value that can include the sum of a first portion (R1) and a second portion (R2). Thus, the first user (A) 5 can send a request to redeem the value of the first portion (R1) of the first token (T!) via the communication network 8 610. Similarly, the issuer (I) 3 receives a request to redeem the first token (T1) from the first user (A) 5 via the communication network 8 210. The issuer can then perform the above steps 220, 230, 240, and 250 to redeem the first token (T1).

[0170] However, since the first user (A) 5 made a request to redeem the value of the first portion (R1) of the total token value (T1), the value of the remaining second portion (R2) needs to be assigned to a second token (T1) returned by the first user (A) 5. The second token will be described hereinafter with reference to FIG. 8.

[0171] The first user (A) 5 can send the public key (P1A) of the first user to the issuer (I) 3 via a communication network to create a second token (T2) 645. Similarly, method 200 then includes the issuer (I) determining the public key (P1A) of the first user from the first user (A) 5 255. The issuer (I) may already have the public key (P1A) of the first user from a previous transaction (or within an electronic wallet), and in such a case, it should be understood that it is not necessary for the public key (P1A) of the first user to be resent by the first user (A) 5. Instead, the public key (P1A) of the first user may be received from a data store 11 and / or a third party.

[0172] In yet another alternative, the first user (A) 5 may wish to use a different encryption pair for the second token (T2). Therefore, the sending step 645 and the step 255 of determining the public key of the first user may include a public key of the first user that is different from that associated with the first token (T1).

[0173] Method 200 includes assigning a second quantity (B2) associated with the second token (T2), and this second token has a value (TV2) of the second token based on a second portion (R2). The step 265 of assigning the second quantity (B2) may include considerations similar to those for assigning the first quantity (B1) described above.

[0174] In some examples, it may be desirable for the first user (A) 5 that the pegging rate (PR2) of the second token (T2) is the same as the pegging rate (PR1) of the first token (T1), so that the conditions of the first token (T1) and the second token (T2) remain the same except for the amount of the token value.

[0175] In other examples, the second quantity (B2) may need to be greater than or equal to a minimum threshold (MT2) that is different from the minimum threshold (MT1) for the first token (T1). Thus, allocating the second quantity (B2) may include determining the minimum threshold (MT2) for the second token (T2), and determining a second quantity (B2) that is greater than or equal to the minimum threshold (MT2) of the second token (T2). Method 200 further includes step 275 of determining a second hash (H2) of the second redemption script (RS2), where the second redemption script (RS2) is at least based on second metadata that is at least partially based on the first metadata (MD2) associated with the first token (T1), the public key (P1A) of the first user, and the public key (P1I) of the first issuer associated with the issuer (I).

[0176] At least the second metadata (MD2) may include, for example, the relationship with one or more contract conditions of the first token (T1). As a result, the second token (T2) may have the same or similar characteristics as the first token (T1), even if it has different token values. In some specific examples, at least the second metadata (MD2) of the second token (T2) is the same as at least the first metadata (MD1) of the first token. In such an example, the second redemption script (RS2) of the second token (T2) is the same as the first redemption script (RS1) of the first token (T1). As a result, the second hash (H2) associated with the second token (T2) is also the same as the first hash (H1) associated with the first token (T1). This may also have the advantage that the second hash (H2) of the second token (T2) can be easily verified by comparing it with the first hash (H1) of the first token (T1). This can also reduce the storage space associated with recording the second hash (H2) (or the next hash) that they are the same.

[0177] As described above, the public key (P1A) of the first user for the second token (T2) may be different from the public key of the first user associated with the first token (T1) in some alternatives. Similarly, the public key (P1I) of the first issuer associated with the second token (T2) for the issuer (I) may also be different. For example, the issuer (I) and / or the first user (A)5 may wish to use different encryption pairs for security reasons.

[0178] In this example, step 260 of sending the second data output (O2) to the peer-to-peer distributed ledger via the communication network 8 may further include displaying a transaction of the second amount (B2) for the first user (A)5 and the second hash (H2). The second hash (H2) is associated with the second amount (B2) to provide the second token (T2) associated with the first user (A)5 and the issuer (I). Thus, the first user (A)5 is provided with a second token (T2) having similar characteristics to the first token (T1) in some examples based on the value of the second portion (R2).

[0179] An example of redeeming the first portion is illustrated in FIG. 3(a), where the first user (A)5 including a request to redeem the value of the first portion (R1) of the first token (T1) redeems the first token (T1) with the issuer (I), and the first portion is equal to $500 AUD non-convertible currency. Similarly, the issuer (I)3 provides $500 AUD in non-convertible currency and the second amount (B2) to provide the second token (T2) to the first user (A)5. The second amount (B2) is associated with a second token that can represent the value of the second portion (R2) of $500 AUD.

[0180] The third type of transaction - the first user (A) transfers a value to the second user (B) Overview of the transfer of value from the first user (A) 5 to the second user (B) The present disclosure also includes a method 300 for creating one or more additional tokens by an issuer (I) 3 as illustrated in FIG. 9. These additional tokens may be created, for example, as a result of a first user (A) 5 desiring to transfer the value of the first token or a portion thereof to a second user (B). This may be achieved by creating a third token (T3) associated with the second user (B) 7 and the issuer (I) 3.

[0181] This can advantageously enable the first user (A) 5 to substantially transfer the same or similar rights associated with the first token (T1) to the second user (B). Even if a new token is created in the form of a third token (T2), the third token (T3) may have characteristics similar to the first token (T1). For example, the tokens may have the same or similar associated metadata. For example, it may be convenient if the same or similar contractual conditions applicable between the first user (A) 5 and the issuer (I) 3 are to be applied between the second user (B) 7 and the issuer (I) 3.

[0182] Depending on the situation, as shown in FIG. 2(c), the first user (A) 5 may desire to transfer at least a portion of the value of the first token (T1) to the second user (B). In one example, this can be achieved by transferring a first quantity (B1) associated with the first token (T1) from the first user (A) to the second user (B) 7. In a transaction where the entire value of the first token (T1) is transferred to the second user (B) 8, this includes the generation of a third token (T3) having the first quantity (B1), which is transferred to the second user (B) 7. Efficiently, the third token (T3) is the transfer of the first token (T1) and the rights associated with the first token (T1) to the second user (B) 7.

[0183] In this example, the transfer of value from a first user (A) 5 to a second user (B) involves an issuer (I) 3 as an intermediary to facilitate the transfer. This is distinguished from a direct transaction of a first quantity (B1) from the first user (A) 5 to the second user (B) 7. The involvement of the issuer (I) in this transfer of value can be advantageous for several reasons. First, involving the issuer (I) can reduce the risk of the first quantity (B1) being transferred and used by the first user (A) 5 as a normal cryptocurrency, as opposed to being used as the first quantity (B1) as a token. Second, by involving the issuer (I), the issuer (I) 3 can be enabled to track tokens and specific rights and / or liabilities associated with specific users. This can be useful for accounting, financial reporting, and / or regulatory purposes. An example of this transfer of value, each of methods 300, 700, 800 being executed by the issuer (I) 3, the first user (A) 5, and the second user (B) 7, will be described in detail with reference to FIGS. 2(c) and 9. The first user (A) 5 sends a request 710 to create a third token (T3) via a communication network 8, and this third token (T3) is associated with a first token (T1). Additionally, or alternatively, the second user (B) 7 can send a request 810 to create a third token (T3) via the communication network 8. It should be understood that whether these requests are sent by one or both of the first user (A) 5 and / or the second user (B) 7 can depend on the contractual conditions of the first token (T1).

[0184] The issuer (I) then receives 310 a request to create a third token (T3) via the communication network 8. It should be understood that requests from the first user (A) 5 and the second user (B) may be sent via another party in the communication network 8. Additionally, the request may be partial, having a part of the request from the first user (A) 5 and another part of the request from the second user (B) 7.

[0185] Method 300 then includes determining 320 a first redemption script (RS1) associated with the first token (T1).

[0186] Method 300 also includes receiving 335 the private key (V1A) of the first user. In one example, this includes reading the private key (V1A) of the first user from the data store 11. The method further includes having the issuer (I) 3 sign the first redemption script with the user's private key (P1A) and the first issuer's private key (P1I) 345. Steps 335 and 345 are similar to steps 235 and 245 in the above-described method 200 for redeeming the first token (T1), and similar considerations may apply.

[0187] To create the third token (T3), the public key (P1B) of the second user is required. This public key (P1B) of the second user is an encryption pair with the private key (V1B) of the second user. The issuer (I) 3 can determine 360 the public key (P1B) of the second user in several ways. First, the issuer (I) 3 can be the service provider of the second user (B) 7, and the public key (P1B) of the second user may be stored in the data store 11 of the issuer (I). Alternatively, the public key (P1B) of the second user may have been received by the issuer (I) during a previous transaction, and thus, the public key (P1B) of the second user can, in some cases, be read from the data store 11 of the issuer (I). In some alternative means, the public key (P1B) of the second user can be received via a third party in the communication network 8. In yet another alternative, the second user (B) 7 can send the second public key (P1B) to the issuer (I) 3 via the communication network 8 820.

[0188] Method 300 further includes allocating 370 a third quantity (B3) associated with a third token (T3). In some examples where the total value of the first token (T1) is transferred to a second user (B), it may be appropriate for the third quantity (B3) to be allocated the same amount from the first quantity (B1). The first quantity of cryptocurrency (B1) allocated from the second user. In other options (e.g., a fifth type of transaction described in more detail below), only a portion of the total value of the first token (T1) is transferred to the second user (B), and the corresponding ratio can be allocated to the third quantity (B3). In yet another example, the third quantity (B3) may be allocated from another cryptocurrency not related to the first quantity (B1). It should be understood that the considerations for allocating 370 the third quantity (B3) can be the same or similar to those when allocating 130 the first quantity (B1) in method 100 and when allocating 265 the second quantity (B2) in method 200.

[0189] This method further includes step 380 of determining a third hash (H3) of a third redemption script (RS3), where the third redemption script (RS3) is based at least on a third metadata (MD3) partially based on a first metadata (MD1) associated with a first token, a public key (P1B) of a second user, and a public key (P1I) of a first issuer. This may include similar or the same considerations as determining a first hash (H1) of a first redemption script (RS1) of method 100 or determining a second hash (H2) of a second redemption script (RS2) of method 200. Method 300 further includes transmitting, via a communication network, a third data output (O3) to a second user (B) of at least a third amount (B3) of transactions, including a display of the transaction and a peer-to-peer distributed ledger including the third hash (H3), where the third hash (H3) is associated with a third amount (B3) of cryptographic pain to provide a third token (T3) associated with the second user (B)7 and the issuer (I). To provide a third token (T3) associated with the second user (B)7 and the issuer (I), the third hash (H3) is the third encrypted amount (B3)). This is similar to steps 150 and 2260 described above, and similar variations and alternatives may apply.

[0190] Fifth type of transaction - The first user (A) transfers a first portion to the second user (B) In another example, only a first portion (R1) of the total amount of the first token (T1) is transferred to the second user (B)7, in which case the remaining second portion (R2) of the total amount can be included in a second token (T2) that is paid back to the first user (A)5. This may be similar to paying back to the second portion (R2) of the value described above in method 200. Thus, a request to create a third token (T3) may explicitly or implicitly include a request to create a third token (T3) with a value of the third token (TV3) based on the first portion (R1).

[0191] The refund to the first user (A) 5 in the form of the second token (T2) is described with reference to FIGS. 3(b) and 10. To create the second token (T2), method 300 includes determining 355 the public key (P1A) of the first user. This may be accomplished in several ways as described above, and may include receiving 745 the public key (P1A) of the first user transmitted from the first user (A) 5 via the communication network 8.

[0192] The method further includes allocating 365 a second amount (B2) for association with the second token (T2), the second token having a value (TV2) of the second token based on the second portion (R2). Method 300 also includes determining 375 a second hash (H2) of the second redemption script (RS2) based on at least partially on the first metadata (MD1) associated with the first token (T1), the public key (P1A) of the first user, and the public key (P1I) of the first issuer associated with the issuer (I) 3. Thus, step 390 of transmitting the third data output (O3) to the peer-to-peer distributed ledger further includes a display of the transaction of the second amount (B2) to the first user (A) 5 and the second hash (H2) associated with the second amount (B2) to provide the second token (T2) associated with the first user (A) 5 and the issuer (I) 3.

[0193] Example of transferring value from the first user (A) 5 to the second user (B) A specific example of the transaction, ID - 110, will now be described. Referring to FIG. 3(b), the first user (A) 5 has a token with a total value of $10.00 AUD. The first user (A) 5 wishes to transfer a first portion (R1) of $7.30 AUD as a third token (T3) to a second user (B) and have the remaining second portion of $2.70 provided as change in the form of a second token (T2) returned to the first user (A) 5.

[0194] In this example, the first token (T1) contains a block of two tokens, each with a block representing a value of $5.00 AUD. This can represent a token with a standardized value (e.g., in $5.00 blocks), or the first user (A) who obtained two blocks from different transactions. Each of these blocks contains 50,000 satoshis, which is equal to $5.00 AUD at a pegging rate of 100 satoshis / cent. This is described below in Table 8 as Transaction IDs - 101 and ID - 102, which are the transactions that create the first token (T1).

Table 8

[0195] Line 3 for both ID - 101 and ID - 102 represents the output script of each transaction and is similar to line 11 in Table 4 above.

[0196] The issuer (I) also needs to pay a transaction fee (mining fee) for this transaction. This transaction fee may be partially paid from the amount received from the previous transaction, Id - 103, shown in Table 8. This represents the previous transaction of 10,000,000 satoshis, which is partially used to fund the transaction. This is similar to the previous Transaction ID - 610 described above with reference to Table 6.

[0197] The transaction that transfers the value to the second user (B), ID - 110, will now be considered with reference to Table 9 below.

Table 9

[0198] The third row of Table 9 indicates that there are three inputs, and row 19 indicates that there are three outputs. Two of the inputs represent the first token (T1), and the third input is for paying the transaction fee. The first output represents the transfer of value to the second user (B)7, the second output represents the change of tokens returned to the first user (A)5, and the third output is the change returned to the issuer (I).

[0199] The first input based on the previous transaction ID - 101 is shown from lines 4 to 8. It is the input of the first block of 50,000,000 satoshis, which is half of the first amount (B1) and represents $5.00 AUD in amount. Line 7 shows the ScriptSig that enables the use of this amount. This indicates that the first redeem script (RS1) requires signatures by two out of four signatures, specifically the secret key of the first user (V1A) and the secret key of the first issuer (V1I). Line 8 is the serial number that tags this first input to the first output.

[0200] The second input based on the previous transaction ID - 102 is shown from lines 9 to 13. It is the input of the second block of 50,000,000 satoshis, which is the second half of the first amount (B1) and represents $5.00 AUD in amount. Line 12 shows a ScriptSig similar to line 7 above. Line 12 shows the serial number that tags the second input to both the first output and the output to the second output. This is because this second block of 50,000,000 satoshis is split into 23,000 satoshis for the first output and 27,000 satoshis for the second output.

[0201] The third input is shown from lines 14 to 18. This is based on the previous transaction ID - 103, which is used to fund the current transaction ID - 110. The ScriptSig in line 17 requires signing with the secret key (V1I) of the first issuer for the previous output script included in the public key (P1I) of the first issuer.

[0202] The first output, shown at lines 20 through 22, has an output of 73,000 satoshis, which is the third amount (B3) for the third token (T3). In this example, the pegging rate of the third token (T3) is 100 satoshis / cent (the same pegging rate as the first token (T1)), and thus the third amount (B3) has a value of the third token (TV3) of $7.30 AUD, which is based on the first portion (R1) of $7.30 AUD.

[0203] The output script is at line 22, and the corresponding redeem script for this example is as follows: 2 metadata1 metadata2 P1B P1I 4 OP_CHECKMULTISIG

[0204] This includes the public key of the second user (P1B) and the public key of the first issuer (P1I). Importantly, since the third token (T3) is used for redemption by the second user (B)7, the public key of the second user (P1B) is used. metadata1 and metadata2 include the above-mentioned metadata, including an indication that this is a "payment" or "transfer" transaction between users. Thus, the first output provides the third token (T3) that can be redeemed by the second user (B)7 for a value of $7.30 AUD by the issuer (I)3.

[0205] The second output, shown at lines 23 through 24, has an output of 27,000 satoshis, which is the second amount (B2) for the second token (T2) returned to the first user (A)5. In this example, with the same pegging rate of 100 satoshis / cent and as a result, the second amount (B2) has a value of the second token (TV3) of $2.70 AUD, which is based on the remaining second portion (R2) of $2.70 AUD. The output script is at line 25, and the corresponding redeem script for this example is as follows: 2 metadata1 metadata2 P1A P1I 4 OP_CHECKMULTISIG

[0206] This includes the public key (P1A) of the first user and the public key (P1I) of the first issuer. Importantly, the public key (P1A) of the first user is used after the second token (T2) has been redeemed by the first user (A). The metadata may also include an indication that this is a "payment" or "transfer" transaction between users.

[0207] The third output, shown from lines 26 to 28, reflects the user's change for the transaction. In the current transaction, the transaction fee is 1,000 satoshis, and as a result, the issuer (I) can expect to have change from the third input of 10,000,000 satoshis. Line 26 is the output value for the third output, which is 9,999,000. Since the third output is the change returned to the issuer (I), the issuer can use the third output freely. As a result, the output script at line 28 includes only the public key (P1I) of the first issuer, represented by <PubK-Issuer hash>.

[0208] The above example allows a single transaction to have a mix of "tokenized" and "non-tokenized". In one example, it may be important to verify that the value of the input token is equal to the value of the output token. Thus, the issuer may verify that the value (TV1) of the first token (T1) is equal to the sum of the value (TV2) of the second token and the value (TV3) of the third token.

[0209] In the above example, the termination of the transaction is paid by the issuer (I), and the issuer (I) may pass these costs on next by other means. In some alternative means, it should be understood that the transaction fee may be paid directly by the first user and / or the second user. For example, the first user may be required to contribute to the cryptocurrency used for the payment of the transaction fee. In another example, a portion of the first, second, or third quantity may be used in each transaction to pay the transaction fee. In yet another alternative means, each transaction can include an additional output that creates an additional token to facilitate the miner's redemption transaction with the issuer (I)3.

[0210] Variant - The user signs the redemption script with their respective private keys In the above example, the issuer (I) is a service provider for the first user (A)5 and the second user (B)7, and manages their respective electronic wallets. As a result, the user (I)3 can access the respective private keys authorized by the users. This includes reading the user's private key from the data store 11.

[0211] In some alternative examples, it may be desirable for the user to hold their own private key. This separation allows the user to have more powerful control over their private key. Those with access to all the information in the issuer (I)3's data store 11, including the first issuer's private key (V1I), may be more secure as they do not have the respective users' private keys and thus cannot unlock the redemption script.

[0212] As a result, one variant of the method can include sending the redemption script to users 5, 7 for signing with their respective private keys. In such an example, the issuer (I)3 does not need to have ownership of the users' private keys.

[0213] A method 200, 600 for redeeming the first token (T1) and such variants thereof will now be described with reference to FIG. 11.

[0214] The first user (A) 5 can send a request 610 to redeem the first token (T1) via the communication network 8. Next, the issuer (I) 3 receives 210 a request from the first user (A) 5 to redeem the first token (T1) via the communication network 8. The method 200 then includes determining 220 a first redemption script (RS1) associated with the first token (T1). In one example, this may include reading the first redemption script (RS1) from the data store 11. In another example, this may include reconstructing the first redemption script (RS1) with data from one or more sources. For example, this may include reading at least the first metadata (MD1) and the public key of the first issuer (P1I) from the data store 11 and receiving the public key of the first user (P1A) via the communication network 8. This data may then be concatenated to reconstruct the first redemption script (RS1).

[0215] Method 200' then includes transmitting a first redemption script (RS1) for signing by a first user (A) 5 via a communication network 8 at 230. Similarly, the first user (A) 5 receives the first redemption script (RS1) at 620. In some alternative examples, it should be understood that the step of transmitting the first redemption script (RS1) to the first user (A) 5 may be performed routinely. For example, the first redemption script (RS1) may be transmitted to the first user (A) 5 during or after the issuer (I) 3 creates the first token (T1). In another alternative, the first redemption script (RS1) may be read by the first user (A) 5 from a data store. In yet another alternative, the first user (A) 5 can independently determine the first redemption script (RS1) associated with the first token (T1). For example, the first user (A) 5 can read the first metadata (MD1), the public key of the first issuer (P1I), and the public key of the first user (P1A) from one or more sources to determine the first redemption script (RS1).

[0216] The first user (A) 5 then signs the first redemption script (RS1) at 630 with the first user's private key (V1A) to provide a first redemption script (RS1A) signed by the first user. The first redemption script (RS1A) signed by the first user is for the communication network.

[0217] Similarly, method 200' includes receiving at 240 the first redemption script (RS1A) signed by the first user via the communication network 8. Method 200 further includes signing at 250 the first redemption script (RS1A) signed by the first user with the private key of the first issuer (V1I) to unlock a first amount (B1) associated with the first token (T1).

[0218] Method 200’ further includes step 260 of transmitting a second data output (O2) via communication network 8 to a peer-to-peer distributed ledger including a display of a transaction to a first quantity (B1) of an issuer (I). In one example, since a first token (T1) has been redeemed, the first quantity (B1) is returned to the issuer (I) and may no longer be associated with the first token (T1). In some cases, metadata associated with the first quantity (B1) may optionally remove the act of “untokenising” the cryptocurrency. This may be done in the same transaction or the next transaction, and may be at the option of the issuer (I)3.

[0219] In particular, the above method 200’ requires both the first user (A)5 and the issuer (I) to sign a first redemption script (RS1). This can be advantageous for preventing accidental or non-intentional spending of the first quantity (B1) by the first user (A)5 beyond the intended purpose of the token, or for reducing risk. For example, if the first user (A)5 attempts to spend the first quantity (B1) on another user (other than the issuer (I)), such a transaction will not be processed because the private key (V1I) of the first issuer is required to unlock the first quantity (B1). On the other hand, requiring the first user (A)5 to sign the first redemption script (RS1) provides a certain level of security for redeeming the first quantity (B1) because the first user (A)5 controls the private key (V1A) of the first user and selectively uses it for approved transactions.

[0220] Furthermore, since the issuer (I) signing the redemption script last can avoid sending a fully signed redemption script over a potentially insecure communication network, security can be enhanced. For example, when redeeming the first token (T1), the order of public keys is instructed to be sent to the issuer (I) for the final signature after the first user (A)5 signs the first redemption script (RS1). Since the issuer (I) provides the final signature for unlocking, this reduces the risk that someone eavesdropping on the communication between the issuer (I) and the first user (A)5 gains unauthorized access to the token (T1) and / or the first amount (B1).

[0221] As shown in methods 300’, 700’, 800’ described in FIG. 12, similar steps can be used when transferring the value of the first token (T1) from the first user (A)5 to the second user (7). Methods 300’, 700’, 800’ include steps similar to those described for methods 300, 700, 800 above with reference to FIG. 9, with the following exceptions. Instead of the issuer (I)3 receiving the private key (V1A) of the first user, it is used to sign the first redemption script (RS1), which is done by the first user (A)5. Thus, method 300’ includes the issuer (I)3 sending the first redemption script (RS1) to be signed by the first user (A)5 via the communication network 8.

[0222] The first user (A)5 receives the first redemption script 720 and signs the first redemption script with the private key (V1A) of the first user 730. This provides the first redemption script (RS1A) signed by the first user, which is then sent to the issuer (I)3 via the communication network 8 740.

[0223] Method 300' then includes step 340 of receiving a first redemption script (RS1A) signed by a first user via communication network 8. Subsequently, sign the first redemption script (RS1A) signed by the first user to unlock a first amount (B1) associated with the first token (T1) with the private key (V1I) of the first issuer at 350.

[0224] Method 300' can further include steps 360, 370, 380, and 390 to complete the creation of the third token (T3) in a manner similar to method 300 described above.

[0225] Tokens and the systematization process A contract is transferable if the rights defined are those granted by the holder or owner of the contract. Examples of non-transferable contracts are those bearing the name of a participant, i.e., where the rights are granted to a specific named entity rather than the contractor. Only transferable contracts are considered herein.

[0226] A token represents a specific contract that enumerates or defines the rights granted by the contract. The actual contract may be a file stored in a distributed manner. For example, it may be stored in the cloud. In a preferred embodiment, the token represents the contract in the form of a Bitcoin transaction.

[0227] A divisible token is a value on a transaction output that can be further broken down into smaller amounts that are assigned across multiple tokens (i.e., assigned across multiple transactions). A typical example is a tokenized fiat currency. A divisible contract is defined to specify a non-zero pegging rate. For a divisible contract, the tokenized value transferred to a transaction output is associated with the value of the underlying Bitcoin (BTC) via the pegging rate. That is, the contract specifies the rights of the holder with respect to the pegging rate. For non-divisible tokens, there is no pegging rate, and the contract specifies the rights of the owner with a fixed value (e.g., like an unsecured bond: "This contract will be redeemed exactly at $1000" or a voucher "This contract can be redeemed for one haircut"). For non-divisible contracts, the BTC of the underlying transaction has no relation to the value of the contract. The expression "Underlying BTC value" refers to the amount of Bitcoin (BTC) attached to a transaction output. In the Bitcoin protocol, a non-zero BTC amount that is considered valid for all transaction outputs is required. In practice, the BTC amount must currently be larger than the minimum value (known as "dust") that has been set at 546 satoshis so far. 1 Bitcoin is defined as equal to 100 million satoshis. Since Bitcoin transactions are used here only as a means to facilitate the exchange of ownership, the actual underlying BTC amount is arbitrary, and the true value lies in the contract specification. In theory, all tokens could be carried by dust. For the protocol of the present invention, especially for divisible tokens, the underlying BTC value has meaning. That is, it has a relationship with the contract value via the pegging rate. The pegging rate itself is arbitrary and is selected to keep the underlying BTC amount small.The reason for using the PeggingRate instead of simply using the transaction per underlying token with dust is that the protocol of the present invention promotes divisibility and there is no need to adjust the original contract when the token is divided into several transaction outputs of smaller amounts. Rather, the contract value of each subdivided token is simply calculated based on the PeggingRate and the subdivided amount of the underlying BTC value. The limited token is one in which the total issued value is fixed (or "restricted") by a fixed non-zero number of shares as defined by an amount called NumShares. Thus, there are no additional shares issued under the restricted contract. For example, a contract for partial ownership of a racehorse is restricted to 100% of the racehorse (e.g., 100 shares at 1% each, 10 shares at 10% each, etc.). An unrestricted contract means that the issuer can undertake the further issuance of shares, for example, by adding the required amount of fiat currency to a reserve account. NumShares must be explicitly stated for all contracts. A restricted contract requires NumShares > 0, and an unrestricted contract is indicated by setting NumShares = 0. A typical example is a currency reserve (similar to a fiat reserve) that matches the total amount of promissory notes (i.e., unredeemed tokens) held in a reserve bank account. This concept is extended beyond the currency reserve to include inventory. For example, the issuer of licensed printed T-shirt tokens can start with 10,000 T-shirts in inventory and issue divisible tokens to represent the 10,000 T-shirts (e.g., each share = 1 T-shirt). The original token can be subdivided, and each subdivided token can be redeemable for several T-shirts according to the underlying BTC value of the transaction output defined by the PeggingRate. However, if demand increases, the issuer can decide to issue additional shares (i.e., increase the number of shares in circulation by, for example, another 10,000).In such a case, the issuer is obliged to deposit an additional 10,000 T-shirts in his reserve account (i.e., inventory warehouse) in order to accept further issuance. Therefore, the total number of T-shirts with inventory at any one time (where the inventory functions as a "deposit account") = the total number of unredeemed shirts. PeggingRates apply only to divisible contracts where the value of the share (represented by an amount called ShareVal) is fixed to the underlying BTC amount. For example, the contract may specify that the issuer agrees to redeem tokens at a rate of $10,000 per 1 BTC of the underlying. This means that a transaction with a tokenized underlying output value of 15,400 satoshis is redeemed at $1.54 (for example). If the value of the PeggingRate is 0, it indicates that the contract is non-divisible (i.e., it can only be transferred in whole like a bearer bond). When the PeggingRate is set to 0 (meaning non-divisible tokens), the underlying BTC value can be set to any amount regardless of the contract value. Usually, in this case, it is desirable to keep the underlying BTC amount as small as possible (i.e., set it to dust) in order to minimize operating costs. NumShares is the total (fixed) number of shares available under a (limited) contract. In the case of a limited contract, NumShares must be an integer greater than 0. In the case of an unlimited contract, NumShares is not fixed and more shares can be issued at any time (if accepted), and the value is indicated by setting it to 0. A share is defined as a unit of transfer, and ShareVal is the value of that unit. For example, in the case of a non-convertible currency, the transfer unit can be set to 1 cent. Or, for example, it can be set to 50 cents, in which case transfers are only made in "lots" of 50 cents. ShareVal can also be expressed as a percentage. For example, if a breeder wants to sell a racehorse in 10 equal shares, ShareVal = 10%. ShareVal must be greater than 0 and must be defined in the contract. TotalIssuance represents the total amount of shares issued.This value is only relevant for a restricted contract. In the case of an unrestricted contract, the issuance is not fixed and there is a possibility that more shares may be issued. If the shares are represented as a percentage, by definition, TotalIssuance = 100%. For a restricted contract, NumShares, ShareVal, and TotalIssuance are related as follows:. NumShares x ShareVal = TotalIssuance If the value of TotalIssuance is 0, it is an unrestricted contract. An example of an unrestricted contract is a non-fungible currency (TotalIssuance is set to 0), and examples of restricted contracts are as follows. (i) Limited edition commemorative coins (1000 minted, 1 share = 1 coin): TotalIssuance = 1000 x 1 = 1000 coins; (ii) Seats in the issued venue, where TotalIssuance = total available seats. Circulation is defined as the total value of the unused tokens (i.e., determined by the transactions in the UTXO - Unused Transaction Output). The complete set of all unused transactions is maintained in a list available at all Bitcoin nodes. For example, if the issuer initially issues $10,000 worth of tokens as a non-fungible currency type and $5500 worth of tokens are redeemed over time, the circulation = $4500 (as the value of the unredeemed tokens). This value needs to be adjusted with the balance of the related reserve account. Note that in some (atypical) situations, the circulation can be less than the reserve account balance. For example, consider a breeder who issues 10 shares for racehorses (here, by definition TotalIssuance = 100%). The buyer can redeem the tokens by sending them back to the breeder, and if she reverse tokenizes it, the currency is only 9 shares, which is 90% of the horse, while the reserve (= stable) is the entire 100% horse. In this situation, the reserve excess (i.e., the unclaimed 10% ownership) implicitly belongs to the issuer. This situation is benign and within the scope of the present invention, but a protocol can be implemented that must explicitly consider 100% of the shares (i.e., in this illustrative situation, the breeder is not allowed to reverse tokenize the tokens).

[0228] Example 1 - Sale by Weight of Firewood. In this example, the contract states as follows: "The owner has the right to receive firewood at a rate of 600 satoshis per 20 kilograms as a base." The metadata is defined to represent the following important parameters: NumShare = 0; ShareVal = 20 kg; PeggingRate = 600 satoshis / share. These parameters define an unlimited and divisible contract, where a share of the contract has the value of 20 kg of firewood, and each multiple of 600 satoshis within the transaction corresponds to one share of the contract. In this example, TotalIssuance is not fixed.

[0229] Example 2 - Sale by Bag of Firewood. In this example, the contract states as follows: "The holder is eligible to receive one bag of 20 kg of firewood." The metadata is defined to represent the following important parameters: NumShares = 0; ShareVal = 1 bag; PeggingRate = 0. These parameters define an unlimited and non - divisible contract, where a share of the contract has the value of a bag of 20 kg of firewood, and the basic amount of Bitcoin within the transaction corresponds to one share of the contract. In this example, TotalIssuance is not fixed.

[0230] Example 3 - $1000 Banknote. In this example, the contract states as follows: "The owner has the right to receive exactly $1000." The metadata is defined to represent the following important parameters: NumShares = 0; ShareVal = $1000; PeggingRate = 0. These parameters define an unlimited and non - divisible contract. A share of the contract has the value of $1000, and the basic amount of Bitcoin within the transaction corresponds to one share of the contract. In this example, TotalIssuance is not fixed.

[0231] Example 4 - Commemorative Coin #1. In this example, the contract states as follows: "The owner has the qualification to obtain a limited edition (1000 coins) 2000 Olympic silver coin (maximum 1 coin per person)". The metadata is defined to represent the following important parameters. NumShares = 1000; ShareVal = 1 coin, PeggingRate = 0. These parameters define an indivisible contract limited to 1000 shares, where the shares within the contract have a value of 1 coin and any amount of the base Bitcoin within a transaction corresponds to 1 share within the contract. In this example, TotalIssuance is 1000 coins.

[0232] Example 5 - Commemorative Coin #2. In this example, the contract states as follows: "The holder is eligible to receive a limited edition (10,000 coins) 2000 Olympic copper coin at a rate of 600 satoshis per coin as the basis". The metadata is defined to represent the following important parameters. NumShares = 10,000; ShareVal = 1 coin; PeggingRate = 600 satoshis / share. These parameters define a divisible contract limited to 10,000 shares, where the shares of the contract have a value of 1 coin and 600 satoshis within a transaction corresponds to 1 share of the contract. In this embodiment, the total issuance amount is 10,000 coins.

[0233] Example 6 - Non - convertible Currency #1. In this example, the contract states as follows: "The owner has the right to receive Canadian dollars at a rate of $10,000 per base Bitcoin. The transfer unit is 50 cents". The metadata is defined to represent the following important parameters. NumShares = 0; ShareVal = 50 cents; PeggingRate = 5000 satoshis / share. These parameters define an unrestricted and divisible contract, where the shares of the contract have a value of 50 Canadian cents and each multiple of 5000 satoshis within a transaction corresponds to 1 share of the contract. In this example, TotalIssuance is not fixed.

[0234] Example 7 - Non - convertible currency #2. In this example, the contract states as follows. "The owner has the right to receive AUD 10,000 for each underlying Bitcoin at a rate of 10,000 dollars per Bitcoin. The transfer unit is 1 cent." The metadata is defined to represent the following important parameters. NumShares = 0; ShareVal = 1 cent; PeggingRate = 100 satoshis / share. These parameters define an unlimited and divisible contract. The shares of the contract have a value of 1 Australian cent, and 100 - land multiples within a transaction correspond to one share of the contract. In this example, TotalIssuance is not fixed. Incidentally, the minimum AUD that can actually be transferred in this example is 6 cents. Below that, the underlying BTC value will be lower than the current minimum required for a valid transaction.

[0235] Example 8 - Shared house. In this example, the contract states, "The owner has the right to share the ownership of the (residential) property at a rate of 600 satoshis for 10%." The metadata is defined to represent the following important parameters. NumShares = 10; ShareVal = 10%; PeggingRate = 600 satoshis / share. These parameters define a divisible contract where the shares within the contract are limited to 10 shares with a value of 10%, and each 600 - satoshi multiple within a transaction corresponds to one share of the contract. In this example, TotalIssuance is 100% ownership of the house.

[0236] Example 9 - Racehorse. In this example, the contract states as follows. "The owner has the right to own 1% of the ownership of 'Naka’s Delight' at a rate of 600 satoshis." The metadata is defined to represent the following important parameters. NumShares = 100; ShareVal = 1%; PeggingRate = 600 satoshis / share. These parameters define a divisible contract where the shares within the contract are limited to 100 shares with a value of 1%, and each 600 - satoshi multiple within a transaction corresponds to one share of the contract. In this example, TotalIssuance is 100% ownership of the horse.

[0237] Example 10 - Ticket for an Assigned Seat. In this example, the contract states as follows. "The owner has the right to sit in seat B54 at the Central Concert Hall on February 14, 2016, at the 'Dead Lizard' concert." The metadata is defined to represent the following important parameters. NumShares = 1; ShareVal = 1 ticket, PeggingRate = 0. These parameters define an indivisible contract limited to one share, where the share of the contract has the value of one ticket, and any amount of the base Bitcoin within the transaction corresponds to one share of the contract. In this example, TotalIssuance is one ticket. The ticket can include an access code to the barrier upon entry to the event venue, thereby providing feedback that the ticket has been redeemed.

[0238] Example 11 - Voucher for a Celebrity Day. In this example, the contract states, "The right to a wonderful dinner for one person with George Kludgy at the Spiffy Hotel in the center of Sydney on March 31, 2016, including a taxi ride home." The metadata is defined to represent the following important parameters. NumShares = 1; ShareVal = 1 date, PeggingRate = 0. These parameters define an indivisible contract limited to one share, where the share of the contract has the value of one date, and any amount of the base Bitcoin within the transaction corresponds to one share of the contract. In this example, TotalIssuance is one day.

[0239] Example 12 - Haircut voucher. In this example, the contract states, "The holder has the right to receive one haircut and blow-dry, valid on weekdays excluding holidays." The metadata is defined to represent the following important parameters. NumShares = 0; ShareVal = 1 voucher; PeggingRate = 0. These parameters define an unlimited and indivisible contract, where the shares within the contract have the value of 1 voucher, and any amount of the underlying Bitcoin in a transaction corresponds to 1 share within the contract. In this example, TotalIssuance is not fixed.

[0240] Example 13 - T-shirt. In this example, the contract states as follows. "The owner has the right to receive a commemorative 'Dead Lizard' T-shirt for the 2016 world tour at a rate of 1000 satoshis per T-shirt." The metadata is defined to represent the following important parameters. NumShares = 0; ShareVal = 1 T-shirt; PeggingRate = 1000. These parameters define an unlimited and divisible contract, where the shares of the contract have the value of 1 T-shirt, and each multiple of 1000 satoshis within the transaction corresponds to 1 share of the contract. In this example, TotalIssuance is not fixed.

[0241] Example 14 - Unassigned seat ticket. In this example, the contract reads as follows: "The owner is eligible to attend the The Jazz Jivers concert at Sadie’s Pub on April 29, 2016 at a rate of 1000 satoshis per ticket. Only 137 spaces are available." The metadata is defined to represent the following important parameters. NumShares = 137; ShareVal = 1 ticket; PeggingRate = 1000. These parameters define a divisible contract limited to 137 shares, where the shares of the contract have the value of 1 ticket, and each multiple of 1000 satoshis within the transaction corresponds to 1 share of the contract. In this embodiment, TotalIssuance is 137 tickets.

[0242] Example 15 - Music File. In this example, the contract states the following. "The owner has the right to obtain one copy of the Dead Lizard album 'Chameleon Rising'." The metadata is defined to represent the following important parameters. NumShares = 0; ShareVal = one album; PeggingRate = 0. These parameters define an unlimited and indivisible contract, where the shares of the contract have the value of one file corresponding to the album, and any amount of the base bitcoins within the transaction corresponds to one share of the contract. In this example, TotalIssuance is not fixed.

[0243] Example 16 - Furniture Item from Catalog. In this example, the contract states: "The owner has the right to receive this wonderful unique antique Georgian escritoire in excellent condition." The metadata is defined to represent the following important parameters. NumShares = 1; ShareVal = one item, PeggingRate = 0. These parameters define a non - divisible contract limited to one share, where the shares of the contract have a value of 1, and any amount of the base bitcoins within the transaction corresponds to one share of the contract. In this example, TotalIssuance is one item.

[0244] Example 17 - A Set of Golf Balls. In this example, the contract states as follows. "The owner is eligible to obtain premium quality Tigger Wodes Class 'A' golf balls at a price of 600 satoshis for 12 balls." The metadata is defined to represent the following important parameters. NumShares = 0; ShareVal = 12 golf balls; PeggingRate = 600. These parameters define an unlimited and divisible contract, where the shares within the contract have the value of 12 golf balls, and each multiple of 600 satoshis within the transaction corresponds to one share within the contract. In this example, TotalIssuance is not fixed.

[0245] Processing device As described above, the issuer (I) 3, the first user (A) 5, and the second user (B) 7 can be associated with the first processing device 13, the second processing device 15, and the third processing device 17. The peer-to-peer distributed ledger 9 can also be associated with a plurality of processing devices 19.

[0246] Such a processing device may be part of an electronic device such as a computer, a tablet computer, a mobile communication device, a computer server, etc. In addition to the processing device, the electronic device may include a data store 11 and a user interface.

[0247] FIG. 13 is a diagram showing an example of the processing devices 13, 15, 17, 19. The processing devices 13, 15, 17, 19 include a processor 1510, a memory 1520, and an interface device 1540. The memory 1520 stores instructions and data for implementing the above-described methods 100, 200, 300, 400, 500, 600, 700, 800, and the processor 1510 executes instructions from the memory 1520 to execute the methods. The interface device 1540 can include a communication module that facilitates communication with the communication network 5 and, in some examples, communication with peripheral devices such as a user interface and the data store 11. The processing device 1501 can be an independent network processing device or can be part of another network element. Further, some of the functions performed by the processing device may be distributed among multiple network elements. For example, the issuer 3 can have a plurality of processing devices 23 that execute the methods 100, 200, 300, 400 in a secure local area network associated with the issuer (I) 3.

[0248] When this disclosure describes a user, issuer, merchant, provider, or other entity performing a particular action (including signing, issuing, determining, calculating, transmitting, receiving, creating, etc.), this language is used for clarity of explanation. It should be understood that these operations are performed by a computing device operated by these entities.

[0249] A signature can include performing an encryption function. The encryption function has an input of clear text and an input of a key such as a private key. The processor can execute a function to calculate a number or a string that can be used as a signature. The signature is provided together with the clear text to provide the signed text. If the message text or the key is changed by only 1 bit, the signature is completely changed. Although little computing power is required to calculate the signature, it is virtually impossible to recreate the message with a specific signature. Thus, the clear text is changed only when the private key is available, and an effective signature is attached. Further, other entities can easily verify the signature using a publicly available public key.

[0250] In most situations, encryption and decryption include a processor that executes an encryption function to calculate output strings representing the encrypted message or the clear text message, respectively.

[0251] Keys, tokens, metadata, transactions, offers, contracts, signatures, scripts, metadata, invitations, etc. are numbers, texts, or strings stored in a data memory, for example, variables in program code of the "string" or "int" type or other types or text files.

[0252] An example of a peer-to-peer ledger is the Bitcoin blockchain. Transferring funds or paying a fee in Bitcoin currency involves creating a transaction on the Bitcoin blockchain along with the funds or fees withdrawn from the transaction. An example of a Bitcoin transaction involves calculating a signature that includes the input transaction hash, the transaction amount, one or more destinations, the recipient's public key, and the signature created using the input transaction as the input transaction and the payer's private key. A transaction can be verified by confirming that the input transaction hash exists in a copy of the Bitcoin blockchain and that the signature is correct using the public key. To ensure that the same input transaction hash has not already been used elsewhere, the transaction is broadcast to a network of computing nodes (the "miners"). The miner accepts and records the transaction in the blockchain only if the input transaction hash has not yet been connected and the signature is valid. If the input transaction hash has already been linked to another transaction, the miner rejects the transaction.

[0253] Assigning a cryptocurrency to a token involves creating a transaction using the assigned cryptocurrency and representing the token in the metadata field of the transaction.

[0254] When two items are associated, this means that there is a logical connection between these items. In a database, for example, the identifiers of two items can be stored in the same record to associate the two items with each other. In a transaction, the identifiers of two items can be included in the transaction string to associate the two items with each other.

[0255] Using the Bitcoin protocol to redeem a script and / or unlock a token involves calculating a signature string for the script and / or transaction using a private key. The script may require two or more signatures derived from different private keys or other conditions. The output of this transaction is then provided to the miner.

[0256] Approving another entity can include calculating a signature string for the transaction using a private key and providing the signature string to the entity so that the entity can use the signature to verify the transaction.

[0257] A user having an account with another entity can comprise an entity that stores information about the user, such as an email address, name, and potentially a public key. For example, the entity can maintain a database such as SQL, OrientDB, MongoDB. In some examples, the entity can also store one or more of the user's private keys.

[0258] Those skilled in the art will understand that many variations and / or modifications can be made to the above-described embodiments without departing from the broad general scope of the present disclosure. Accordingly, the present embodiments are to be considered in all respects as illustrative and not restrictive.

Description of Reference Numerals

[0259] 3 Issuer 5 First User 7 Second User 8 Communication Network 9 Peer-to-Peer Distributed Ledger 11 Data Store 13 Processor 15 Processing Device 17 Processing Device 19 Processing Device

Claims

1. A transfer method implemented by a computer, comprising: generating a redemption script, wherein the redemption script is metadata including tokens, where the tokens are representations of tokenized entities or references to tokenized entities, and the metadata includes control data, and at least one public key, and generating a blockchain transaction (Tx) having an output (TxO) related to the digital asset and a hash of the redemption script; and the metadata is provided at a position specified as the position of the cryptographic key in the blockchain protocol within the redemption script.

2. The method according to claim 1, wherein the digital asset is an amount of cryptocurrency.

3. The method according to claim 1 or 2, wherein the tokenized entity is stored on or outside the blockchain.

4. The method according to any one of claims 1 to 3, further comprising submitting the blockchain transaction (Tx) to a blockchain network.

5. A computer program comprising machine-readable instructions that cause a processing device to perform the method according to any one of claims 1 to 4.

6. An apparatus configured to execute the method according to any one of claims 1 to 4.

Images