Blockchain-based Universal Tokenization System

Abstract

The present invention is a method for token creation, redemption, and transfer involving tokens on a peer-to-peer distributed ledger. [Solution] The method includes metadata associated with tokens in a redeem script, which is associated with transactions on a peer-to-peer distributed ledger. One aspect of the invention provides a method for issuing and / or transferring tokens, including generating a blockchain transaction (Tx) having an output (TxO) associated with a quantity, such as Bitcoin and a hash of the redeem script. The redeem script also includes metadata including tokens. A token is a representation of, or a reference to, a tokenized entity. The redeem script also includes at least one (preferably two or more) public cryptographic keys. The metadata is provided in the redeem script at locations specified in the underlying blockchain protocol as locations for the cryptographic keys.

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 methods for creating, transferring, and redeeming tokens that represent assets. The present disclosure has specific applications for creating tokens associated with transactions on a peer-to-peer distributed ledger, such as the Bitcoin blockchain, for example. 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 also include contractual rights that bind both parties. In the digital economy, there can be expectations 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 transferred property, such as the physical delivery of documents representing a contract, securities, etc., or the tangible assets themselves that have no value. More recently, blockchains have 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, immutable record of all transactions written to the blockchain from the beginning. Transactions contain small programs known as scripts that are incorporated into their inputs and outputs, specifying how and by whom the outputs of the 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 the nodes 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 the transaction - if the transaction is validated, the node relays it to other nodes in the network, ii) it is added to a new block built by the 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 well-known, but both the encrypted security system of Bitcoin and the data that can be stored on the blockchain for implementing new systems are being considered for use. Regardless of the field, it can be very advantageous if the blockchain can be used for automated tasks and processes. 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 produce results and executing 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 ledger. These include, without limitation, consensus-based blockchain and transaction chain technologies, permissioned, non-permissioned ledgers, shared ledgers, and their variants. A more widely 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 in this specification 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] The invention 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 blockchain. Additionally or alternatively, it can enable the control and / or transfer of ownership of assets or rights. This can be a digital or virtual asset such as a smart contract or a real-world / physical asset. 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 also 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 by using hash technology, 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 intercommunication 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, comprising the step of generating a blockchain transaction (Tx) having an output (TxO) associated with a digital asset (B1) and a hash (H1) of a redemption script, wherein the redemption script includes metadata comprising 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 unlock script that meets the requirements of the lock script of the output TxO. In particular, when hashed, it is necessary to present a redeem script that matches the hash provided by the lock script of the TxO. 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 unlock (redeem) script, the ownership of the cryptocurrency (B1) is transferred to the redeeming party or user, 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 necessary 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 methods of the above-described embodiments and includes a blockchain network and associated nodes.

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

[0014] The present invention can provide a computer-implemented method for creating a first token (T1) by an issuer (I). The first token (T1) can be associated with 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 a public key (P1A) of the first user, wherein the public key (P1A) of the first user forms an encryption pair with a private key (V1A) 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 public key (P1I) of a first issuer associated with the issuer (I), wherein the public key (P1I) of the first issuer forms an encryption pair with a 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). Determining a first hash (H1) of a first redemption script (RS1) based at least on first metadata (MD1) including information related to the first token (T1) and transmitting the first data output (O1) including the first hash (H1) via the communication network provide many advantages. First, since 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 unsuitable 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. Since the metadata contains a pointer to the terms and conditions of the contract, 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 transmit the entire transaction history, and the details of the related transactions can be 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 tokens representing venue tickets, and travel tickets or vouchers can be included. Yet another advantage is that the tokens 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 terms of the contract.

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

[0019] The information in the first metadata (MD1) may include at least one or more contract terms of the contract. The information in the first metadata (MD1) includes information regarding one or more types of contracts, one or more contract terms of the contract, pointers to the contract terms 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 sequential 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 includes sending, via a communication network, a request to open an account (ACA) for the first user (A), where this account (ACA) is associated with 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 a 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 for 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 for redeeming 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) for unlocking 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), and 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 quantity (B2) of a digital asset associated with a second token (T2), where the second token has a second token value (Tv2) based on the second part (R2). The method also includes determining a second hash (H2) of a second redemption script (RS2), where the second redemption script (RS2) is based at least in part on at least a 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 quantity (B2) of the digital asset to the first user (A), and the second hash (H2) associated with the second quantity (B2) of the digital asset (B2) to provide 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) in accordance with 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 in order 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 quantity (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 quantity (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 transmitting, 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 quantity (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 quantity (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 related to the second token (T2), where 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), where the second redeem script (RS2) is based at least in part on first metadata (MD1) related to the first token (T1), the public key (P1A) of the first user, and a first issuer public key (P1I) related to an issuer (I). In this method, a third data output (O3) for a 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), where the second hash (H1) is related to the second quantity (B2) of the digital asset and provides the second token (T2) related to 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] The 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 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 assets to the issuer (I) via the communication network.

[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 secret key (V1A) of the first user; signing the first redemption script (RS1A) signed by the first user to unlock the first amount (B1) of the digital asset associated with the first token (T1) with the secret key (V1I) of the first issuer; determining the public key (P1B) of the second user, wherein the public key (P1B) of the second user forms an encryption pair with the secret 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 a 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; 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 advantages of blockchain technology can be utilized 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 a 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 be used to encapsulate or represent 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 ease by transferring 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 a contract 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 tokens may be, for example, a bank, other financial institution, mint, company, or the like. 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 the communication network 8. The first user (A) 5 requests the creation of tokens from the issuer (I) 3, the redemption of tokens with the issuer (I) 3, or the transfer of some or all of the value of the tokens 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 also 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 the first user (A) transferring fiat currency (e.g., $1,000 AUD) to the 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 this first quantity (B) by the issuer (I) 3 remains “tokenized” or is converted to an “untokenized” cryptocurrency is an option for the issuer (I) 3.

[0061] As shown in FIG. 2(c), the third type of transaction involves the transfer of the value of the first token (T1) from the first user (A) 5 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 part 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 part (R1) + the second part (R2), and the first user (A) 5 desires to "use" the first part (R1) and return the second part (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 part (R1) of the token (T1) by transferring an amount as a token having the value of the first part (R1), and in return, receives non-fungible currency having a value representing the first part (RA). Only the first part (R1) is redeemed, and the remaining second part (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 part (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 that, as shown in Figure 3(b), the first user also has a first quantity (B1) representing the first token (T1) from the previous transaction. Next, the first user (A) transfers a third quantity (B3) to the second user (B) as a token with a value of the first portion (R1), thereby transferring the first portion (R1) of the token (T1). By transferring the third encrypted quantity (B3) as a token with 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 quantity (B2) as a token with a value representing the second portion (R2). In one example, the second quantity (B2) and the third quantity (B3) are derived from the first quantity.

[0065] The above detailed example of the transaction is described from here.

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

[0067] A non - limiting exemplary application of the method described herein is that the issuer (I) (e.g., a financial institution) deposits an amount of non - convertible currency (e.g., $1000 AUD), and the issuer (I) likewise creates a first token (T1) representing the value of the deposited non - convertible currency for the first user (A). Depending on the contract terms, the first user (A) can redeem the first token (T1) on a future date for the value associated with the deposited non - convertible currency. The contract terms may allow for at least a portion of the value of the token to be transferred to the second user (B). Such contract terms may be specific to this token or may be general contract terms 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 encrypted 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 comprises determining 140 a first hash (H1) of a first redemption script (RS1), wherein the first redemption script (RS1) includes at least first metadata (MD1) containing 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 encrypted pair with a secret key (V1I) of the first issuer.

[0070] The method 100 also includes 150 transmitting 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 a token such that the record of the token 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 the 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), since the first hash (H1) is sent to and recorded in the peer-to-peer distributed ledger 9, it is impossible (or difficult) to change the contract terms that will later provide the same first hash (H1). A detailed example of the issuer (I) 3 that creates 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 the 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 the 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 the 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 is only accessible 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 securely 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 the private key can be reproduced by combining them.

[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 of 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 travel ticket or 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 $1000 AUD deposit 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, for example, 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, via the communication network 8, a first token (T1) and, in some cases, a request for at least some of the contractual conditions from the first user (A) 5. The issuer (I) can determine 112 whether to accept the request, make a counter-offer modifying the contractual conditions of the request, or reject the request. The method 100 then includes 114, at step 112, sending 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 contractual conditions 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 by 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 120 of the public key of the first user Method 100 includes a 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, the 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 130 of the first quantity related to the token 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 (in this example, a blockchain), 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) can be 1000 satoshis / cent AUD, and the value of the first token (TV1) can be $1000 AUD. Thus, the first quantity (B1) can 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 this purpose, 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 greater 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 daily. In another example, the contract can also have a value that is 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 transaction fees. 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 infinitesimally 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 otherwise not recorded (or the cost of the transaction approaches or exceeds 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). Accordingly, method 100 can include determining a minimum threshold (MT1) suitable for a 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 in 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 involves a transaction of the first token (T1) that results in a second token (T2) representing the $200 AUD that remains with the first user (A)5 as change, and creates a third token (T3) representing the $800 AUD that is 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. Thus, it may be advantageous to allocate a sufficient amount (B1) to the first token (T1) so that the amount is divisible such that it can be used for the expected number of subsequent tokens. In one example, the contractual terms may specify the amount, or the minimum value of the token, or the denomination of the token. For example, the contractual terms can set $10 AUD as the minimum denomination of the token value. Thus, 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 140 of the first hash (H1) of the first redemption script (RS1) 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 hash functions used in P2SH scripts 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 script hash methods 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 for unlocking 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" out of the "n" signatures for signing must be done in the correct order. For example, let "m" be 2 and the number of public keys "n" 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) using 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 places available for the public key 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 include metadata taking the place of the public key. 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 (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, changing the value of the metadata, if not impossible, would be difficult 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 originally agreed contract. 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] Thus, at least the first metadata (MD1) includes both Metadata1 and Metadata2 that use two locations in the redemption script. This is followed in order by two public keys, the first public key (P1A) and the first issuer's public key (P1I). NumSigs is 2, meaning 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 if 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 a "non-fungible token". The next 16 bytes hold the IP address of the location of the actual electronic contract file, taking into account an IPv6 address. 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 that uses RIPEDMD-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 illustrated 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, the issuer (I) 3 can, in some cases, process the token in the transfer without reading the contract file for the key information necessary to process the transfer. Thus, including the key parameters in the metadata can greatly assist in processing efficiency.

[0118] In addition to the above information, 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 portion of the first token (T1), a second token (T2) is created by the issuer (I) to represent the value of the remaining portion, and the issuer can embed information in the metadata to associate the second token (T2) with the first token (T1). This can help to track the whereabouts and progress of the token without the issuer (I), such as a bank, having to expend the effort to trace through the history of the transaction, which can be a centralized task for the issuer (I).

[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). Multiple different rates can be set for the same fiat currency, but different tokens (with different contracts) are required for each different rate. The selection of the rate may be at the discretion of the issuer (I), but as described above, the issuer (I) can conduct a similar consideration for the pegging rate regarding 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 (where a token is generated from a cryptocurrency), a payment (where at least part of the token value is transferred from one user to another), or a redeem (where 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 malicious parties trying to determine a secret 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 secret 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 secret keys (V1A) of the first user and (P1I) of the issuer, respectively. The public keys may be widely known to the public, while in another example, it may be desirable to communicate the public keys as needed. In any case, since the corresponding secret keys are only needed when signing and unlocking a redemption script (such as during token exchange), only the public keys are 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 is accessed (or recreated) only 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 redemption 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 redemption 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 quantity (B1) of transactions. That is, it is to record that the quantity 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 quantity (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 saving a first redemption script (RS1) in the data store 11 for later use 160.

[0128] A specific example of a transaction that creates the 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, the first user (A) 5 wishes to deposit $1000 AUD with the issuer (I), and in exchange, the issuer (I) creates the 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 a 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 produced in the form of transaction-ID / Satoshis amount / locking script. Producing 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. This output, in <PubK-Issuer hash>, the redeem script indicates this output locked with the public key (P1I) of the first issuer. That is, this transaction can be unlocked using the corresponding secret key (V1I) of the first issuer.

[0133] As described above, method 100 includes allocating a first quantity (B1) suitable for the first token (T1). However, the quantity the issuer (I) has on hand may not exactly match the first quantity (B1). In the current example, the required first quantity (B1) is 10,000,000, which is considerably less 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 amount 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 "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 referenced 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 the "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 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 a first quantity (B1) associated with the first token (T1). Line 9 is the value of the output of the first quantity (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 quantity (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 including an indication that this is an "issuance" transaction. OP_EQUAL provides a boolean result for verifying the output.

[0143] The second entry reflects the change of the issuer for the transaction. Since the input, which was the previous transaction ID - 201, included 50,000,000 satoshis, the issuer can expect the remainder with respect to 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 returns 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 of the first issuer (P1I) represented by <PubK-Issuer hash>.

[0144] Generally, the output value of a transaction must be equal to or less than the input value. In the above example, the input is 50,000,000 and the output is 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 from the first user (A) 5 a request 610 to redeem a first token via the communication network 8. 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] The method 200 also includes step 260 of transmitting a second data output (O2) via the communication network 8 to the peer-to-peer distributed ledger 9 including a display of the transaction to the first quantity (B1) of the issuer (I).

[0149] Accordingly, the 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 spend the encrypted 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 fiat 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 one or more transactions that remove the 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 approval (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., 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), has 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 quantity received from the previous transaction, ID-610. This quantity is summarized as follows:

Table 6

[0157] The second row of Table 6 shows the quantity 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 of the token), 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 from rows 4 to 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 redemption script (RS1) requires two out of four signatures, specifically, signed with the first user's private key (V1A) and the first issuer's private key (V1I).

[0161] The second input is shown from rows 9 to 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 from rows 15 to 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 redemption script is as follows: 1 metadata1 metadata2 PubK-Issuer 3 OP_CHECKMULTISIG

[0163] This redeem script includes 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 notable that the public key of the first user (P1A) is not within 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 implied 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 part 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 part 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 from the first user (A) 5 a request to redeem the first token (T1) 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). Similarly, method 200 then includes the issuer (I) determining the public key (P1A) of the first user from the first user (A) 5. The issuer (I) may already have the public key (P1A) of the first user from a previous transaction (or within the 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 sent again by the first user (A) 5. Instead, the public key (P1A) of the first user may be received from the 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 step 645 of sending 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 allocating 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 allocating the second quantity (B2) may include considerations similar to those for allocating the first quantity (B1) described above.

[0174] In some examples, the pegging rate (PR2) of the second token (T2) is the same as the pegging rate (PR1) of the first token (T1), so it may be desirable for the first user (A) 5 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 with respect to 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 issuer (I) with respect to the second token (T2) 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 quantity (B2) for the first user (A)5 and the second hash (H2). The second hash (H2) is associated with the second quantity (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 characteristics similar 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 that includes 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 quantity (B2) to provide the second token (T2) to the first user (A)5. The second quantity (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 acting 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 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, is described in detail with reference to FIGS. 2(c) and 9. The first user (A) 5 sends a request to create a third token (T3) 710 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 to create a third token (T3) 810 via the communication network 8. 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 a request to create a third token (T3) 310 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) may 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 at least based 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 the same or similar considerations as determining the first hash (H1) of the first redemption script (RS1) of method 100, or determining the second hash (H2) of the second redemption script (RS2) of method 200. Method 300 further includes transmitting, via a communication network, a third data output (O3) to at least a second user (B) of a third amount (B3) transaction, 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). The third hash (H3) is the third encrypted amount (B3)) to provide a third token (T3) associated with the second user (B)7 and the issuer (I). 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 above value 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] Returning to the first user (A) 5 in the form of the second token (T2) will be 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 assigning 365 a second amount (B2) for association with the second token (T2), where the second token has 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 to the second user (B) as a third token (T3) 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 having 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] Row 3 of both ID - 101 and ID - 102 represents the output script of each transaction and is similar to row 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 shows 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 marks this first input with 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 marks this second input with the outputs to both the first output and the second output. This is because this second block of 50,000,000 satoshis is divided 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 of the first issuer (V1I) for the previous output script included in the public key of the first issuer (P1I).

[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 for 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 of the first user (P1A) and the public key of the first issuer (P1I). Importantly, the public key of the first user (P1A) 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 of the first issuer (P1I) 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 of the first token (TV1) of the first token (T1) is equal to the sum of the value of the second token (TV2) and the value of the third token (TV3).

[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 additional tokens 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 to 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 who have 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 because 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 for redeeming the first token (T1), such variations 200', 600' will be described hereinafter 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 to redeem the first token (T1) from the first user (A) 5 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 recreating 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 recreate the first redemption script (RS1).

[0215] Method 200' then includes transmitting 230 a first redemption script (RS1) for signing by a first user (A) 5 via a communication network 8. Similarly, the first user (A) 5 receives 620 the first redemption script (RS1). 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 630 the first redemption script (RS1) to provide a first redemption script (RS1A) signed by the first user using the secret key of the first user (V1A). The first redemption script (RS1A) signed by the first user is for the communication network.

[0217] Similarly, method 200' includes receiving 240 the first redemption script (RS1A) signed by the first user via the communication network 8. Method 200 further includes signing 250 the first redemption script (RS1A) signed by the first user with the secret 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 sending 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) may be returned to the issuer (I) and no longer associated with the first token (T1). In some cases, metadata associated with the first quantity (B1) may remove the act of “untokenising” the cryptocurrency. This may be done in the same transaction or the next transaction, and may be at the discretion 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 the first redemption script (RS1). This can be advantageous to prevent accidental or non-intentional spending of the first quantity (B1) by the first user (A)5 beyond the intended purpose of the token, or to reduce the 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 improved. For example, when redeeming the first token (T1), the order of the public keys is such that after the first user (A)5 signs the first redemption script (RS1), it is then sent to the issuer (I) for the final signature. Since the issuer (I) provides the final unlock signature, this reduces the risk that someone eavesdropping on the communication between the issuer (I) and the first user (A)5 can illicitly access 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 secret key (V1A) of the first user and using it to sign the first redemption script (RS1), this 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 over the communication network 8.

[0222] The first user (A)5 receives the first redemption script 720 and signs the first redemption script with the secret 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 over the communication network 8 740.

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

[0224] Method 300' can further include steps 360, 370, 380, and 390 to complete the creation of a 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 with the name of a participant, i.e., where the rights are granted to an entity with a specific name 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 allocated across multiple tokens (i.e., allocated 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 of 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 greater 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. A 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. Therefore, there are no additional shares issued under a 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 additional 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., the inventory warehouse) in order to undertake 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 promises 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 indivisible (i.e., it can only be transferred in its entirety 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-fungible 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 limited contract. In the case of an unlimited contract, the issuance is not fixed and there may be more shares issued. If the shares are represented as a percentage, by definition, TotalIssuance = 100%. For a limited contract, NumShares, ShareVal, and TotalIssuance are related as follows:. NumShares x ShareVal = TotalIssuance If the value of TotalIssuance is 0, it results in an unrestricted contract. An example of an unrestricted contract is with non - convertible 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 a venue that has been issued tickets, where TotalIssuance = total available seats. Circulation is defined as the total value of unused tokens (i.e., determined by transactions in unspent transaction outputs - UTXO). The complete set of all unspent transactions is maintained in a list available on all Bitcoin nodes. For example, if the issuer initially issues $10,000 worth of tokens as non - convertible currency type and over time $5500 worth of tokens are redeemed, then the circulation = $4500 (as the value of un - redeemed tokens). This value needs to be reconciled with the balance of the associated 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 a racehorse (where by definition TotalIssuance = 100%). The buyer can redeem the tokens by sending them back to the breeder, and if she reverse - tokens them, the currency is only 9 shares which is 90% of the horse, while the reserve (= stable) is 100% of the whole 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 - token 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 basis." 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 for 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 a non - divisible contract limited to 1000 shares where each share within the contract has 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 base". 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 each share of the contract has 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 - Fiat 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 unlimited and divisible contract where each share of the contract has 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 Australian dollars (AUD) at a rate of $10,000 per underlying 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 a multiple of 100 in the transaction corresponds 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 limited to 10 shares where the shares within the contract have a value of 10%, and a multiple of 600 satoshis in the 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 multiple of 600 satoshis in the 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 1 ticket, and any amount of the base bitcoin within the transaction corresponds to one share of the contract. In this example, TotalIssuance is 1 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 obtain 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 1 date, and any amount of the base bitcoin within the transaction corresponds to one share of the contract. In this example, TotalIssuance is 1 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 share of the contract has the value of one file corresponding to the album, and any amount of the base bitcoin within a 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 an indivisible contract limited to one share, where the share of the contract has a value of 1, and any amount of the base bitcoin within a 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 a 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 methods 100, 200, 300, 400, 500, 600, 700, 800 described above. 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 a plurality of 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, deciding, 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 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 on the blockchain only if the input transaction hash is not already connected and the signature is valid. If the input transaction hash is already 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, etc. 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 should be considered in all respects as illustrative and not restrictive.

Explanation of Signs

[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 tokenization method implemented by a computer, comprising: generating a blockchain transaction (Tx) including an output (TxO) related to an amount of cryptocurrency (B1) and a lock script; wherein the lock script is metadata including information associated with a token (T1) that is a representation of a digital asset or a reference to a digital asset, the metadata including a randomly generated value, and at least one public key; A method comprising.

2. The method according to claim 1, wherein the token (T1) is provided in a redeem script of a blockchain transaction (Tx).

3. The method according to claim 1 or 2, comprising allocating the amount of cryptocurrency (B1) for association with the token (T1).

4. i) storing the digital asset on or outside the blockchain; and / or ii) providing an unlock script that meets the requirements of the lock script for the output (TxO) to transfer ownership of the amount of cryptocurrency to a redeeming party or user. The method according to any one of claims 1 to 3, comprising.

5. The metadata i) includes information associated with the token; and / or ii) includes a pointer to a file, control data, information related to a contract, information related to the token, and / or information related to how to hold the blockchain transaction (Tx). The method according to any one of claims 1 to 4, comprising.

6. The metadata i) is hashed; and / or ii) is provided in the lock script of the output (TxO) so as to be interpreted or appear to be interpreted by the blockchain protocol as a cryptographic key. The method according to any one of claims 1 to 5, comprising.

7. The lock script includes an operation of comparing a signature with a public key; and / or The blockchain transaction (Tx) is an N-of-M blockchain transaction. The method according to any one of claims 1 to 6, comprising.

8. The token is related to a contract, and the blockchain transaction and / or metadata are as follows: i) the amount of shares available under the contract, ii) the amount of the transfer unit transferred from the transmission side to at least one reception side, iii) a factor for calculating a value for the amount of the transfer unit, A parameter or data item including The method according to any one of claims 1 to 7.

9. For the association with the token (T1), the step of allocating the amount of the cryptocurrency (B1) includes: determining a token value (TV1) of the token (T1); determining a pegging rate (PR1) of the token (T1); determining the amount of the cryptocurrency (B1) based on the pegging rate (PR1) and the token value (TV1); The method according to any one of claims 3 to 8.

10. For the association with the token (T1), the step of allocating the amount of the cryptocurrency (B1) includes: determining a minimum threshold (MT1) of the amount of the cryptocurrency of the token (T1); determining an amount of the cryptocurrency (B1) equal to or greater than the minimum threshold (MT1); The method according to any one of claims 3 to 9.

11. The metadata is provided in the blockchain transaction, so that the blockchain protocol does not depend on the existence of the token (T1) and / or other metadata in the lock script, and the metadata can be interpreted and used as a token by the user, and / or the transfer of the token (T1) is executed via the blockchain without changing the underlying blockchain protocol. The method according to any one of claims 1 to 10.

12. transmitting or receiving a request for the token (T1) via a communication network, or embedding information in the metadata to associate a second token (T2) with the token (T1), including and / or The encryption key forms an encryption pair including a private key and a public key, and the public key and / or the private key are stored in an electronic wallet or a data store. The method according to any one of claims 1 to 11.

13. A computer program including machine-readable instructions for causing a processing device to execute the method according to any one of claims 1 to 12.

14. An apparatus including a processing device that executes the method according to any one of claims 1 to 12.

Images