Computer-implemented method and system for providing access to multiple functions and applications associated with blockchain

Abstract

A computer-implemented method and system is provided that enables interaction between a device and an asset transfer platform. And interaction is performed only under the condition that the license data structure is allowed.

Description

Technical Field

[0001] The present disclosure generally relates to methods and systems for implementing a platform for one or more services associated with a distributed ledger (i.e., blockchain) of one or more clients. In particular, the present disclosure relates to, but is not limited to, providing access to multiple functions and applications associated with a blockchain of one or more clients, such as enabling the transfer of digital or tokenized assets. Background Art

[0002] In this article, the term "blockchain" covers all forms of computer-based electronic distributed ledgers. These ledgers include consensus-based blockchain and transaction chain technology, licensed and non-licensed ledgers, shared ledgers, public and private blockchains, and variants thereof. It should be noted that the present disclosure is not limited to use with alternative blockchain implementation schemes and protocols associated with any type of digital assets or representations of digital assets that fall within the scope of the present disclosure. In this article, the terms "client", "entity", "node", "user", "sender", "receiver", "payer" and "recipient" may refer to computing or processor-based resources. The term "digital asset" may refer to any transferable asset, such as a token representing at least a portion of property, a smart contract, a license (i.e., a software license) or a DRM contract for media content. It should be understood that the term "digital asset" used throughout this article represents a commodity that may be associated with a value that can be transferred from one entity to another or provided to another entity as a payment in a transaction.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer-based system that consists of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, so blocks are linked together to create a permanent and unchangeable record of all transactions written to the blockchain since its creation. Transactions contain small programs embedded in their inputs and outputs, called scripts, which specify how and by whom the outputs of the transaction can be accessed. On some platforms, these scripts are written in a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be "verified". Network nodes work to ensure that each transaction is valid, and invalid transactions are rejected by the network. The software clients installed on these nodes perform this verification work on unspent transactions (UTXO) by executing their locking scripts and unlocking scripts. If the execution of the locking script and unlocking script evaluates to true (TRUE), then the transaction is valid and the transaction is then written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, the transaction must be: i) verified by the first node that receives the transaction, and if the transaction passes verification, the node relays it to other nodes in the network; ii) added to a new block; iii) mined, that is, added to the public ledger of past transactions.

[0005] It should be understood that the nature of the work performed by the network nodes will depend on the type of consensus mechanism used to maintain the blockchain. It should be understood that other consensus mechanisms may be used, such as proof of stake (PoS), delegated proof of stake (DPoS), proof of capacity (PoC), proof of elapsed time (PoET), proof of authority (PoA), etc. Different consensus mechanisms differ in how mining is distributed among nodes. It should be understood that the handling of transaction fees is part of the underlying mechanism for submitting data to a public blockchain.

[0006] As previously mentioned, each transaction in a given block encodes a transfer of control of a digital asset between participants of the blockchain system. For example, a digital asset may relate to a digital representation of a document, an image, a physical object, etc. In some cases, transfers between participants may be processed by an entity that is different and / or independent from the entity that maintains the transaction ledger using the blockchain.

[0007] Once stored as a UTXO in the blockchain, the user can transfer control of the associated resource to another address associated with an input in another transaction. This transfer is usually done using a digital wallet, but this is not the case in reality. The digital wallet can be: a device; a physical medium; a program; an application on a computing device such as a desktop, laptop, or mobile terminal; or a remote hosting service associated with a domain on a network such as the Internet. Digital wallets store public and private keys and can be used to: track ownership of resources, tokens, assets, etc. associated with a user; receive or spend digital assets; transfer tokens that may be associated with digital assets such as licenses, property, or other types of resources.

[0008] Digital entrepreneurs are exploring how to implement new systems using cryptographically secure systems and data that can be stored on blockchains. It would be very beneficial if blockchains could be used to automate tasks and processes. Such solutions would be able to leverage the advantages of blockchains (e.g., permanent, tamper-proof event records, distributed processing, etc.) while being more widely applicable.

[0009] One area of ​​current research is the use of blockchain to implement "smart contracts." These are computer programs designed to automatically execute the terms of a machine-readable contract or agreement. Unlike traditional contracts written in a natural language, smart contracts are machine-executable programs that include rules that process inputs to produce results and then cause actions to be performed based on those results.

[0010] Specifically, one area of ​​research is asset transfers and how they can be recorded on a blockchain to ensure that the transfers benefit from the immutability of the blockchain. In addition, in addition to the means of recording such transfers, there is a need to provide an efficient and secure asset transfer protocol to ensure that asset transfers are securely documented and recorded with the support of the underlying blockchain infrastructure. Summary of the invention

[0011] The word "comprise" or variations such as "comprises" or "comprising" used throughout this specification will be understood to mean the inclusion of stated elements, integers, steps or groups of elements, integers or steps but not the exclusion of any other elements, integers or steps or groups of elements, integers or steps.

[0012] In some embodiments, a computer-implemented method of verifying at least one data item is provided. The data item may be provided during an asset transfer event. The data item may be an alphanumeric sequence of characters. The data item may be a number. The data item may be a string of characters generated randomly or pseudo-randomly. The method is implemented by a processing resource. The processing resource may be a software-based or hardware-based resource. The method may include receiving request data from a computing device. The computing device may be a mobile computing device. The request data may include an instruction data set, the instruction data set including an identifier of an entity associated with the asset transfer event. The request data may also include a challenge data structure. The challenge data structure may include a first numeric identifier of the at least one data item; and / or a representation of the at least one data item.

[0013] The method may include determining the validity of the at least one data item by:

[0014] - determining concurrence between the representation of the at least one data item and a data item stored in the license data structure by determining that a corresponding credential exists in the instruction data set or in a license data structure associated with the entity. The corresponding credential may be the same data item or another data item that is equivalent to the data item. For example, the corresponding credential may be a hash of the data item.

[0015] The method may include generating a second digital identifier for the corresponding credential in a corresponding instruction data set or license data structure.

[0016] The method may include generating response data including: an identifier of the corresponding credential; and / or the second digital identifier; and / or a signature associated with the first digital identifier and the second digital identifier.

[0017] The method may also include sending the response data to the computing device.

[0018] In other embodiments, a computer-implemented method of verifying at least one data item is provided. The data item may be provided during an asset transfer event. The data item may be an alphanumeric sequence of characters. The data item may be a number. The data item may be a string of characters generated randomly or pseudo-randomly. The method is implemented by a first processing resource. The first processing resource may be a payment processing resource or an instance of a payment processing resource. The method may include generating request data. The request data may include an instruction data set, the instruction data set including an identifier of an entity associated with the asset transfer event and / or a challenge data structure, wherein the challenge data structure may include a first numeric identifier of the at least one data item; and / or a representation of the at least one data item.

[0019] The method may also include sending the request data to a second processing resource. The second processing resource may be any computing device. The second processing resource may be an instance of a payment processing resource.

[0020] The method may also include receiving response data from the second processing resource.

[0021] The method may further comprise verifying the data item by determining from the response data that there is a signature of the combination of the second digital identifier in combination with the first digital identifier.

[0022] In some embodiments, a computer-implemented method for providing access to an asset transfer processing platform is provided. The asset transfer processing platform may be a resource that processes payments according to a payment processing protocol. The asset transfer processing platform may be implemented using any processing resource. The method may be implemented by a processing resource, which may be implemented by a cloud or by a collection of localized hardware or software resources. The method may include receiving a message from a client device associated with a user. The message may be received via a data communications network or another suitable means (e.g., via an application programming interface (API) call). The client device may be any computing device. The message may include at least one identifier of a message type associated with the message. This may be implemented using parameters in an API call. This may also be implemented using parameters in a message transmitted over a data communications network. The message may also include at least one identifier associated with a profile registered on the asset transfer processing platform, wherein the profile is associated with at least one event stream provided by the asset transfer processing platform, wherein the at least one event stream is associated with at least one asset type.

[0023] An event stream may include an append-only log supported by a blockchain, in which data recorded in blockchain transactions are added to a time-ordered log. That is, the event stream records data recorded on the blockchain in chronological order (i.e., in the order in which it occurs in the sequence of blockchain transactions). An event stream may be implemented using any suitable data structure. An event stream may include a series of entries stored in a sequence, wherein each entry in the sequence is referenced in the sequence by a monotonically increasing number. That is, the first entry in the event stream is entry 1, the second entry is entry 2, and so on. Writing data to an event stream using a blockchain transaction means that it can be guaranteed that the individual entries in the event stream have not been modified since being written, no entries have been inserted between previous consecutive entries, no entries have been deleted, and no entries have been reordered. It is also impossible for unauthorized parties to append events to the event stream. The message may also include request data associated with the request, the request being associated with the message and the profile. The request data may include instruction data associated with the request. The instruction data may identify the parties and / or permit data structures to be used to process the request.

[0024] The profile may correspond to an allocation of asset transfer platform resources for processing asset transfers using the asset transfer platform. An instance of the asset transfer platform associated with the profile may utilize the allocated resources to perform processing steps as part of the method.

[0025] The method may also include determining the message type associated with the message and the profile registered on the asset transfer processing platform based on the received message. Determining the message type may include processing the request to determine the presence of a parameter in an API call or a parameter in a message transmitted over a data communications network.

[0026] The method may also include identifying a message response protocol for the determined message type based on the determined message type. The message response protocol defines a series of criteria for determining a response type or content of a response to be provided to the requestor. The message response protocol may define requirements for a request in order to perform an action on the request. The message response protocol may require access to a license data structure to determine the presence of a data item or cryptographic signature.

[0027] The method may also include a license data structure identifying the profile, wherein the license data structure provides at least a standard that defines which users can interact with the profile using the determined message type. The license data structure may include a public key, an encrypted signature generated using a private key corresponding to the public key, at least one data item, and a license identifier. The private key and the public key may be paired in an encrypted manner. The private key and the public key may be generated using an elliptic curve digital signature algorithm (ECDSA) technique. The data item may be an alphanumeric sequence or a digital sequence.

[0028] The method may also include processing the request data to determine that there is an encrypted signature used to sign the request data, and based on determining that there is an encrypted signature used to sign the request data, further processing the request data to extract a data item from the request data.

[0029] The method may also include applying the identified message response protocol to the extracted data items. The applying may include using the data items in the request data to determine whether an action may be taken in response to the request. The data items may include identification of the parties, identification of the license data structure, identification of the account holder and / or account manager, and identification of the asset type.

[0030] An account holder may correspond to a user associated with the profile registered on the asset transfer platform. An account holder may correspond to an account, which may be a funding account containing a supply of money used in transactions using the asset transfer platform. Alternatively or additionally, the account may correspond to an asset register, in which the supply of assets of a particular asset type may be registered. Such an account may be a gold account. An account manager may correspond to a bank that manages the funding account or an asset registry for managing the asset register. For example, in the example of a gold account, the account manager may be the Royal Mint at Llantrisant CF72 8YT, England, and the asset registry is an account opened by an individual at the Royal Mint. Another example may be a funding account opened at HSBC, in which the account manager will be HSBC, and the asset registry will be a funding account for its GBP (i.e., British Pound) savings.

[0031] The method may also include generating a response to the message based on the message response protocol, the extracted data items, and the license data structure by using the license data structure to determine whether the user is permitted to interact with the profile using the identified message type.

[0032] The method may also include using the message response protocol to determine whether the extracted data items meet the requirements of the determined message type; and based on the requirements of the determined message type being met, generating response content by interacting with the at least one event stream, wherein the at least one event stream is associated with the profile.

[0033] In other embodiments, a computer-implemented method is provided that enables a user to update a balance associated with an asset transfer processing platform. The asset transfer processing platform may be a resource that processes payments according to a payment processing protocol. The asset transfer processing platform may be implemented using any processing resource. The method may be implemented using a processing resource that may be implemented using software or hardware or using a cloud-based resource.

[0034] The method may also include receiving a message from a client device associated with the user.

[0035] The message may also include at least one of: an identifier associated with a balance update; at least one identifier associated with a profile registered on the asset transfer processing platform.

[0036] The method may also include determining, from the received message, at least one profile identified in the message.A profile may correspond to an instance of the asset transfer platform.

[0037] The method may also include applying an update request protocol to the extracted data item to determine whether the balance can be updated. The update request protocol may include a series of criteria for determining whether the balance can be updated, i.e., whether a transfer can be made from the account. A transfer from the account may be a transfer of a portion of the asset to another party.

[0038] The method may also include generating a response to the message based on the update request protocol, the extracted data items, and the permissions data structure by: using the permissions data structure to determine whether the user has the cryptographic permissions required to update the balance; using the update request protocol to determine whether the update can be performed; and generating response content based on satisfying the requirements of the determined message type by updating the balance and interacting with the at least one event stream, wherein the at least one event stream is associated with the profile.

[0039] Interacting with the event stream may include at least one of: viewing the event stream; retrieving data from the event stream; writing to the event stream; reading from the event stream; or appending data to the event stream. Any interaction with the event stream may generate its own response content. The response content may be a message sent to the entity requesting interaction with the event stream or a message sent to an entity associated with the event stream.

[0040] In some embodiments, a computer-implemented method for enabling access to the asset transfer processing platform is provided. The method may be implemented by a processing resource. The method may include initializing an application on the computing device, the application configured to generate a message. The message may include at least one of the following: at least one identifier of a message type associated with the message; at least one identifier associated with a profile registered on the asset transfer processing platform, wherein the profile is associated with at least one event stream implemented by the asset transfer processing platform, wherein the at least one event stream is associated with at least one asset type; request data associated with a request, the request being associated with the message and the profile.

[0041] The method may also include receiving input from a user, the input identifying a message type of the message to be sent to the asset transfer processing platform. The input may also identify a profile registered with the asset transfer processing platform. The input may also include request data including content of a request to be made to the asset transfer processing platform.

[0042] The method may further include applying a cryptographic signature to the request data to generate signed request data.

[0043] The method may also include generating a message including: an identifier of the message type of the user identification; an identifier of the profile registered on the asset transfer processing platform; and the signed request data.

[0044] The method may also include sending the message to the asset transfer processing platform.

[0045] In other embodiments, an asset transfer processing platform is provided. The platform may be configured to receive a message from a client device associated with a user, the message comprising:

[0046] - at least one identifier of a message type associated with said message;

[0047] - at least one identifier associated with a profile registered on the asset transfer processing platform, wherein the profile is associated with at least one event stream, the at least one event stream is associated with the asset transfer processing platform, wherein the at least one event stream is associated with at least one asset type; and

[0048] - request data relating to a request associated with said message and said profile.

[0049] The platform may be configured to determine, from the received message, the message type associated with the message and the profile registered on the asset transfer processing platform.

[0050] The platform may also be configured to identify a message response protocol for the determined message type based on the determined message type.

[0051] The platform may also be configured to identify a license data structure for the profile, wherein the license data structure provides criteria defining which users may interact with the profile using the determined message type.

[0052] Interaction with the profile may include any interaction with the event stream associated with the profile.

[0053] The platform can be configured to process the request data to determine the presence of a cryptographic signature used to sign the request data, and based on determining the presence of the cryptographic signature used to sign the request data, further process the request data to extract data items from the request data to be used to determine a response using the identified message response protocol.

[0054] The platform may be configured to apply the identified message response protocol to the extracted data items.

[0055] The platform can also be configured to generate a response to the message based on the message response protocol, the extracted data items and the permission data structure in the following manner: using the license data structure to determine whether the user has the encryption authority required to interact with the profile using the identified message type; using the message response protocol to determine whether the extracted data items meet the requirements of the determined message type; and based on the requirements of the determined message type, generating response content by interacting with the at least one event stream, wherein the at least one event stream is associated with the profile.

[0056] In some embodiments, a computer-implemented method of appending entries to at least one event stream is provided. The event stream may include an append-only log supported by a blockchain, in which data recorded in blockchain transactions are added to a time-ordered log. That is, the event stream records data on the blockchain in chronological order (i.e., the order in which it appears on the blockchain). The event stream may be implemented using any suitable data structure. The event stream may include a series of entries stored in a sequence, wherein each entry in the sequence is referenced in the sequence by a monotonically increasing number. That is, the first entry in the event stream is entry 1, the second entry is entry 2, and so on. Utilizing the underlying blockchain means that it can be guaranteed that the individual entries in the event stream have not been modified since they were written, no entries have been inserted between previous consecutive entries, no entries have been deleted, and no entries have been reordered. It is also impossible for unauthorized parties to append events to the event stream. The at least one event stream may belong to an asset account associated with a user registered on an asset transfer platform. The method may be implemented by a processing resource. The processing resource may be hardware or software implemented.

[0057] The method may include receiving a request to append an entry to the at least one event stream, the entry including instruction data and an identifier of the at least one event stream. The instruction data may relate to a transaction being processed by the processing resource or by another resource in communication with the processing resource. The request may be received over a data communications network or through an application programming interface (API) call. The method may also include retrieving the identifier of the at least one event stream from the request. The identifier may identify an instance of a payment processing resource associated with the at least one event stream. Based on the identifier, the method may also include accessing the at least one event stream and obtaining a log of previous entries associated with the identified at least one event stream. The log of previous entries may be pruned. The pruning may delete entries that are older than a specified expiration date. The method may also include retrieving the instruction data from the request. The instruction data may include a plurality of data items that may be further processed by the processing resource.

[0058] The method may include generating a unique identifier for the instruction data. Generating the unique identifier may include retrieving the unique identifier from the instruction data. Such a unique identifier may be an encrypted signature for signing the instruction data. Generating the unique identifier may include processing the instruction data to generate the identifier using a hash algorithm or the like.

[0059] Based on the generated unique identifier, the method may also include determining whether data identical to the instruction data is present in a log of previous entries associated with the identified event stream. This may include searching the log for the generated unique identifier to determine whether it is present in the log of previous entries. The log of previous entries may be a database of transactions that have been recorded in the event stream.

[0060] Based on a result of the determining step, the method may further include appending an entry to the at least one event stream, the entry including the unique identifier of the instruction data; or rejecting the entry of the event stream as a duplicate entry.

[0061] The embodiments may be used in combination in whole or in part. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Various aspects and embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0063] Figure 1a A system according to an embodiment is shown;

[0064] Figure 1b A node configured to implement software for verifying blockchain transactions is shown;

[0065] Figure 1c A blockchain network is shown;

[0066] Figure 1d , Figure 1e and Figure 1f is a schematic diagram of the tiered licensing structure;

[0067] Figure 2 shows the establishment of an instance of a payment processing resource according to an embodiment;

[0068] Figure 3 is a flow diagram illustrating how computing devices interact to retrieve information from an event stream;

[0069] Figure 4a and Figure 4b is a flow chart illustrating how a payment processing device may process a transaction;

[0070] Figure 5a and Figure 5b is a flow chart illustrating how to verify a data item using a challenge data structure and a response data structure;

[0071] Figure 6 is a flow chart showing how the event flow attaches transaction-related data;

[0072] Figure 7 The rendezvous transaction is shown;

[0073] Figure 8 Dust chains are shown;

[0074] Fig. 9 shows the flow of events for the parties to a transaction;

[0075] Fig.10 is a flow chart showing how to adjust the settings of an instance of a payment processing resource; and

[0076] Fig.11 is a flow chart showing how to prevent duplicate transactions. DETAILED DESCRIPTION

[0077] A detailed discussion of aspects and embodiments of the present disclosure is now provided to provide the reader with a full and complete understanding of the present disclosure.

[0078] From a first aspect, there is a computer-implemented method of verifying at least one data item. The data item may be provided during an asset transfer event. The data item may be an alphanumeric sequence of characters. The data item may be a number. The data item may be a string of characters generated randomly or pseudo-randomly. The method may be implemented by a processing resource, which may be any computing device. The processing resource may be a payment processing resource. The method may include receiving request data from a computing device. The request data may be passed in an application programming interface (API) call. The request data may be transmitted using a data communications network.

[0079] The request data may include an instruction data set including an identifier of an entity associated with the asset transfer event. The request data may include a challenge data structure, wherein the challenge data structure may include a first numeric identifier of the at least one data item; and / or a representation of the at least one data item. The representation may be an alphanumeric sequence. The representation may be a hash of the at least one data item.

[0080] The method may also include determining the validity of the at least one data item by determining the concurrence between the representation of the at least one data item and the data item stored in the license data structure by determining that a corresponding credential exists in the instruction data set or in a license data structure associated with the entity. The corresponding credential may be a hash of the data item.

[0081] The method may further include generating a second digital identifier for the corresponding credential in the corresponding instruction data set or license data structure.

[0082] The method may further comprise generating response data comprising: an identifier of the corresponding credential; and / or the second digital identifier; and / or a signature associated with the first digital identifier and the second digital identifier.

[0083] The method may also include sending the response data to the computing device.

[0084] The method according to the first aspect provides a method for securely verifying a data item. The data item may be exchanged during an asset transfer event (e.g., a funds transfer). The data item is securely verified because the signature is provided only if the data item can be verified based on the license data structure or another data structure. A plurality of data items may be provided, and the method may be repeated for each of the plurality of data items. The provider of the response data structure needs to provide the signature associated with the first digital identifier and the second digital identifier to indicate that they have verified the data item. The signature cannot be provided based on a license data structure that the provider of the response data does not own, because the owner's private key is required to generate the signature. The response data structure may identify a satisfactory license data structure (e.g., using a license identifier), and this enables a party to determine a license data structure that can be used to check the signature, which has been used to generate the signature associated with the identifier. The signature may be an encrypted signature. The provider of the challenge data structure provides a digital identifier (the second digital identifier) ​​so that the provider of the response data structure cannot simply replay the signature from a license data structure that they do not own. The provider of the response data structure provides a digital identifier so that the provider of the challenge data structure cannot simply "fish" for the signature of a useful message.

[0085] The first digital identifier and the second digital identifier may be random numbers generated for the corresponding data item or response data. The first digital identifier and the second digital identifier may be random numbers based on the corresponding data item or response data. The combination of the first digital identifier and the second digital identifier may be a concatenation of the first digital identifier and the second digital identifier, wherein the second digital identifier may be located at a first position in the concatenation of the first digital identifier and the second digital identifier.

[0086] The method may comprise determining consistency between the representation of the data item and a data item stored in a license data structure, the license data structure being associated with the entity, by:

[0087] - obtaining said representation of said data item from said challenge data structure;

[0088] - querying the instruction data set to obtain the credential corresponding to the data item; and

[0089] - based on the query, retrieving an identifier corresponding to the credential, or querying a license data structure associated with the identifier of the entity to obtain a credential corresponding to the data item; and

[0090] - based on said querying of said license data structure, retrieving an identifier corresponding to said voucher corresponding to said data item. The method may further comprise generating a response content comprising an indication of verification of said data item.

[0091] If the corresponding instruction data or license data structure contains a field containing the same representation of the data item, the query may only return the voucher corresponding to the data item. If the corresponding instruction data or license data structure does not contain a field containing the same representation of the data item, the query provides a rejection response.

[0092] The challenge data structure may also include an identifier for the challenge data structure, and the response data may include an identifier for the response data structure. The challenge data structure and the identifier for the response data structure may correspond in some suitable manner. This may mean that the response data structure refers to the challenge data structure. The identifier for the challenge data structure may be the same as the identifier for the response data structure. The identifier for the response data structure provides the advantage of a recordable link between the response data structure and the challenge data structure and a corresponding license data structure.

[0093] Viewed from a second aspect, there is provided a computer-implemented method for verifying at least one data item during an asset transfer event. The method may be implemented by a first processing resource. The method may include generating request data. The request data may include:

[0094] - an instruction data set, the instruction data set may include an identifier of an entity associated with the asset transfer event; and / or

[0095] A challenge data structure, wherein the challenge data structure comprises:

[0096] o a first numerical identifier of the at least one data item; and / or

[0097] o A representation of the at least one data item.

[0098] The method may comprise sending the request data to a second processing resource.The request data may be sent using any suitable means (eg a data communications network or an API call).

[0099] The method may include receiving response data from the second processing resource.

[0100] The method may comprise verifying the data item by determining from the response data that there is a signature of the combination of the second digital identifier in combination with the first digital identifier.

[0101] The method according to the second aspect provides a method for verifying a data item, the method involving sending request data to a second processing resource, the request data comprising a challenge data structure, the challenge data structure identifying the data item and comprising a representation of the data item. The data item can only be determined by providing a signature. The signature can be checked using a license identifier that can be provided in the response data.

[0102] The first and second aspects may be implemented using a suitably configured system.

[0103] From another aspect, a computer-implemented method for providing access to an asset transfer processing platform is provided. The method may be implemented by processing resources. The method may include receiving a message from a client device associated with a user. The message may include at least one identifier of a message type associated with the message. The message may also include at least one identifier associated with a profile registered on the asset transfer processing platform, wherein the profile is associated with at least one event stream provided by the asset transfer processing platform, wherein the at least one event stream is associated with at least one asset type. The message may also include request data associated with a request, wherein the request is associated with the message and the profile. The method may also include determining the message type associated with the message and the profile registered on the asset transfer processing platform based on the received message. The method may also include identifying a message response protocol for the determined message type based on the determined message type. The method may also include identifying a permit data structure for the profile, wherein the permit data structure at least provides criteria for defining which users can interact with the profile using the determined message type. The method may also include processing the request data to determine the presence of an encrypted signature for signing the request data, and based on determining the presence of an encrypted signature for signing the request data, further processing the request data to extract data items from the request data. The method may also include applying the identified message response protocol to the extracted data items. The method may also include generating a response to the message based on the message response protocol, the extracted data items, and the license data structure by: using the license data structure to determine whether the user is allowed to interact with the profile using the identified message type; using the message response protocol to determine whether the extracted data items meet the requirements of the determined message type; and based on meeting the requirements of the determined message type, generating response content by interacting with the at least one event stream, the at least one event stream being associated with the profile.

[0104] According to the method of this another aspect, a method is provided by which a user can interact with an asset transfer platform. The interaction is determined by the permissions provided by a license data structure, and the license data structure provides cryptographic security for the interaction. This means that the license may allow certain interactions and may not allow certain interactions.

[0105] The method may also include providing the response content to the client device. The response content may be determined based on an entry from the event stream. The response content may include data recorded in the event stream. The data may be used in conjunction with an alphanumeric phrase. The response content may be a rejection of the message, and the rejection may be provided because the request data is not cryptographically signed; and / or the rejection may be provided if the message type identifier does not correspond to a message type; and / or the rejection may be provided if a profile registered on the asset transfer processing platform cannot be determined.

[0106] The method enables content to be retrieved from an event stream and provided to a client. This is based on the content being implemented with the cryptographic security provided by the license data structure.

[0107] The license data structure may include data identifying at least one of: an asset type associated with the profile; an asset manager identifier; permissions provided to the asset manager via the profile; permissions provided to the user associated with the profile.

[0108] The message response protocol may determine an operation to be applied to the event stream. The operation may be a write operation or a read operation.

[0109] The effect of this operation is that only certain operations are permitted on the event stream, and these operations are determined according to the message response protocol and the criteria it sets for the contents of the license data structure.

[0110] The identified message type may correspond to a retrieval request, further wherein the message response protocol is a retrieval request protocol, wherein applying the retrieval request protocol may include determining whether the client device is authorized to access the profile by determining whether a session license has been issued to the client device, wherein if a session license has been issued to the client device, the processing resource retrieves a current state from the event stream corresponding to the identified profile and provides a balance as part of the response provided to the client device; and further wherein if a session license has not yet been issued to the client device, the processing resource generates a rejection message and provides the rejection message to the client device.

[0111] That is, the method may enable a client to retrieve data from an event stream if a session license is available. A session license may be available that is valid only for a specified period of time. The holder of the license data structure may also revoke a session license.

[0112] The identified message type corresponds to an update request, which is used to request an update of at least one account associated with an asset type. Further, the message response protocol is an update request protocol, and applying the update request protocol includes: determining whether the update is a duplicate update based on the data items extracted from the request data by determining that corresponding instruction data exists in an event log previously attached to the event stream; further, if the update is a duplicate update, generating a response message to be provided to the client device, the response message indicating that the update is a duplicate update; and further, if the update is not a duplicate update, applying an update processing protocol to the request data to determine the validity of the update; if the update is valid, attaching the update to the event stream; if the update is invalid, generating a rejection message for the client device.

[0113] That is, if the update request has not been previously made, the method may enable the client to update the balance according to the contents implemented by the license data structure.

[0114] Generating the update request may include generating a blockchain transaction for synchronizing an event stream corresponding to the entity identified in the request data, wherein for each of the entities identified in the request data, the blockchain transaction includes a dust input and an unspent transaction output associated with the request, the dust input spending a dust output associated with a previous transaction and a corresponding unspent transaction output corresponding to the dust input; updating the event stream corresponding to the entity identified in the request data.

[0115] The identified message type may correspond to a setting request, the setting request being used to request a change in at least one field in the profile associated with the asset transfer processing platform, and wherein the message response protocol is a setting request protocol, wherein applying the setting request protocol comprises: extracting at least one identifier from the data item, the at least one identifier respectively identifying a profile setting to be modified; determining whether the user is allowed to make the modification based on the license data structure; and modifying at least one setting based on the license data structure.

[0116] That is, the method may allow the settings of a profile to be changed based on the license data structure.

[0117] The data item may include a timestamp identifying the time when the message was generated; and the processing resource may be configured to: accept the request if the timestamp indicates that the message was generated within a time period determined from the current time; and reject the request if the timestamp indicates that the message was generated outside the determined time period.

[0118] From another aspect, a computer-implemented method is provided for enabling a user to update a balance associated with an asset transfer processing platform. The method may be implemented by a processing resource. The method may include receiving a message from a client device associated with a user. The message may include an identifier associated with a balance update; at least one identifier associated with a profile registered on the asset transfer processing platform, wherein the profile is associated with at least one event stream provided by the asset transfer processing platform, wherein the at least one event stream is associated with at least one asset type; and request data associated with the update of the balance. The method may also include determining at least one profile identified in the message based on the received message. The profile may be a resource allocation of the processing resource, and may be an instance of the processing resource. The instance may be implemented by the cloud or by hardware or software. The method may also include identifying a license data structure, wherein the license data structure provides criteria for defining which users may update the balance. The license data structure may associate a cryptographic signature with a data item. The data item may be an alphanumeric sequence or a numeric sequence. The data item may be generated randomly, deterministically, or pseudo-randomly.

[0119] The method according to this other aspect provides a secure way in which an asset transfer platform can process a request to update a balance. The method utilizes a license data structure to provide cryptographic support to prevent users who do not have permission to update the balance from updating the balance.

[0120] The method may also include processing the request data to determine the presence of a cryptographic signature for signing the request data, and based on determining the presence of a cryptographic signature for signing the request data, further processing the request data to extract data items from the request data to be used for the update of the balance. The method may also include applying an update request protocol to the extracted data items to determine whether the balance can be updated. The update of the balance may be due to a transaction based on instruction data provided by the client. The instruction data may be signed by a cryptographic signature that is verified based on a license data structure.

[0121] The method may also include generating a response to the message based on the update request protocol, the extracted data items, and the permissions data structure. This may be achieved by: using the permissions data structure to determine whether the user has the cryptographic permissions required to update the balance; using the update request protocol to determine whether the update can be made; and generating response content by updating the balance and interacting with the at least one event stream based on meeting the requirements of the determined message type, the at least one event stream being associated with the profile.

[0122] From another aspect, a computer-implemented method is provided that enables a user to access an asset transfer processing platform using a computing device. The user can access the asset transfer processing platform using an identifier. The asset transfer processing platform can be a payment processing resource. The asset transfer processing platform can be implemented by software or hardware. The access to the asset transfer processing platform can be through a data communication network or by another suitable method (e.g., through an API call), and the API call uses the identifier and parameters of the user to identify the required interaction. The method can be implemented by a processing resource. The processing resource can be software or hardware implemented. The processing resource can be cloud-implemented or distributed on multiple processors. The method may include initializing an application on the computing device, and the application may be configured to generate a message including the following: at least one identifier of a message type associated with the message; at least one identifier associated with a profile registered on the asset transfer processing platform, wherein the profile is associated with at least one event stream implemented by the asset transfer processing platform, wherein the at least one event stream is associated with at least one asset type; and request data associated with a request, the request being associated with the message and the profile. The method may include receiving input from a user, the input identifying: a message type of a message to be sent to the asset transfer processing platform; a profile registered on the asset transfer processing platform; request data, the request data including the content of the request to be made to the asset transfer processing platform. The method may also include applying a cryptographic signature to the request data to generate signed request data. The method may also include generating a message including: an identifier of the message type identified by the user; an identifier of the profile registered on the asset transfer processing platform; and the signed request data. The method may also include sending the message to the asset transfer processing platform.

[0123] According to the method of this other aspect, a method is provided in which a user can transmit a message to the asset transfer platform. The application enables the user to provide instruction data, and then signs the instruction data so that the instruction data can be used in conjunction with a license data structure, thereby enabling the user to interact with the asset transfer platform securely.

[0124] From another aspect, an asset transfer processing platform is provided, the asset transfer processing platform being configured to receive a message from a client device associated with a user, the message comprising: at least one identifier of a message type associated with the message; at least one identifier associated with a profile registered on the asset transfer processing platform, wherein the profile is associated with at least one event stream implemented by the asset transfer processing platform, wherein the at least one event stream is associated with at least one asset type; and request data associated with a request, wherein the request is associated with the message and the profile. The asset transfer processing platform may be configured to determine the message type associated with the message and the profile registered on the asset transfer processing platform based on the received message. The asset transfer processing platform may also be configured to identify a message response protocol for the determined message type based on the determined message type. The asset transfer processing platform may be configured to identify a license data structure for the profile, wherein the license data structure provides criteria defining which users may interact with the profile using the determined message type. The asset transfer processing platform may also be configured to process the request data to determine the presence of an encrypted signature for signing the request data, and based on determining the presence of an encrypted signature for signing the request data, further process the request data to extract data items from the request data to be used to determine a response using the identified message response protocol. The asset transfer processing platform may also be configured to apply the identified message response protocol to the extracted data items. The identified message response protocol may include a series of criteria for determining whether a response may be provided and what the response may be. The message response protocol may generate a response to the message based on the message response protocol, the extracted data items, and the permission data structure in the following manner: using the license data structure to determine whether the user has the cryptographic permissions required to interact with the profile using the identified message type; using the message response protocol to determine whether the extracted data items meet the requirements of the determined message type; and based on the requirements of the determined message type, generating response content by interacting with the at least one event stream, the at least one event stream being associated with the profile.

[0125] The method according to this other aspect provides a platform through which a user can interact with a stream of events, the stream of events being associated with an account. The interactions are determined by permissions provided by a license data structure, which provides cryptographic security for the interactions. This means that a license may allow certain interactions and may not allow certain interactions.

[0126] Viewed from another aspect, a computer-implemented method of appending entries to at least one event stream is provided. An event stream may include an append-only log supported by a blockchain, in which data recorded in blockchain transactions are added to a time-ordered log. That is, an event stream records data on the blockchain in chronological order (i.e., the order in which it appears on the blockchain). An event stream may be implemented using any suitable data structure. An event stream may include a series of entries stored in a sequence, wherein each entry in the sequence is referenced in the sequence by a monotonically increasing number. That is, the first entry in an event stream is entry 1, the second entry is entry 2, and so on. Utilizing the underlying blockchain means that it can be guaranteed that the individual entries in the event stream have not been modified since they were written, no entries have been inserted between previous consecutive entries, no entries have been deleted, and no entries have been reordered. It is also impossible for unauthorized parties to append events to the event stream.

[0127] The at least one event stream may belong to an asset account associated with a user registered on the asset transfer platform. The registration of the user may include generating a profile on the asset transfer platform. The profile may correspond to an instance of a processing resource (e.g., a payment processing resource). The method may be implemented by a processing resource. The processing resource may include a hardware-based resource or a software-based resource. The method may include receiving a request to attach an entry to the at least one event stream, the entry including instruction data and an identifier of the at least one event stream. The request may be received via a data communications network or an API call, the API call receiving the identifier of the at least one event stream as a parameter. The identifier of the at least one event stream may also identify an instance of a payment processing resource.

[0128] The method may include retrieving the identifier of the at least one event stream from the request. Based on the identifier, the method may also include accessing the at least one event stream and obtaining a log of previous entries associated with the identified at least one event stream. The log of previous entries may be limited by a number of entries or a predefined time period (i.e., seconds, minutes, hours, days, months, or years).

[0129] The method may comprise retrieving the instruction data from the request.The instruction data may comprise data items identifying: an account; parties associated with an account; a license data structure associated with the account; and an account manager.

[0130] The method may include generating a unique identifier for the instruction data. Generating the unique identifier may include retrieving the unique identifier from the instruction data. The unique identifier may be an encrypted signature for signing the instruction data. Generating the unique identifier may also include generating the unique identifier by applying a hash algorithm to the instruction data or another suitable technique.

[0131] Based on the generated unique identifier, the method may further include determining whether data identical to the instruction data exists in a log of the previous entry associated with the identified event stream. This may be achieved by using the generated unique identifier as a search keyword in the log of the previous entry.

[0132] Based on a result of the determining step, the method may further include appending an entry to the at least one event stream, the entry including the unique identifier of the instruction data; or rejecting the entry of the event stream as a duplicate entry.

[0133] The method according to this other aspect prevents duplicate entries from being placed in the event stream. This is important because duplicate entries may include the immutability of the event stream, which reduces trust in the integrity of the data recorded in the event stream. The unique identifier of the instruction data may include an encrypted signature for encrypting and signing the instruction data. The encrypted signature may be generated using ECDSA technology. The encrypted signature can be retrieved from a license data structure associated with an entity that is associated with the transaction.

[0134] The request may be to append the entry to a plurality of event streams, and the method may further include retrieving the identifier of each of the plurality of event streams from the request. The request may further include identifying each of the plurality of event streams and a corresponding log of a previous entry. The method may further include using the unique identifier as a search keyword to determine whether data identical to the instruction data has been previously added to any of the logs. Based on the result of the determining step, the method further includes appending the entry to each of the event streams using the unique identifier; or refusing to append the entry to the plurality of event streams.

[0135] The effect of this operation is that if the request identifies multiple event streams, the transaction cannot be processed even if the transaction has been recorded in one of those event streams.

[0136] The method may also include determining a condition of the at least one event stream based on the instruction data, the condition must be met before the entry is added to the at least one event stream, and determining whether the condition is met before adding the entry to the at least one event stream. The condition may be that the index of the event stream must be less than or equal to an integer defined in the instruction data and / or that the entry is added to the event stream within a predetermined time period.

[0137] The processing resource may be configured to maintain the log at a maximum size by deleting entries in the log that are older than a predefined maximum period of time.

[0138] Upon receiving a further request received substantially simultaneously with the request to add an entry to the at least one event stream, the further request comprising the same instruction data as the request to add an entry to the at least one event stream, the method comprising rejecting both requests. The effect of this operation is that the data integrity of the event stream is not affected by the situation where instruction data is sent twice at the same time, i.e., the presence of a duplication in an entry of the log is recognized before the processing.

[0139] The embodiments and aspects according to the embodiments may be combined together in part or in whole.

[0140] Specific embodiments are now described by way of illustration with reference to the drawings, wherein like reference numerals refer to like features.

[0141] Reference now Figure 1a A system 100 is described that enables recording of a transfer of assets between a first user and a second user of the system 100 .

[0142] The system 100 includes a first computing device 102 and a second computing device 104. The first computing device 102 and the second computing device 104 can be any computing resources. Each of the first computing device 102 and the second computing device 104 is configured to interact with a payment processing resource 106 through a corresponding first application programming interface (API) and a second application programming interface (API) 108.

[0143] The payment processing resource 106 is configured to use the event stream resource 110 to initialize and / or interact with an event stream provided for at least each of a first user named Alice (110a), a second user named Bob (110b), and a payment processing resource (110c). According to UK patent application No. 2102314.8 filed on February 18, 2021 in the name of nChain Holdings Limited, it should be understood that the payment processing resource 106 initializes and interacts with the event stream.

[0144] As will be described further below, the payment processing resource 106 may be configured to interact with an event stream resource 110 that provides a sequential log of transactions processed using the payment processing resource 106 .

[0145] Blockchain 112 includes at least one public proof-of-work blockchain, which is an append-only ledger of blocks (BSV1, BSV2, BSV3) composed of transactions.

[0146] Blockchain 112 includes the combination of Figure 1b Each node is configured as part of the blockchain according to the software, as described below. Figure 1c as described.

[0147] Figure 1b An example of node software 450 running on each blockchain node 126 of the network 132 in an example of a UTXO-based or output-based model is shown. It should be noted that another entity may run the node software 450 without being classified as a node 126 on the network 132, i.e., not performing the actions required of the node 126. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a collection of one or more blockchain-related functional modules 455. Each node 126 may run node software that includes, but is not limited to, all three of the following: a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 401 is typically configured to identify different fields of a transaction 152 and process such fields according to the node protocol. When a transaction 152i (Tx m-1 )’s output (e.g., UTXO) is an input transaction 152j (Tx j ), the protocol engine 451 identifies Tx j The unlocking script in and passes it to the script engine 452. The protocol engine 451 also j The pointer in the input to identify and retrieve Tx i .Txi may be published on blockchain 150, in which case the protocol engine may retrieve Tx from the copy of block 151 of blockchain 150 stored at node 126 i . Or, Tx i It can also be published on blockchain 150. In this case, protocol engine 451 can retrieve Tx from unpublished ordered transaction set 154 maintained by node 126. i Regardless of the method used, the script engine 451 will identify Tx i The locked script in the reference output is passed to the script engine 452.

[0148] Therefore, the script engine 452 has Tx i The locking script and the j The unlocking script corresponding to the input. For example, Figure 1b 4. Transactions labeled Tx0 and Tx1 are shown in FIG. 4, but the same can also be applied to any transaction pair. As previously described, the script engine 452 runs two scripts together, which will include placing data on and retrieving data from the stack 453 according to the stack-based scripting language (e.g., Script) used.

[0149] By running the scripts simultaneously, the script engine 452 determines whether the unlocking script satisfies one or more criteria defined in the locking script, i.e., whether the unlocking script unlocks the output including the locking script? The script engine 452 returns the result of the determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet one or more criteria specified in the corresponding locking script, the result "TRUE" is returned. Otherwise, the result "FALSE" is returned.

[0150] In the output-based model, a result of "TRUE" from the script engine 452 is one of the conditions for the validity of the transaction. Typically, one or more further protocol-level conditions evaluated by the protocol engine 451 must also be satisfied; for example, Tx j The total amount of digital assets specified in the inputs of tx does not exceed the total amount pointed to in its outputs, and tx i The pointed output of has not been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 and one or more protocol-level conditions, and only if they are all TRUE, the protocol engine verifies the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. j Under the condition that it is indeed effective, the decision engine 454 can choose to control the consensus module 455C and the propagation module 455P at the same time to execute its Tx jThis includes the consensus module 455C, adding Tx to the corresponding ordered transaction set 154 of the node. j , for incorporation into block 151; and propagation module 455P, Tx j Forwarded to another blockchain node 126 in the network 106. Optionally, in an embodiment, the application-level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may choose to publish a transaction only if the transaction is valid and sufficient transaction fees are reserved.

[0151] In addition, it should be noted that in this article, the terms "TRUE" and "FALSE" are not necessarily limited to returning results that are expressed only in the form of a single binary number (bit), although this is indeed a possible implementation. More generally, "TRUE" can refer to any state indicating a successful or positive result, while "FALSE" can refer to any state indicating an unsuccessful or non-positive result. For example, in an account-based model, a combination of implicit protocol-level verification of a signature and an additional positive output of a smart contract can be used to indicate that the result is "TRUE" (if both individual results are TRUE, the overall result is considered to be TRUE).

[0152] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein.The scope of the present disclosure is not limited by the described embodiments but only by the appended claims.

[0153] It should be understood that the above description can generally be applied to any blockchain.

[0154] In a preferred embodiment of the present invention, the blockchain node 126 performs at least all of the functions described in creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or part of these functions but not all of them. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing blocks (remember that these entities are not considered nodes of the preferred blockchain network 132).

[0155] In a non-preferred embodiment of the present invention, it is not excluded that a node can perform at least one or part of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150, but not all of the functions. For example, on these other blockchain networks, "node" can be used to refer to a network entity that is configured to create and publish blocks 151 but does not store and / or propagate these blocks 151 to other nodes.

[0156] Even more generally, any reference above to the term "blockchain node" 126 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles in creating, publishing, propagating, and storing blocks. The functionality of such a network entity / element may be implemented in hardware in the same manner as described above with reference to the blockchain node 126.

[0157] Figure 1c An exemplary system 100 for implementing a blockchain 150 is shown. The system 100 may include a packet-switched network 130, typically a wide area network such as the Internet. The packet-switched network 130 includes a plurality of blockchain nodes 126, which may be arranged to form a peer-to-peer (P2P) network 132 within the packet-switched network 130. Although not shown, the blockchain nodes 126 may be arranged as a nearly complete graph. Thus, each blockchain node 126 is highly connected to other blockchain nodes 126.

[0158] Each blockchain node 126 includes a computer device of a peer, and different nodes 126 belong to different peers. Each blockchain node 126 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, special processors and / or field programmable gate arrays (FPGAs), and other devices, such as application-specific integrated circuits (ASICs). Each node also includes a memory, that is, a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memories (EEPROMs), and / or optical media such as optical disk drives.

[0159] The blockchain 150 includes a series of data blocks 151, wherein a respective copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 126 in the distributed or blockchain network 130. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned as long as each blockchain node 150 stores a block header (discussed below) for each block 151. Each block 151 in the blockchain includes one or more transactions 152, wherein a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a particular transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount of a digital asset represented as a property, an example of which is an output to a user 103 to which the output is cryptographically locked (requiring the user's signature or other solution to unlock, thereby redeeming or spending). Each input points to the output of a previous transaction 152, thereby linking these transactions.

[0160] Each block 151 also includes a block pointer 155, which points to the previously created block 151 in the blockchain to define the order of the blocks 151. Each transaction 152 (except for Coinbase transactions) includes a pointer to the previous transaction to define the order of the transaction sequence (Note: the sequence of transactions 152 can be branched). The blockchain of blocks 151 is traced back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 earlier in the blockchain 150 point to the genesis block 153, not to the previous transaction.

[0161] Each blockchain node 126 is configured to forward transactions 152 to other blockchain nodes 126, so that transactions 152 propagate throughout the network 132. Each blockchain node 126 is configured to create blocks 151 and store corresponding copies of the same blockchain 150 in its corresponding memory. Each blockchain node 126 also maintains an ordered set 154 of transactions 152 waiting to be incorporated into the block 151. The ordered set 154 is generally referred to as a "mempool". In this article, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of ordered transactions that the node 126 has accepted as valid, and for which the node 126 is forced to not accept any other transaction that attempts to spend the same output.

[0162] In a given current transaction 152j, an input (or each input) includes a pointer that references an output of a previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152j. In general, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although the previous transaction 152i will need to exist and be verified to be valid in order to ensure that the current transaction is valid, the previous transaction 152i does not have to exist when the current transaction 152j is created or even sent to the network 132. Therefore, in this article, "previous" refers to the predecessor in the logical sequence linked by the pointer, and not necessarily the creation time or sending time in the time sequence, and therefore, does not necessarily exclude the situation where transactions 152i, 152j are created or sent out of order (see the discussion of orphan transactions below). The previous transaction 152i can also be called a predecessor transaction or a predecessor transaction.

[0163] The inputs of the current transaction 152j also include input authorizations, such as the signature of the user 103a to whom the outputs of the previous transaction 152i are locked. In turn, the outputs of the current transaction 152j may be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j may transfer the amounts defined in the inputs of the previous transaction 152i to the new user or entity 103b defined in the outputs of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amounts among multiple users or entities (one of which may be the original user or entity 103a for changes). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and reallocate them to one or more outputs of the current transaction.

[0164] According to the output-based transaction protocol, when an entity 103 such as a user or a machine wishes to execute a new transaction 152j, the entity sends the new transaction from its computer terminal to a recipient. The entity or recipient will ultimately send the transaction to one or more blockchain nodes 126 of the network 132 (now typically a server or data center, but in principle it can also be other user terminals). It is also not excluded that the entity 103 executing the new transaction 152j may send the transaction to one or more blockchain nodes 126, and in some examples, the transaction may not be sent to the recipient. The blockchain node 126 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each blockchain node 126. The blockchain node protocol typically requires the blockchain node 126 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of the entity 103 included in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i assigned by the new transaction, wherein the condition typically includes at least checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, this may be determined solely by the blockchain node protocol, or may be determined by a combination thereof. In either case, if the new transaction 152j is valid, the blockchain node 126 forwards it to one or more other blockchain nodes 126 in the blockchain network 132. These other blockchain nodes 126 apply the same test according to the same blockchain node protocol, and therefore forward the new transaction 152j to one or more other nodes 126, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 126.

[0165] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated is whether it is validly redeemed by the input of another subsequent transaction 152j according to the blockchain node protocol. Another condition for the transaction to be valid is that the output of the previous transaction 152i that it attempts to allocate or redeem has not been allocated / redeemed by another transaction. Similarly, if invalid, the transaction 152j will not be propagated (unless marked as invalid and propagated for reminder) or recorded in the blockchain 150. This prevents double spending, that is, the transaction processor allocates the output of the same transaction more than once. On the other hand, the account-based model prevents double spending by maintaining account balances. Because there is also a defined transaction order, the account balance has a single defined state at all times.

[0166] In addition to verifying that transactions are valid, blockchain nodes 126 compete to be the first node to create a block of transactions in a process generally referred to as mining, which is supported by "proof of work". At blockchain node 126, new transactions are added to the ordered set 154 of valid transactions that do not yet appear in block 151 recorded on blockchain 150. Blockchain nodes then compete to assemble a new valid transaction block 151 of transactions 152 in the ordered transaction set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is juxtaposed with a representation of the ordered transaction set 154 and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash value has a certain predefined number of leading zeros. It should be noted that this is only one specific type of proof of work puzzle, and other types are not excluded. The property of a hash function is that it has an unpredictable output relative to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 126 that attempts to solve the puzzle.

[0167] The first blockchain node 126 that solves the puzzle announces the puzzle solution on the network 132, providing the solution as proof, which can then be easily checked by other blockchain nodes 126 in the network (once a solution to the hash value is given, it is directly possible to check whether the solution satisfies the output of the hash value). The first blockchain node 126 propagates a block to other nodes that reach the consensus threshold, and these other nodes accept the block and thus execute the protocol rules. The ordered set of transactions 154 is then recorded by each blockchain node 126 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n pointing to the previously created block 151n-1 in the blockchain. The large amount of work required to create a proof-of-work solution (e.g., in the form of a hash) signals the first node 126's intention to follow the blockchain protocol. These rules include not accepting a transaction as a valid transaction if it allocates the same output as a previously verified valid transaction, otherwise it is called a double spend. Once created, the block 151 cannot be modified because it is identified and maintained at each blockchain node 126 in the blockchain network 132. The block pointers 155 also impose order on the blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 126 in the network 132, an immutable public ledger of transactions is provided.

[0168] It should be noted that the different blockchain nodes 126 competing to solve a puzzle at any given time may do so based on different snapshots of the set of ordered transactions 154 that have not yet been published at any given time, depending on when they began searching for a solution or the order in which they received the transactions. The person solving the corresponding puzzle first defines the transactions 152 included in the new block 151n and their order, and updates the current set of unpublished transactions 154. The blockchain nodes 126 then continue to compete to create blocks from the newly defined set of pending ordered unpublished transactions 154, and so on. In addition, there is a protocol to resolve any "forks" that may occur, where two blockchain nodes 126 solve puzzles within a short time of each other, thereby propagating conflicting views of the blockchain between the nodes 126. In short, the fork direction that is the longest becomes the final blockchain 150. It should be noted that this does not affect users or agents of the network, as the same transaction will appear in both forks.

[0169] According to most blockchains, a node that successfully builds a new block 126 is granted the ability to distribute the amount of digital assets accepted in a new special type of transaction that distributes a limited amount of digital assets (as opposed to an inter-agent or inter-user transaction, which transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is often called a "Coinbase transaction", but may also be called an "initiation transaction". It usually forms the first transaction of a new block 151n. The proof of work signals the intention of the node that built the new block to follow the protocol rules, thereby allowing the particular transaction to be redeemed later. The blockchain protocol rules may require a maturation period, such as 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-generated) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 126 that created the block 151n in which the transaction was published. This fee is often called a "transaction fee" and is discussed below.

[0170] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 126 takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 126 may take the form of a user terminal or a group of user terminals networked together.

[0171] The memory of each blockchain node 126 stores software configured to run on the processing device of the blockchain node 126 to perform its corresponding role according to the blockchain node protocol and process transactions 152. It should be understood that any action attributed to the blockchain node 126 herein can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in one or more applications at the application layer or a lower layer such as an operating system layer or a protocol layer, or any combination of these layers.

[0172] The computer devices of each of the multiple parties 103 playing the role of consuming users are also connected to the network 130. These users can interact with the blockchain network but do not participate in verifying, building, or propagating transactions and blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without acting as senders or receivers. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., a copy of the blockchain that has been obtained from the blockchain node 126).

[0173] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on the blockchain network 132. Users of the blockchain network (often referred to as "clients") may be referred to as being part of a system that includes the blockchain network; however, these users are not blockchain nodes 126 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may interact with the blockchain network 132, thereby utilizing the blockchain 150 by connecting to (i.e., communicating with) the blockchain node 132. For illustrative purposes, two parties 103 and their corresponding devices are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. The first computing device 102 and the second computing device 104 may be configured to implement any functionality of the corresponding computer device 102a or 102b. It should be understood that more such parties 103 and their corresponding computer devices may exist and participate in the system 100, but for convenience, they are not illustrated. Each party 103 may be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document can be replaced with "first party" and "second party" respectively.

[0174] The computer device of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, GPUs, other accelerator processors, dedicated processors and / or FPGAs. The computer device of each party 103 also includes a memory, that is, a computer-readable memory in the form of a non-temporary computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memory or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer device of each party 103 stores software, which includes a corresponding instance of at least one client application 105 that is set to run on the processing device. It should be understood that any action attributed to a given party 103 in this article can be performed by software running on the processing device of the corresponding computer device. The computer device of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0175] The client application 105 may initially be provided to the computer device of any given party 103 via a suitable computer-readable storage medium (e.g., downloaded from a server), or via a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable disk drive, floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive. The client application 105 corresponds to Figure 1c 105a and 105b on devices 102a and 102b shown in FIG.

[0176] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more blockchain nodes 126, which are then propagated in the network of blockchain nodes 126 and included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant parties scattered throughout the blockchain 150.

[0177] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and rather, any client function described herein may be implemented in a suite consisting of two or more different applications, such as interfacing via an API or one application as a plug-in to another application. More generally, the client functions may be implemented at the application layer or at a lower layer such as an operating system, or any combination of these layers. The following description will be based on the client application 105, but it should be understood that this is not limiting.

[0178] An instance of the client application or software 105 on each computer device is operably coupled to at least one of the blockchain nodes 126 of the network 132. This can enable the wallet function of the client 105 to send transactions 152 to the network 132. The client 105 can also contact the blockchain node 126 to query the blockchain 150 for any transactions for which the corresponding party 103 is a recipient (or indeed to check the transactions of other parties in the blockchain 150, because in an embodiment, the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet function on each computer device is configured to formulate and send transactions 152 according to the transaction protocol. As described above, each blockchain node 126 runs software that is configured to verify that the transactions 152 are valid and forward the transactions 152 according to the blockchain node protocol so that these transactions are propagated throughout the blockchain network 132. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 126 in the network 132 use the same node protocol.

[0179] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in the blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using the wallet function in her client application 105). She will then send the transaction 152 from the client application 105 to one or more blockchain nodes 126 to which she is connected. For example, this may be the blockchain node 126 that Alice's computer is best connected to. When any given blockchain node 126 receives the new transaction 152j, it will process it according to the blockchain node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets certain conditions for becoming "valid", specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions may be configurable on a per-transaction basis through a script included in the transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by a combination of scripts and node protocols.

[0180] If the newly received transaction 152j passes the validity test (i.e., under the "verified valid" condition), any blockchain node 126 that receives the transaction 152j will add the new verified valid transaction 152 to the ordered transaction set 154 maintained at the blockchain node 126. Further, any blockchain node 126 that receives the transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 126 in the network 132. Since each blockchain node 126 applies the same protocol, the transaction 152j is assumed to be valid, which means that the transaction will soon be propagated throughout the network 132.

[0181] Once in the ordered set of transactions 154 maintained at a given blockchain node 126, that blockchain node 126 will begin racing to solve the proof-of-work puzzle on the latest version of its respective ordered set of transactions 154, which includes the new transaction 152 (remember that other blockchain nodes 126 can attempt to solve the puzzle based on different ordered sets of transactions 154. However, whoever solves the puzzle first will define the ordered set of transactions included in the latest block 151. Ultimately, the blockchain node 126 will solve the puzzle for a portion of the ordered set 154, which includes Alice's transaction 152j). Once the ordered set 154 including the new transaction 152j completes the proof-of-work, it will immutably become part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also immutably recorded.

[0182] Different blockchain nodes 126 may initially receive different instances of a given transaction, and therefore have conflicting views about which instance is “valid” before one instance is published in a new block 151, at which point all blockchain nodes 126 agree that the published instance is the only valid instance. If a blockchain node 126 accepts one instance as valid, and then discovers that a second instance has been recorded in the blockchain 150, the blockchain node 126 must accept this and will discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance that has not yet been published in block 151).

[0183] Another type of transaction protocol operated by some blockchain networks as part of the account-based transaction model can be called an "account-based" protocol. In the account-based case, each transaction is defined not by reference to the UTXO of the previous transaction in the past sequence of transactions, but by reference to the absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes of the network and is continuously updated. In such systems, transactions are ordered using the account's running transaction record (also called the "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, optional data fields can also be signed in the transaction. For example, if the data field contains the ID of the previous transaction, the data field can point to the previous transaction.

[0184] Transactions recorded in blockchain 112 simulate value transfers that are either spent or unspent and protected by locking scripts. Transactions spend value through their inputs and pay value through their outputs. The value of a transaction's inputs must equal or exceed the value of the previous transaction's outputs, and any remaining inputs are charged as transaction fees. A transaction is invalid if: the solution provided to the locking script (i.e., unlocking script) is incorrect; if the value of the transaction output is greater than the value used as input; if the transaction spends an output that has already been spent, or if the transaction attempts to spend value that does not exist at all.

[0185] Both locking and unlocking scripts are expressed in a machine-readable scripting language, allowing for a variety of script spending conditions, including scripts that can embed arbitrary data (in the form of provably unspendable outputs) as data-carrying outputs.

[0186] Figure 1a The payment processing resource 106 in can be configured to interact with the blockchain 112. This can be done when generating a blockchain transaction, where it can retrieve unspent outputs to use as the basis for inputs to other blockchain transactions. When generating a blockchain transaction, the payment processing resource 106 can record the generation of the blockchain transaction as an event in a corresponding event stream implemented by the event stream manager 110. More details of the functionality of the event stream can be found in GB2002285.1 filed on behalf of nChain Holdings Limited, GB2020279.2 filed on behalf of nChain Holdings Limited, and PCT / IB2021 / 051261 filed on behalf of nChain Holdings Limited.

[0187] Figure 1aThe payment processing resource 106 in is configured to interact with a key storage module 122 and a payment data storage 124. The key storage module 122 is configured to store keys corresponding to the accounts of the parties using the payment processing resource 106 to enable transactions. The key storage module 122 can utilize any suitable storage device and will utilize a database management system (DBMS) to initialize, store, and retrieve data from records within a database of the parties that store encryption keys in the key storage module 122. The payment data storage 124 is configured to store data related to any payment implemented using the payment processing resource 106.

[0188] The interaction between the respective computing devices and the payment processing resource 106 may be determined based on the license data structure generated by the payment processing resource 106 .

[0189] The concept of a license data structure related to a license associated with a user of the payment processing resource 106 is now described. The license provides a way to identify a user and describe the operations that the user can perform. The identification aspect is performed through the use of public key cryptography, while aspects related to the authorization of the user are managed through the use of permissions.

[0190] A license provides a way to identify a user and describe what operations the license holder is able to perform. The identification aspect is done by using public key cryptography, while the "operations the holder can perform" are done by using the license described in this article.

[0191] In one embodiment, each license has an associated license data instance (which is also described as associated license data or license data). The license data instance includes data about the license itself and the permissions that specify the operations that the holder of the license can perform. Optionally, each license includes at least one permission, and more optionally includes multiple permissions. Permissions are configured to determine the operations that the holder of the license can perform. Optionally, permissions are defined by name value (also called key value) pairs. Optionally, the name is a string of characters. More optionally, the string of characters is human-readable and provides an indication of the relevant content of the permission. Optionally, the value is a string, a number, or a data structure, wherein the data structure is one or more name value pairs. Optionally, permissions take the form discussed in further detail below under the heading "permissions". Optionally, when a license including one or more permissions used herein is referenced, this reference includes a license data instance of the name value permission. Optionally, permissions are provided in the form of a set or group (referred to as permissionSet in the example described herein). Optionally, permission groups are part of each license as an "extension".

[0192] Each license also includes data so that the identity of the holder of the license can be verified. Optionally, the license includes a public key associated with the holder of the license. Verification of the identity of the license holder can be determined by the holder signing a message (or any data) using its private key, and then the party verifying the identity of the license holder can compare the signature and message to the public key associated with the license holder. Optionally, the public key associated with the license holder is stored in the associated license data instance.

[0193] Optionally, each license is identified by a license identifier. Optionally, the license identifier does not provide an indication as to the content of the license. Optionally, the license identifier is a pseudo-randomly generated string.

[0194] In one embodiment, the system provides a method for verifying a user's signature against his or her license, thereby verifying that the user is or is not the holder of the license.

[0195] Optionally, a license is part of a hierarchy. Figure 1d , shows the hierarchy of licenses 200. All licenses (except root 202) will have a parent license, and optionally one or more child licenses. Optionally, a child license cannot have multiple parents. The resulting license hierarchy is a tree. A parent license can create child licenses.

[0196] Optionally, the license includes a set of rules that allow the licensee to create sublicenses that include permissions within a given "domain" or "namespace", but not across other domains or namespaces. Using these namespaces prevents different organizations from interfering with other organizations using the license system. This set of rules can be found in the "Special Permissions" discussion below.

[0197] Additionally, the set of rules allows delegation of authority to sublicenses, giving sublicenses the right to create grandchildren within a domain or namespace, and recursively down, subject to optional depth and total number limits.

[0198] The top-level root license 202 is capable of creating a large or even unlimited number of sub-licenses, with virtually no restrictions. Optionally, with such extensive capabilities, the private key / public key pair used to create the root license can be securely managed. Optionally, the private key associated with the root license is stored offline in a secure device.

[0199] The creation of the top-level root license 202 (rather than the organizational root licenses 206, 208, 210) is a one-time process. The method is similar to creating a child license, except that there is no parent license to reference, so all checks related to checking the permissions, authentication, authorization and other functions of the parent license are skipped or otherwise ignored. Optionally, in this embodiment, it is run only once and not again.

[0200] exist Figure 1d In the exemplary license hierarchy 200 of FIG. 1 , there are four different organizations using licenses. nChain(TM) is the holder of the root license, and the licenses used by Org ABC, Org PQR, and Org XYZ are all children of the nChain license. It should be understood by those skilled in the art that the specific companies are used only as examples. Furthermore, there may be any number of organizations in such a license system. Figure 1d The exemplary hierarchy and organization shown in exemplifies the flexibility of license construction when using the various disclosed embodiments described herein.

[0201] Continuing with the example, Org ABC has an organization-level root license 206. This is a root license because it is the root of Org ABC's licenses, not the top-level root of the entire tree 202. Org ABC has created at least two sub-licenses 212, 214. These sub-licenses are for different customers and / or end users.

[0202] Org XYZ has a root license 210. Org XYZ has chosen to have a different hierarchical structure with licenses for each country. The XYZ UK license 216 is shown with at least two licenses 218, 220 for members and / or end users.

[0203] In one embodiment, the holder of the root license creates multiple sublicenses 204 of the same holder. These sublicenses are configured so that they can create other child licenses 206, 208, 210 for other users of the system. In this way, each time a new user or organization requires a license, further license creation does not need to be performed using the top-level root license 202, thereby reducing the opportunity for attacks and increasing the security of the root license.

[0204] Optionally, each license contains a reference to its parent license and one or more named permissions. When created, a parent license provides data indicating the set of permissions and the public key associated with the license holder (holderPubKey). As can be seen in the example license data instance below, by default, permissions are stored under the extensions["default"] object.

[0205] Optionally, the license information is tracked in a data structure called a license data instance or license data. The data structure includes at least some of the following elements listed in the following table. Optionally, all of these elements are required. Some values ​​of these elements can be set to empty, zero, or zero length. More optionally, the parent license is required, but not empty.

[0206] Optionally, each license has a defined validity period. Optionally, the validity period of the license is from the current time to an end time and date; more optionally, wherein the end time and date is set under the "revoked" element in the license data instance. Once revoked, a license may not be reactivated.

[0207] Optionally, determining whether a license has been revoked depends on the current time. Each license includes a "revoked" element, which includes a time. For a license to be considered revoked, the current time must be after the revocation time stored in the license. More optionally, and in accordance with another embodiment, a method is provided in which a license is provided at a time in the future, and whether the license is valid at that time is returned.

[0208] Optionally, a map of named permissions is referenced by its name in the extension map. The name "default" is used when storing the initial extension.

[0209] Alternatively, no extension mapping is used, and only one permission set is associated with the license.

[0210] An exemplary license data instance is shown below in JSON format, where all elements are used (although some of them are set to empty).

[0211]

[0212]

[0213] It will be appreciated by those skilled in the art that the above is an exemplary license, and that some features of the license data instance may be deleted, not used, or modified according to the specific embodiments described herein. It will be further appreciated by those skilled in the art that the JSON provided here is used as an example of representing a license. The license and its contents may be represented using other formats, such as XML, binary encoding format, or any other appropriate format.

[0214] refer to Figure 1e , a simple example is shown (where the final top-level root license is omitted). Here, an organization's root license 302 has at least two child licenses 304, 306. The organization is NBW (National Bureau of Waterways), which issues fishing licenses 304, 306 (restricted to anglers in this example). Optionally, NBW provides a mobile application that holds an identifier of the holder's license and a secret key that allows the holder of the license to verify that they hold that license. Each angler's license 304, 306 includes rights called "org.nbw.angler.rights" and optionally has the following structure:

[0215]

[0216] Optionally, there are other permissions associated with an individual's identity, such as a membership number and user name.

[0217] In use, a fishing inspector who wishes to confirm that a user (e.g., Fred Bass, who holds the first sublicense 304) is fishing with the right type of equipment and catching the right type of fish can use the license to perform these actions. The inspector can use the license identifier (optionally obtained from Fred Bass's phone via a QR code). Using the license identifier, the inspector can query the license instance itself to verify authority (so that Fred Bass is using a fishing rod and catching only carp, channel fish, or pike) and identity (so that Fred is actually the holder of the license and he has not copied someone else's license identifier).

[0218] Permissions

[0219] Optionally, the permissions are namespaced. More optionally, the permissions are namespaced by restricting the names of the name value pairs. These namespaces use a reverse DNS domain-like structure separated by "." (periods). Some exemplary namespaces include:

[0220] com.example.user.id

[0221] com.example.user.type

[0222] com.example.acme.user.id

[0223] org.nbw.angler

[0224] As can be seen, these namespaces are built from left to right, where the leftmost prefix is ​​the least specific feature and the rightmost suffix is ​​the most specific feature.

[0225] Optionally, both the names and values ​​of the name-value pairs of these permissions are customizable (as long as the names are within the allowed namespace of the parent license). Optionally, both the names and values ​​can be any arbitrary value. Optionally, both the names and values ​​are provided by the user of the license system. Thus, the names and values ​​are user-generated. By providing user-generated and / or customizable names and values, the use case of the license can be very flexible, allowing it to be used in a large number of different applications.

[0226] Optionally, namespaces can only get longer. This also means that the permissions of a child license can only be a subset of the permissions allowed by the parent permissions. Optionally, namespaces allow permissions to be structured into a hierarchy (this is additional and separate from the licenses, although they usually match, but licenses are also hierarchical).

[0227] Optionally, the permissions hierarchy follows the same structure as a license. Furthermore, it should be understood that each sublicense includes the permissions that are a subset (by namespace) of the parent.

[0228] Special permission sets prefixed with a "$" namespace provide information and / or restrictions about the license itself. The "$" namespace provides restrictions on the permissions these licenses can add to sublicenses. These restrictions can include:

[0229] Enforce one or more namespace prefixes on all permissions in descendants;

[0230] Grants the right to create additional licenses to children, recursively up to a given depth;

[0231] Limit the number of children and descendants that can be created; and / or

[0232] Limit the number of extensions that can be created (discussed below under the "Extensions" heading).

[0233] Alternatively, the information stored in these special permissions (i.e., the restrictions and other information of the license) is not stored in the special permissions, but is stored in the license data instance. Optionally, each of these restrictions is stored as its own element in the license data instance. It should be understood by those skilled in the art that these restrictions can be stored in any number of different locations associated with the license.

[0234] Optionally, the "$" namespace is also used to define the validity period of the license.

[0235] Table 1 - Example Special ($) Permissions

[0236]

[0237] Special ($) namespaces are not required to follow the "$.children.namespace" rules above. Optionally, only a specific set of special permissions can be created. More optionally, the above set is the only special permissions a license can have.

[0238] Optionally, the $.valid.after and $.valid.before permissions use local time. Optionally, these permissions are optional, and are not required. Optionally, $.valid.after and $.valid.before define the validity period of a license and / or extension. Optionally, if a parent sets either of the $.valid.after and $.valid.before permissions, any child license created from it must be delivered within the same or a narrower time window. Thus, it can be seen that the validity period of a child license cannot exceed the validity period of its parent license.

[0239] Optionally, these special permissions are only stored in the initial / default extension, since these special permissions refer to the entire license. Any special permissions stored in a different extension are ignored or denied.

[0240] refer to Figure 1e As in the previous example, the NBW root license 302 includes at least the following permissions:

[0241] $.children.namespace="org.nbw"

[0242] $.children.levels=1

[0243] These permissions state that the holder of the NBW root license 302 can create as many sub-licenses as desired, as long as the permissions of the sub-licenses begin with "org.nbw" and the sub-licenses are only one level deep.

[0244] refer to Figure 1f , another exemplary license structure 320 is shown here. This structure is similar to reference Figure 1e The structure described. The NBW root license 302 has the "$.children.levels" permission equal to 2 (or more). In this example, the NBW license 302 holder wants to allow clubs to create licenses for their own members. The NBW license 302 creates a club license BLFC 322 (Big Lake Fishing Club) that includes the following permissions:

[0245] org.nbw.club.id="BLFC"

[0246] $.children.namespace="org.nbw.angler"

[0247] $.children.levels=1

[0248] $.children.max=50

[0249] These permissions allow the BLFC to create up to 50 licenses for its members, but are limited to permissions within the namespace "org.nbw.angler". Therefore, no sublicense is allowed to use permissions such as "org.nbw.club.id", so a sublicense cannot impersonate the permissions of a club license (for example, if a sublicense includes the permission "org.nbw.club.id", the sublicense can pretend to be the club and take any actions associated with the club) or any other similar permissions.

[0250] The BLFC license 322 creates at least two sublicenses 324, 326. These sublicenses must have permissions prefixed with "org.nbw.angler".

[0251] Extensions

[0252] Optionally, permissions are stored in "extensions". Optionally, an extension consists of: a permission set (called permissionSet), a revoke element, and a holderPubKey element. Extensions are stored in license data instances in the extension map and referenced by name. Optionally, the name is user-generated. Optionally, the name is human-readable. Optionally, the initial extension and / or the default extension are marked as "default". Here, human-readable means any encoding such that it can be naturally read by humans. Optionally, the encoding is ASCII or Unicode text.

[0253] Optionally, the extension provides a way to reference a group of at least one permission. More optionally, the permission provides a human-readable way to reference a group or set of at least one permission.

[0254] Each extension includes multiple elements. Exemplary elements of the extension are provided in Table 2 below. Optionally, all of these elements are required.

[0255] Table 2 - Extension elements

[0256]

[0257] It will be appreciated by those skilled in the art that it is not necessary to strictly follow the structure and format of the extension and the storage mode of the extension. For the extension and / or set of permissions, there may be alternative structures. An exemplary alternative may be that the extension may not be strictly stored in the extension map, but may be stored in a list or other appropriate data structure. Alternatively, the extension objects described herein may also have different structures because they only include a permission list or a permission reference list, and the permissions themselves are stored elsewhere in the license.

[0258] Extensions can be used to add and replace permissions during the validity period of a license. Extensions can be added or revoked by a parent license. Optionally, all permissions added to a license are signed by the holder of the parent license.

[0259] In one embodiment, the extension enables the license holder to associate different devices with the license. For example, if the license is used to access a specific resource (optionally a computing resource), a single license holder may have an "iPhone" extension to manage the interaction of its iPhone with the computing resource and a "desktop" extension to manage the interaction of its desktop computer with the computing resource. As described above, the extension can be revoked. Advantageously, if the user loses their iPhone, they can contact their license provider (the provider has control over the parent license that created the user's license), and they can revoke the iPhone extension without affecting the interaction of the user's other devices with the service. Therefore, it can be seen that the extension system provides improved flexibility and control when providing / removing access to resources. Combined with the central control of the license and / or the lack of a certificate revocation list, computing resources can be saved when verifying the permissions within the relevant extension because such lists do not need to be distributed and maintained.

[0260] Interaction with Licenses

[0261] As mentioned above, optionally, the license system described herein interacts using requests. Optionally, these requests are HTTP requests. More optionally, these requests are sent to REST endpoints. There are two relevant REST endpoints:

[0262] … / send, for requesting actions on a license, including creating and revoking sublicenses; and

[0263] … / query, to check the validity and permissions of the license.

[0264] Optionally, several interactions will require the request to include a signature, so organizations wishing to interact with a license for creation, revocation, or other interactions will need to set up a private / public key pair. Any request will also need to include the instance id of the license of interest. The instance id and public key can be publicly viewable or known, but the private key must be kept secret.

[0265] Transmitting requests to these endpoints can also be described as "calling" them, since they are presented in the form of a RESTful API. Therefore, the sender of the request can also be considered the "caller".

[0266] Optionally, any request sent to the "… / send" endpoint is logged. Optionally, logging occurs on the blockchain, allowing third parties to audit the requests. Optionally, any request sent to the "… / query" endpoint is not logged.

[0267] In one embodiment, the interactions are recorded on the blockchain, or at least a subset of the interactions are recorded on the blockchain. Optionally, all of these interactions are recorded off-chain, and a subset of the interactions are recorded on the blockchain. Optionally, the interactions are recorded into multiple interaction sets, where each interaction set is associated with a single license. Each interaction set also has an associated representation on the blockchain (through the use of transactions). Thus, an auditor who wishes to track interactions with a license of interest can only audit the set of interest.

[0268] Optionally, each of the interactions recorded on the blockchain includes an immutable reference to the previous interaction (optionally also stored on the blockchain). Optionally, the reference is a hash of the previous interaction. Optionally, all interactions include a reference to the previous interaction, thereby building an immutable chain of all interactions. Thus, the immutable log only requires a subset of the interactions recorded on the blockchain. Optionally, only the first interaction and the last interaction are recorded on the blockchain.

[0269] Optionally, a per-license event stream is used for logging. Optionally, there is a logging service that interacts via an API to provide logging implementations. The event stream is as follows:

[0270] PCT / IB2021 / 051258 filed by nChain Holdings Limited on February 15, 2021;

[0271] PCT / IB2021 / 051260 filed by nChain Holdings Limited on February 15, 2021; and

[0272] PCT / IB2021 / 051333 filed on February 17, 2021 by nChain Holdings Limited.

[0273] Optionally, data indicating any interaction with the license is transferred to the event stream using an event stream API. Optionally, the event stream API is a RESTful API. The current state of the license can be verified by taking all of these interactions with the license (including its creation), and recreating a "dummy permit" by executing / playing back all the interaction steps again (this can also be described as a "dry run" because no new license is actually created). The final state of the "dummy license" should have the same current state as the real license. If any intermediate states of the license are known, verify that the intermediate states are also true.

[0274] Therefore, it can be seen that by recording the interaction with the license, the state of the license is recorded, so the current state or any previous state is auditable and verifiable. By submitting these state changes to the blockchain through an event stream, the license will become permanently auditable and verifiable with high data integrity confidence.

[0275] Some example requests to the endpoint might include the following features in the header:

[0276] POST https: / / {AWS ID}.amazonaws.com / api / v1 / processInstance / {instanceID} / send

[0277] or

[0278] POST https: / / {AWS ID}.amazonaws.com / api / v1 / processInstance / {instanceID} / query

[0279] Where {AWS ID} is the id of the AWS(TM) endpoint and {instance ID} is the license identifier. It will be appreciated by those skilled in the art that other URLs and services may be used. For example, a non-AWS URL may be used. It will be appreciated by those skilled in the art that the requests provided herein are exemplary and may take different forms. The request is shown to include the URL to which the request is sent. Optionally, the full URL is not provided in this manner, but only the path is provided.

[0280] Optionally, the request header also includes an AWS API key.

[0281] Optionally, the body of the POST should be a JSON object containing a single property naming the message or interaction being sent. Optionally, the request is authenticated and authorized by signing the parameters with the sender's private key and placing the result in the signature attribute of the request. For example:

[0282]

[0283] It should be noted that the part of the request being signed needs to be sent as a string representation of the request contents rather than the JSON object itself. This is to ensure that the sender of the request and the receiver of the request use the same object representation (regardless of spacing, order, etc.) to calculate the signature. In addition to stringification, a canonical structure of the object can also be used. Optionally, the canonical structure is defined according to RFC8785. The canonicalization scheme is a scheme that is mutually agreed upon by the sender and the receiver. The scheme may be agreed upon in advance, or the scheme is identified by the sender so that the receiver knows which scheme is being used.

[0284] Optionally, the response to the above request has a result property and an optional message. For example:

[0285]

[0286] The exact contents of the message (msg) will depend on the context of the request and how it is processed.

[0287] A number of different embodiments are given below describing different interactive licenses. Optionally, any number of these embodiments may be used with any number of different other embodiments. It will be appreciated by those skilled in the art that some embodiments may not be used in every conceivable system. For example, extensions may not be used, and therefore any interactions related to the creation or revocation of extensions may not be used.

[0288] Each license data structure may be stored in a license data store 180. The license data store 180 may be accessed from the payment processing resource 106 via a suitable API or other means. The license data structure is stored in the license data store 180 in any suitable manner so that the license identifier can be used to identify the license. For example, this enables access to other elements of the license data structure during checking of the cryptographic signature.

[0289] The payment processing resource 106 enables users to establish instances of the payment processing resource 106 that they can use to manage their accounts. Figure 2 Describe this. An instance of the payment processing resource 106 is used to manage activities around assets that are managed by accounts established on the payment processing resource 106 according to the procedures specified in GB2109064.2 filed on behalf of nChain Licensing AG on June 24, 2021.

[0290] A first computing device 102 associated with a user downloads application code that configures the first computing device to use the API 108 to generate application programming interface (API) calls that are received by the payment processing resource 106. The payment processing resource 106 provides the first computing device 102 with a payment processing resource identifier that the API can use to identify the payment processing resource 106. The identifier can be an alphanumeric sequence of characters or a purely numeric sequence of characters.

[0291] The first computing device 102 initiates the process of establishing an instance of the payment processing resource 106 by generating an API call to an endpoint of the API 108, the API call corresponding to a request for a new instance of the payment processing resource 106. This is step S200. The API call includes a payment processing resource identifier provided by the payment processing resource 106 to the first computing device 102.

[0292] The payment processing resource 106 can be associated with a stringified JavaScript Object Notation (JSON) object that can have elements corresponding to identifiers of assets managed by the corresponding account; an identifier of the account manager, an identifier of the account manager's license data structure, an identifier of the account holder's license data structure, an identifier of the account initiator (e.g., who can be a customer of a bank), an expression that enables checking the expression in the account holder's license and terms and conditions (including a uniform resource location that enables retrieval of the terms and conditions, a hash of the terms and conditions, and an encrypted signature of the account holder), configuration parameters (e.g., minimum and maximum balance settings), settings on how to control numbers, and spending limits for the corresponding funding account.

[0293] The permission data structure for the account manager and account holder may be constructed as described above, wherein various permissions are provided, which may be cryptographically verified by the payment processing resource 106 using the permission data structure.

[0294] The payment processing resource 106 responds by requesting data corresponding to the element used by the corresponding instance of the payment processing resource 106. This is step S202.

[0295] Then, the first computing device 102 provides corresponding elements used by the payment processing resource 106 to establish an instance of the payment processing resource 106 required for the corresponding user to interact with the payment processing resource 106. This is step S204.

[0296] When establishing an instance of the payment processing resource 106, the payment processing resource 106 effectively generates a profile for the user, which is identified by an instance identifier (which is generated and used as described below). This means that when the identifier is used to access the payment processing resource 106, the payment processing resource 106 can determine which files to access and can also determine the correct allocation of resources (i.e., memory, directories, and registers) to activities on the instance. The payment processing resource 106 can run, access, and utilize each instance separately.

[0297] In the case where the payment processing resource 106 is implemented by cloud-based resources, the instances of the payment processing resource 106 can be implemented using corresponding software running through the necessary hardware across the cloud infrastructure. This enables the payment processing resource 106 to appropriately allocate resources to any one instance.

[0298] Upon receiving the corresponding elements, the payment processing resource 106 processes the required elements and verifies the data provided to support the licenses of the account holder and the account manager. In this way, it obtains the public keys corresponding to the two licenses. It also obtains the identifiers of the two licenses and checks the validity of the expressions of the two licenses. This is step S206. This is achieved by referencing the license data structure corresponding to the corresponding license. The encrypted signature on the terms and conditions is also checked by referencing the license data structure of the account holder. This can be checked using the above method, where the terms and conditions and the encrypted signature are provided to the license data storage 180, and a request is made to verify the encrypted signature for the corresponding license data structure. Then, the encrypted signature is verified using known techniques, such as generating and verifying digital signatures based on the elliptic curve digital signature algorithm (ECDSA) or Rivest-Shamir-Adleman (RSA) method. If the signature provided in the request is successfully verified, the digital signature is considered valid. If it is not successfully verified, a rejection message can be issued.

[0299] The identifiers of the assets and account managers are then recorded in the instance data structure 170 generated for the instance. In addition, the identifiers corresponding to the licenses of the account holder and account manager are recorded in the instance data structure 170. This is step S208. The instance data structure 170 includes any suitable data structures required to provide access to the identifiers of the account holder and account manager. The payment processing resource 106 can access the instance data structure 170 using any suitable means (e.g., through an additional API or through a data communication network).

[0300] In addition, the balance of the corresponding funding account is set to zero, and other settings related to the representation of numbers, spending limits, and minimum and maximum balances are also set in the instance data structure 170. When the user receives a message for the account, an instance identifier is also generated to identify the instance to the payment processing resource 106. This is step S210. The instance identifier is then provided back to the first computing device 102, where it can be stored for further interaction with the payment processing resource 106. This is step S212. If other users need to interact with the corresponding instance of the payment processing resource 106, the instance identifier can also be used by them. Providing the instance identifier to the first computing device 102 completes the generation of an instance of the payment processing resource 106 corresponding to the funding account of the asset identified in the information provided in step S204. Providing the instance identifier to the first computing device 102 also triggers the generation of parameters required to allocate resources to the corresponding instance of the payment processing resource 106. Upon completion of the generation of the instance of the payment processing resource 106, the payment processing resource 106 interacts with the event stream manager 110 to initialize the event stream corresponding to the instance of the payment processing resource. This is step S214. The event stream will be used to record the complete history associated with the corresponding fund account. Only read operations or append operations can be performed on the event stream.

[0301] Initializing an event stream may include setting up and configuring the computing resources and data structures required to implement a particular event stream. Alternatively or additionally, completing the generation of an instance of the payment processing resource 106 may result in accessing a pre-existing event stream. Initializing a pre-existing event stream may also include additional entries to attach data confirming that an instance of the payment processing resource 106 has been established. A pre-existing event stream may be an event stream containing entries for all instances of the payment processing resource 106. A pre-existing event stream may also be an event stream that synchronizes each other event stream into a single event stream, which is also managed by the event stream manager 110. More detailed information on the functionality of an event stream can be found in GB2002285.1 filed on behalf of nChain Holdings Limited, GB2020279.2 filed on behalf of nChain Holdings Limited, and PCT / IB2021 / 051261 filed on behalf of nChain Holdings Limited.

[0302] Creating an instance of payment processing resource 106 and providing an instance identifier enables devices such as first computing device 102 to interact with the instance of payment processing resource 106. Devices other than first computing device 102 may also interact with the generated instance if the license data structure allows them to do so, as described below.

[0303] In a first example of interaction between a computing device and an instance of a payment processing resource 106, the following describes how the first computing device 102 can utilize the API 108 to initiate a session with the instance of the payment processing resource generated in steps S200 to S214. As will be described later, the session can then be used to implement other interactions with the instance.

[0304] Specifically, refer to Figure 3 Describes how the first computing device 102 obtains a session key to enable interaction with a funding account associated with an instance of the payment processing resource 106 .

[0305] In step S300, the first computing device 102 uses the API 108 to issue a call to request a session with the instance of the payment processing resource 106. This utilizes the session endpoint of the API 108. The API call requesting the session passes the instance identifier (associated with the corresponding instance of the payment processing resource 106) to the session endpoint to initialize the session with the instance of the payment processing resource 106. The API call also includes instruction data, which includes a timestamp confirming the time of the call. The instruction data may also include a time period during which the session can be utilized (and essentially a time period during which the corresponding session key will be used) and a flag confirming whether the instruction is from the account manager (set to FALSE if the instruction is from the account holder).

[0306] The instruction data may also include data including a license identifier that identifies a license data structure and a credential in the license data structure that may show authorization for the first computing device 102 to access the event stream. Verification of such credentials is discussed later in the context of how to verify data items. Such credentials may also be described as permissions in the license data structure. The instruction data may also include a public key corresponding to the license data structure.

[0307] That is, the payment processing resource 106 determines, based on the API call and the provided instance identifier, that the message from the first computing device 102 relates to a request to establish a session between the first computing device 102 and an instance of the payment processing resource 106 .

[0308] The instruction data also includes an encrypted signature from an account holder corresponding to a funding account associated with the identified instance of the payment processing resource 106. That is, the instruction data is cryptographically signed by the account holder, and the encrypted signature is included in the instruction data. The encrypted signature can be generated using an elliptic curve digital signature algorithm (ECDSA) technique using a private key associated with the license data structure of the account holder. Alternatively, the signature can be generated using RSA-based techniques.

[0309] In response to the API call, the payment processing resource 106 performs some initial checks to determine whether a session key can be generated or whether the request should be rejected immediately. This is step S302. That is, the payment processing resource 106 checks the timestamp to see if it is at most one minute away from the current time. If the timestamp is more than one minute away from the current time, the session request is rejected. If the timestamp is less than or equal to one minute away from the current time, the session request is accepted. This time period may be different from the time indicated by the timestamp. For applications with a higher security awareness, this time period may be much less than one minute, but for applications with a lower security awareness, this time period may be longer.

[0310] By checking the current time relative to the time indicated by the timestamp to determine how much time has passed since the request was made, the payment processing resource 106 can prevent replay attacks.

[0311] The payment processing resource 106 also checks the time period (also referred to as the session period) to determine the time when the session may be used. The time period is usually expressed in the form of seconds or minutes, but can also be expressed as a date range for the expected use of the session.

[0312] In step S304, the payment processing resource 106 issues a request to the license data store 180 to verify the cryptographic signature (included in the instruction data). This can be accomplished through a separate API or through a message transmitted to the license data store 180 via a telecommunications network. Alternatively, the license data store 180 may be local to the payment processing resource 108 because it occupies the same localized group of hardware resources. The request will include the instruction data provided in step S300 and the cryptographic signature used to sign the instruction data (i.e., the instruction data being verified). The request may also include a reference used by the specific instance of the payment processing resource 106 making the verification request, and may also include a string identifying the device that is the source of the request. For example, if the request is from Apple , then the string may be "iPhone". The string may be provided in the instruction data and extracted from the instruction data by the payment processing resource 106. The reference used by the particular instance may be the event stream index of the request made in step S300. This is advantageous because it helps to verify the state of the license data structure in conjunction with the state of the associated event stream (i.e., the event stream generated for the instance of the payment processing resource 106) when the request is made. That is, when a request is made to verify the cryptographic signature, this may help to verify whether the license data structure produces a correct response in its current state. The request also includes an instance identifier of the corresponding instance of the payment processing resource 106, and additionally includes a license identifier so that the license can be identified by the license data storage 180.

[0313] The license data storage 180 will then perform a check on the record corresponding to the license identified by the license identifier. This is step S306. If an encrypted signature is found in the license data structure corresponding to the license, the check will return a confirmation. This involves verifying the signature using standard ECDSA or RSA signature verification techniques. The generated signature is compared to the encrypted signature provided in the instruction data. This is step S308. If the encrypted signatures do not match, the check will return a rejection. This is step S310, and the request fails or is no longer processed. If the flag confirming whether the instruction is from the account manager is set to TRUE, the public key used to verify the signature is from the license data structure owned by the account manager.

[0314] If the check returns confirmation, that is, the signatures do match, the payment processing resource 106 compares the session period requested in step S300 with the maximum period set by the payment processing resource 106 for the session with the corresponding instance of the payment processing resource 106. This is step S312. If the session period is less than the maximum period set by the payment processing resource 106, the payment processing resource 106 will generate a session key (also referred to as a session token) for the requested session with the requested session period. This is step S314. The session key will be generated by the payment processing resource using any suitable technique. The session key can be generated using a public key corresponding to the license found in the license data structure. The session key can be generated using a hierarchical key generation technique, using the public / private key pair associated with the account holder's license as the base key. The session key can then be returned to the first computing device 102 along with a message that the session has been initialized. The session key can then be used together with the instruction data to request other requests to interact with the event stream. However, the session key can only be used within the session period that has been requested.

[0315] If the result returned by the comparison in step S312 indicates that the session period is greater than the maximum period or less than the minimum value also set by the instance of the payment processing resource for the session with the payment processing resource 106, the payment processing resource 106 will not generate a session key and the request will fail, i.e., will no longer be processed.

[0316] Alternatively or additionally, if the cryptographic signature is verified, but the requested session period is less than the minimum value set for a session with an instance of the payment processing resource 106 , the payment processing resource 106 may generate a session key and increase the allowed session period to the minimum value.

[0317] When the session key is generated, the payment processing resource 106 may retrieve the balance from local storage. Optionally, the payment processing resource 106 may also issue a query to the event stream manager 110 to obtain a sequential log of transactions from an event stream corresponding to a funding account associated with an instance of the payment processing resource identified by the instance identifier. The query may return a partial or complete version of the event stream, thereby providing an overview of the transaction history related to the funding account associated with the instance of the payment processing resource 106. A partial version may be returned if the query specifies a date range between which the event stream manager 110 will return all entries. The date range may be specified in the initial request made in step S300, or may be automatically generated by the payment processing resource 106. This is step S316.

[0318] The event stream manager 110 will generate a timestamp of the query and an index of the event stream. This is step S318. In response to the query, the event stream manager 110 may add an entry to the event stream.

[0319] Then, the balance (if acquired), the timestamp and index of the event stream are returned to the first computing device 102. This is step S320. Then, in step S320, the session key may also be transmitted to the first computing device 102.

[0320] The first computing device 102 may then use the session key to request read-only data from an event stream associated with the instance of the payment processing resource identified by the instance identifier provided in step S300. This does not require repeating the authentication process involved in generating the session key. That is, the session key may be provided in an API call from the first computing device 102 to the payment processing resource.

[0321] This may be part of a request to view the state of an account tracked via an event stream, or to get information about the history of said account. A request to get information about the history may request details of a transaction specified by a date range, index range, or even a hash of the corresponding transaction data. Requests may also be for the complete transaction history.

[0322] That is, the computing device can interact with an instance of the payment processing resource 106 using the instance identifier and then obtain read-only information from the associated event stream. Alternatively, the computing device can interact with the instance of the payment processing resource 106 to generate a session key, which can then be used to further interact with the event stream. When making a request, the license data structure is used to verify the license data structure corresponding to the provided cryptographic signature, and the request will only proceed if the cryptographic signature is verified. The use of the license data structure to verify the cryptographic signature and determine that the session period is neither too short nor too long serves as a protocol for determining the acceptability of a message, especially a request for obtaining read-only data related to an event stream, which is associated with an instance of the payment processing resource. The user of the first computing device 102 can access the read-only data only if the session can be authorized, and the session can only be authorized if the requirements of the protocol (i.e., the presence of the signature and the length of the session period) can be met. Authorizing the session includes providing a session key to the requesting user. The user can sign the instruction data using the session key, and the payment processing resource 106 can check the signature when the user requests access to the corresponding event stream. The payment processing resource 106 can determine that the above protocol is needed based on the API call received from the first computing device because it can provide a parameter identifying the type of request being made. Alternatively or additionally, if the first computing device 102 provides the request over a data communication network, the message can provide a parameter identifying a specific type of request.

[0323] Now, refer to Figure 4a , describes how the first computing device 102 may interact with an instance of the payment processing resource 106 during a transfer of funds from a funding account associated with one instance of the payment processing resource 106 to another instance of the payment processing resource 106. This results in the transfer being recorded in the associated event stream.

[0324] In step S400, the payment processing management module 195 generates instruction data regarding Alice's payment of 5 GBP to Bob. The instruction data is generated based on payment metadata received from Alice (possibly using the first computing device 102 or the second computing device 104), which payment metadata indicates the amount that Alice wishes to pay to Bob, the instance identifier of Alice's payment processing resource 106 (the instance corresponding to the funding account from which the payment to Bob is made), the currency that Alice wishes to pay (i.e., GBP), Bob's identifier, and the identifier of the instance of the payment processing resource 106 associated with Bob's funding account, which, for simplicity, is a GBP account managed by the same account manager as Alice. The generation of the instruction data includes a combination of the payment metadata received from Alice and information associated with Bob's funding account.

[0325] The payment processing management module 195 then uses the API 108 to make an API call to update Alice's balance, which can also be understood as a request to debit 5 GBP from Alice's funding account and deposit that amount into Bob's funding account. This is step S402. The API call receives instruction data generated by the payment processing management module 195 as part of the call. When making the API call, the first computing device enables the payment processing resource 106 to receive the instruction data generated in step S400. The API call also includes additional data (also received by the payment processing resource 106), which may include a transaction identifier (which may be generated in the same step based on a hash of the instruction data) and other information that may be used in the transaction (which may be referred to as one or more tags). When the transaction has been completed and information about the transaction is added to the event stream, the tags will be included in the event stream entry. For example, the tags may show "Debit 5 GBP from Alice" and / or "Pay 5 GBP to Bob". The API call also includes cryptographic signatures from Alice and Bob's accounts. The cryptographic signature may be generated using ECDSA (or RSA) techniques using the private keys corresponding to Alice and Bob's license data structures.

[0326] The transaction identifier uniquely identifies a funds transfer and may be formed using a secure hash algorithm (SHA) 256 hash of the instruction data. The tag may include information that will also be used in the event stream entry when the transaction is appended to the event stream. The tags may be formatted as an array of strings, where each string includes an alphanumeric string.

[0327] That is, the payment processing resource 106 can determine based on the API call and the identifier provided in the API call that Alice at the first computing device 102 wants to conduct a transaction with Bob, i.e., the transaction is to be processed.

[0328] In step S404, the data received in the API call is parsed to generate a JSON object containing instructions and cryptographic signatures corresponding to Alice's and Bob's accounts, respectively. These instructions will identify (from Alice's account) the account manager, the identification of the asset (i.e., GBP), the value being transferred (i.e., 5 GBP), the identifier of the funding account (which may be different from the instance identifier), an alphanumeric string containing a reference to the transaction (i.e., pay Bob), the time limit for the funds transfer, and the response data structure, which will be discussed further below. These instructions will also identify (from Alice's account) the terms and conditions that Alice agreed to when creating her funding account, the cryptographic signature of the terms and conditions that Alice agreed to, and the uniform resource locator of those terms and conditions.

[0329] The instructions will also identify (from Bob's account) the account manager, the identification of the asset (i.e., GBP), the value being received (i.e., 5 GBP), an identifier for Bob's funding account (which may be different from the corresponding instance identifier), an alphanumeric string containing a reference to the transaction (i.e., Alice's payment), the transaction's nonce, and a challenge data structure, which will also be discussed further below. The instructions will also identify (from Bob's account) the terms and conditions to which Bob agreed (when creating his funding account), and may also include a cryptographic signature of the terms and conditions to which Bob agreed and the uniform resource locator of those terms and conditions.

[0330] As the resource that coordinates the transfer of funds between Alice and Bob, the payment processing resource 106 can dynamically manage the transfer of funds as now described because it manages the credentials provided by both Alice and Bob and interacts with the license data structure and event stream. This does not require the storage of instruction data.

[0331] Optionally, these instructions may be stored by an instance of Alice's payment processing resource 106 as a pending transaction in a memory of the instance. The storage may be identified by a transaction identifier generated in step S402. These instructions may also be stored by an instance of Bob's payment processing resource 106 as a pending transaction in a memory allocated to the instance.

[0332] Parsing the data received in the API call also retrieves the instance identifier of the instance of the payment processing resource associated with Alice's funding account. The instance identifier is then used in step S406 to retrieve instruction data associated with Alice's funding account. These instructions constitute constraints on the funding account and restrictions on transactions that can be completed using the funding account.

[0333] The instruction data associated with Alice's funding account may include an identifier of an account manager, an identifier of the asset being transferred (i.e., GBP), a maximum value that can be transferred, an instance identifier of an instance of a payment processing resource associated with Alice's funding account, a sequence number of the transaction being processed, a random number for the transaction being processed, a field corresponding to a time period in which the transaction can be completed (i.e., a minimum date and time and a maximum date and time), a reference to the transaction, a tracking identifier for the transaction, an alphanumeric string indicating the action to be taken (i.e., debit 5 GBP), an identifier of a party (i.e., the account holder), and a tag.

[0334] The instruction data associated with Alice's funding account may also include a response data structure, the purpose of which will now be described.

[0335] That is, Alice's fund account is represented as a JSON object that requires input corresponding to each of the fields, and the input is provided by the parsed data.

[0336] The parsed data is then processed so that the payment processing resource 106 can process the payment using the response data structure and the challenge data structure. The parsed data is then passed to the payment protocol module 120 to process the requested payment. The payment processing resource 106 may be able to determine that the payment protocol module 120 is required and the payment processing protocol is required based on the parameters provided in the initial API call. Alternatively, the specific protocol may be identified in the instruction data. Alternatively, the specific protocol may be identified by a parameter in the request transmitted over the data communication network.

[0337] The payment protocol module 120 applies the payment processing protocol to the parsed data to determine whether Alice is authorized to make payment and whether payment can be made regardless of the authorization from Alice's license data structure. This is step S408.

[0338] The first step in applying the payment processing protocol is to determine whether the instruction is properly authorized. This is achieved by determining whether the instruction comes from the account holder or the account manager. In this example, the instruction comes from Alice, so it is the account holder who provides authorization. This can be verified using the instance data structure 170, in which the instance identifier corresponding to the instance of Alice's payment processing resource 106 is stored. Then, the payment processing protocol determines the validity of Alice's signature. This is performed using Alice's license data structure. The payment protocol module 120 sends a request to the license data storage 180 to check the validity of Alice's signature. This is step S410. The request uses the license identifier provided by Alice in the instruction data to identify the license. The license identifier can also be obtained from the license storage maintained by the payment processing resource 106. The request receives the instruction data, a string including Alice's signature, a reference to the current event stream index of the event stream associated with Alice's fund account, and the name of the device Alice uses to provide the instruction data (this can be included in the payment metadata used to generate the instruction data and passed when the instruction data is generated).

[0339] Upon receiving the request, the license data store 180 identifies the license corresponding to the license identifier and determines whether the signature provided by Alice corresponds to the encrypted signature associated with Alice's license data structure. This is step S412. This check returns an answer of YES or NO.

[0340] If the answer NO is returned, the process fails and a message is provided to Alice indicating that the transaction cannot proceed. If the answer YES is returned, the payment protocol module 120 may move to the next step of the payment processing protocol.

[0341] The payment processing module 120 then issues a request for Bob's instance identifier (ie, an identifier for identifying the instance of Bob's payment processing resource 106) from the instance data structure 170. This is step S414. This is to check whether the transaction counterparty (ie, Bob) is authentic.

[0342] If the instance data structure 170 cannot provide Bob's instance identifier, a rejection message is returned. This is step S416. This results in a rejection being issued to Alice, indicating that her transaction cannot proceed because the transaction counterparty account identified in the instruction data is invalid. The process fails and the request is no longer processed.

[0343] If the instance data structure 170 can provide Bob's instance identifier, the payment processing module 120 proceeds to the next step of the payment processing protocol.

[0344] Then, in step S418, the third instance of the payment processing module 120 (the instance responsible for successfully processing the transaction) confirms that the instructions provided by Alice and Bob are complementary. That is, the payment processing resource confirms that the instruction data corresponding to the two parties of the transaction are complementary, one party pays the other party, or in other words, one party sends funds and the other party receives funds. This is step S420.

[0345] In response to a negative determination, i.e., the instructions from Bob's side do not correspond, Bob's instance of payment processing resource 106 provides a rejection message. Payment processing resource 106 then converts the rejection message into a rejection transaction and transmits it to Alice. The process then fails and the request is no longer processed.

[0346] If Bob's instance of payment processing resource 106 is providing replenishment instructions, the payment processing module 120 moves to the next step of the payment processing protocol, where the transaction data is processed to determine whether the minimum and maximum balance thresholds have not been breached. This is step S422. At this stage, a check may be made to see if the accounts of both parties have been frozen.

[0347] If it is determined that any of the thresholds have been breached and / or the account has been frozen, the payment processing resource 106 issues a rejection to Alice indicating that the transaction cannot be completed. This is step S424.

[0348] If it is determined that the threshold has not been breached and / or there is no freeze command, the payment processing module 120 moves to the next step of the payment processing protocol 120 where it is determined whether the zero-sum requirement for the transaction is met. This is step S426.

[0349] To determine whether the zero-sum requirement is met, the value elements in Alice's and Bob's instruction data are checked. In this example, Alice pays Bob 5GBP, so the value on Alice's side should be -5GBP (which is indeed the case) and the value on Bob's side should be 5GBP (which is indeed the case). This is because 5GBP is debited from Alice's account and 5GBP is credited from Bob's account. This means that the zero-sum requirement is met. If the value field on Bob's side reads 4.90, 0.10 will not be accounted for and the zero-sum requirement will not be met. Since the zero-sum requirement has been met, the payment processing module 120 can proceed to the next step. If the zero-sum requirement is not met, the transaction is rejected and the process returns to step S400.

[0350] If the zero-sum requirement is met, the payment processing module 120 may then choose to determine whether the correct tags are provided in the instruction data for the particular job being performed. That is, whether the tags in the instruction data from Alice show "Debit 5GBP and credit 5GBP from Bob." This is step S428. If the account manager signed the instruction data, the tags will be processed to determine whether other tags are present. For example, if the account manager is a bank and the transaction involves currency exchange, appropriate tags should be included. These tags are included in the instruction data and are typically included in the data that is appended to the event stream to record the transaction. Therefore, it is critical to ensure their accuracy.

[0351] The payment processing module 120 may also make a request to Bob's instance of the payment processing resource 106 to determine whether Bob's instance is breaching a minimum or maximum balance threshold. This is step S430. If Bob is the party paying Alice, the maximum payment threshold will also be checked.

[0352] Continuing with the steps applied by the payment processing module 120, the payment processing protocol is applied to the instruction data (ie, request) provided by Alice. The remaining step in determining whether the transaction can be completed is to determine whether Alice has the necessary credentials to pay Bob from her payment account based on the license data structure.

[0353] We will now describe how to use the challenge data structure and the response data structure to verify Alice's credentials to claim that she can make this payment from the referenced funds account. Figure 5a and Figure 5b to achieve.

[0354] The challenge data structure is provided by Bob and provided by Bob's instance to request Alice to prove that she is allowed to conduct transactions. Upon receiving instruction data about payment from Alice to Bob, the instance of Bob's payment processing resource 106 generates a challenge data structure. The challenge data structure includes an identifier of the challenge data structure. The identifier of the challenge data structure can be an alphanumeric sequence or a numeric sequence. The identifier of the challenge data structure can be generated randomly or pseudo-randomly. The challenge data structure also includes a random number for the data item to be verified. The random number of the data item will be used in combination with the random number provided in the response data structure, and when the data item is verified, this will form the basis of the encrypted signature provided by the instance of Alice's payment processing resource 106 (as described below). The challenge data structure also includes the data item being verified. The data item may have a reverse DNS domain class structure (i.e., com.example.user.id). The data item can be an alphanumeric sequence of characters with a namespace. Alternatively, the data item can be any alphanumeric sequence of characters. It can be an expression that can be understood by humans or a randomly generated set of characters. The data item represents that Alice claims that she can pay. That is, this data item represents the credentials that Alice asserted when instructing payment processing resource 106 to process payment to Bob. This data item may be an expression as described above with respect to the license data structure.

[0355] The response data structure is provided by Alice in an instruction associated with her instance of the payment processing resource 106. When receiving an instruction to pay Bob, the response data structure can be generated by Alice's instance of the payment processing resource 106. The response data structure includes an identifier of the response data structure. The identifier can be an alphanumeric sequence or a numeric sequence. The identifier of the challenge data structure can be randomly or pseudo-randomly generated. The response data structure also includes a random number. The response data structure also includes an identifier of a corresponding license data structure owned by Alice. The response data structure can also include an identifier that identifies the device used by Alice.

[0356] The response data structure also includes an encrypted signature of the concatenation of the random number provided in the response data structure and the SHA256 hash of the random number provided in the challenge data structure. The encrypted signature can be generated based on the private key corresponding to the public key possessed by Alice (i.e., the public key corresponding to the license data structure identified in the response data structure). The encrypted signature can also be generated using a paired private key (with the public key) found in a digital wallet associated with Alice. The steps for generating the response data structure are now described.

[0357] In step S500, the payment processing resource 106 retrieves the challenge data structure provided by Bob. In step S502, the payment processing resource 106 uses the identifier of the challenge data structure to search for the response data structure. The identifier of the response data structure should match the identifier of the challenge data structure.

[0358] In this example, the response data structure is provided by Alice as part of her instruction data in step S400, and is a response data structure that satisfies the requirements associated with the challenge data structure to prove ownership of the license data structure (as now set forth). It will be described later how the payment processing resource 106 will proceed if the response data structure is not initially provided and a request is required. That is, the payment processing resource 106 finds the response data structure with the corresponding identifier in the content that Alice has provided. This may occur when the responder (i.e., Alice) already knows which license data structure the challenger (i.e., Bob) will seek to support verification of Alice's payment authority. That is, the responder already knows which data item Bob will seek to verify from her license data structure, and can generate the random number and signature accordingly based on the corresponding license data structure in the license data storage 180. When Alice provides the instruction data, the random number in the response data structure will be generated in step S400. The random number in the challenge data structure will be generated when the corresponding parties reach an agreement on Alice's payment to Bob. The payment processing management module 195 may then generate an encrypted signature of the concatenation of the random numbers, which is then provided in the response data structure included in the instruction data provided by Alice. The concatenation may include the random number from the response data structure, followed by the random number from the challenge data structure.

[0359] Then, in step S504, the payment processing resource 106 extracts the encrypted signature of the concatenation of the random numbers from the response data structure. In step S506, the signature is verified using known signature verification techniques (e.g., PKI). The payment processing resource 106 then proceeds to step S508, in which the payment processing resource verifies the encrypted signature of the concatenation of the first random number and the second random number. If the verification indicates that the signature is invalid, the payment processing resource 106 provides a failed transaction message to Alice and Bob, including a message that Alice was unable to conduct the transaction. This is step S510.

[0360] The instruction data associated with Alice and Bob may not provide corresponding response data structures and challenge data structures; or, as described in step S510, the corresponding response data structures and challenge data structures do not enable verification of Alice's authorization to pay 5 GBP to Bob. Figure 5bDescribes how an instance of Bob's payment processing resource 106 can check whether Alice can make a payment if the response data structure provided in the instruction data does not provide a valid signature or is not provided at all.

[0361] In step S512, Bob's instance of the payment processing resource 106 will generate a challenge data structure (if the challenge data structure has not already been generated or provided in the instruction data set).

[0362] The challenge data structure will contain the data item to be verified in order to process the transaction of paying 5 GBP to Bob (from Alice). The data item may be an alphanumeric sequence, with a content similar to "uk.co.Alice-Bank-Account". Alternatively or additionally, the data item may be a purely numeric sequence, such as "31415192". The challenge data structure also contains a random number. The random number may be randomly generated based on the data item, or may be randomly generated independently of the data item. In addition, an identifier is assigned to the challenge data structure.

[0363] Then, in step S514, the challenge data structure is provided to an instance of Alice's payment processing resource 106. The instance of Alice's payment processing resource 106 is then configured to determine, based on the pending instruction data set, whether a response data structure has been provided (for this example, it has not been provided), and then, if no response data structure has been provided, to issue a query to the license data storage 180 (using the identifier of Alice's license data structure) to obtain a corresponding license data structure (i.e., owned by Alice) that contains the alphanumeric sequence "uk.co.Alice-Bank-Account" and is valid at the time the request is made. This verification step is performed in step S516. In summary, the verification step aims to determine whether the expression "uk.co.Alice-Bank-Account" is associated with a corresponding license data structure, i.e., whether the expression is present in the permissions associated with Alice's license data structure.

[0364] That is, the license data store 180 is queried to determine whether the instance of Alice's payment processing resource 106 is cryptographically associated with a license data structure containing the alphanumeric sequence "uk.co.Alice-Bank-Account" and whether the corresponding license data structure is still valid.

[0365] The presence of a valid license data structure containing the alphanumeric sequence "uk.co.Alice-Bank-Account" ensures that Alice has passed the specified KYC process (performed by her account manager) and is allowed by the account manager to conduct the transaction.

[0366] The query issued in step S516 takes the alphanumeric sequence as a parameter. Optionally, other parameters may also be received, as the query may also carry the following: a flag for the type of alphanumeric sequence provided; an index into the event stream associated with Alice's instance of the payment processing resource (in order to verify the index of the last entry in the event stream associated with the instance of the payment processing resource when the query (issued in step S516) is made); an extension indicating the name of the device that Alice uses (or used in the past) to provide instructions to the payment processing resource 106.

[0367] If the license data store does return a license data structure owned by Alice (i.e., a license data structure that can be identified by the identifier of Alice's license data structure), and the permissions associated with Alice's license data structure (i.e., permissionSet) contain the alphanumeric sequence "uk.co.Alice-Bank-Account", then in step S518, the payment processing resource 106 will generate a response data structure that contains the identifier of the challenge data structure, the random number provided in the challenge data structure, the identifier of the license owned by Alice and containing the alphanumeric sequence, an extension indicating the name of the device used by Alice, and an encrypted signature of the concatenation of the random number provided in the challenge data structure and another copy of the random number provided in the challenge data structure. The encrypted signature can be generated by Alice using her private key (i.e., the private key corresponding to the public key identified in the license data structure). The encrypted signature can also be generated using a private key associated with Alice found in a digital wallet associated with Alice. Since Alice's payment authorization has been verified, the transaction can proceed. This is step S520. The payment processing resource 106 then moves to the next step of the transaction, as described below with respect to generating a rendezvous blockchain transaction.

[0368] If the license data store does not return a license data structure that Alice owns and that contains the alphanumeric sequence "uk.co.Alice-Bank-Account", the payment processing resource 106 proceeds to reject the transaction. This is step S522.

[0369] If multiple alphanumeric sequences are provided in the challenge data structure, steps S512 to S522 may be repeated until the license data store returns a license data structure owned by Alice that contains one of the provided alphanumeric sequences (from the challenge data structure).

[0370] Alternatively or additionally, if a response data structure is provided in the instruction data set provided by Alice, then for each provided alphanumeric sequence from the challenge data structure, the payment processing resource 106 may check whether the signature is correct and whether the corresponding license exists.

[0371] That is, for each alphanumeric sequence from the challenge data structure, the payment processing resource 106 forms a concatenation of the corresponding random numbers from the response data structure and the challenge data structure. The payment processing resource 106 then queries the license data store for the license data structure by providing the concatenation and the encrypted signature from the response data structure provided by Alice. The payment processing resource also provides the license identifier from the response data structure to identify the license in which the corresponding signature should be found. When making a query, the query may also provide a parameter containing an index to the event stream associated with Alice's instance of the payment processing resource 106. The query may also contain an indicator of the device that Alice was using when the transaction was processed.

[0372] To verify the cryptographic signature, a signature is constructed using the public key stored in the retrieved license data structure to check if it returns the same signature on the provided random number combination. If so, the cryptographic signature provided in the response data structure is considered valid. If not, the response data structure is rejected as not providing authorization to conduct the transaction.

[0373] In response to determining that the cryptographic signature is valid, the payment processing resource provides a request for the corresponding alphanumeric sequence corresponding to the cryptographic signature to be verified. This includes providing a request for the corresponding alphanumeric sequence to be verified to the license data store. This includes providing a license identifier (of the identified license) to the license data store and requesting the return of a license data structure identified by the license identifier, and checking whether the corresponding alphanumeric sequence is found in the identified license data structure when the license data structure is returned. If the corresponding alphanumeric sequence is found in the identified license structure, Alice's payment authorization is accepted. If the corresponding alphanumeric sequence is not found in the identified license structure, Alice's payment authorization is rejected. The payment processing resource 106 can then proceed with the transaction and generate a rendezvous blockchain transaction, which will reference Figure 6 Give a description.

[0374] A rendezvous transaction is a blockchain transaction that can include multiple dust chain input / output pairs and outputs marked with the OP_RETURN opcode to make the output unspendable and allow the addition of a data carrier. The OP_RETURN opcode causes the execution of the corresponding redemption script to end immediately and make it invalid, i.e. the output cannot be redeemed. This means that the output cannot be spent and the data carrier remains on the blockchain as part of the rendezvous transaction. Dust chain input / output pairs can have the same index in the transaction and can input funds and change outputs separately. The data carrier can be the final output. The multiple dust chain inputs that make up the rendezvous transaction can come from different corresponding event streams.

[0375] In step S600, the payment processing resource 106 then issues a request to the event stream management resource 110 to establish a rendezvous blockchain transaction based on the respective event streams associated with each of Alice and Bob (and HSBC as their account manager). This will refer to Figure 7 That is, for Alice, the event stream management resource 110 is requested to access the current state of Alice's account (similar to Bob's event stream). Figure 8 and Fig. 9 Describe the dust chain and its relationship to the event stream.

[0376] The blockchain transaction 702 retrieved for Alice includes a dust output (Tx0, Alice), and the blockchain transaction 704 retrieved for Bob includes a dust output (Tx0, Bob).

[0377] The payment processing resource 106 then generates a new rendezvous blockchain transaction 406 that includes dust inputs for each of Alice and Bob that spend corresponding dust outputs from the blockchain transaction retrieved in step S600. This is step S602. The dust outputs may be retrieved from the dust chain corresponding to the event stream associated with Alice and Bob. Figure 7 This is also shown in . The transaction chain between 702 and 704 to 706 can be described as a dust transaction chain, and there will be one dust transaction chain for each of Alice and Bob, corresponding to their respective event streams. In the context of blockchain transactions of the present disclosure, "dust" is understood to be a spendable transaction of a digital asset whose output has a low or minimal value, i.e., the value can be much less than the cost of mining the output in the blockchain. That is, the new rendezvous transaction synchronizes the event streams on behalf of Alice and Bob by generating a transaction that will support entries attached to both event streams.

[0378] Alternatively, the payment processing resource 106 may generate a new dust transaction using a combination of dust that does not form part of a pre-existing event stream and a hierarchical deterministic (HD) keychain, as described in UK patent application number 2102217.3. In other words, a dust transaction is generated that uses dust as an input and includes inputs corresponding to each of Alice and Bob, where the dust has not been previously used in an event stream. A party in possession of the HD keychain may use one of the subkeys and the dust to generate the first transaction in the new event stream. In short, a new event stream may be initiated based on dust that may be retrieved from an existing transaction on the blockchain 112 and used as the basis for the start of a new event stream. That is, the dust may be used to generate a transaction (in order to start a new event stream) and then returned to the platform before being used to initiate another event stream.

[0379] Now refer to Figure 8 Further clarify the relationship between the dust transaction chain and the event stream.

[0380] Figure 8 The basic data structure and paradigm of an ordered append-only data storage system is shown. This can also be described as a data logging system. Figure 8 The specific system shown is an event stream system for recording events. For example, the event stream is used throughout for illustrative purposes, however, those skilled in the art will appreciate that the proposed systems and aspects described herein can generally be used with data records, and can also be used with ordered append-only data item records or storage systems. A data record refers to a hash of the actual data. The hash can be a hash of the instruction data of a transaction being recorded in an event stream corresponding to an instance of a payment processing resource 106 associated with each party. Using a hash instead of the data itself advantageously provides proof of existence for the data without the need to store the data (which may be large or even too large for the transaction) on the transaction. This also protects the privacy of the data because even if the hash is published on the chain, the data cannot be distinguished from the hash. The data described here is payment instruction data related to the payment being recorded by the payment processing resource 106.

[0381] Each event 502 in the append-only log is mapped to a blockchain transaction 504, and the sequence of blockchain transactions is ordered and linked using a "dust chain" 506. The data associated with each event is stored in the payload (described below) as part of each transaction. The data payload (i.e., a hash of the payment instruction metadata) is saved in the unspendable OP_RETURN output of the transaction, an example of such a transaction is the rendezvous transaction 706 described above. This is a script opcode that can be used to write arbitrary data on the blockchain or mark the transaction output as invalid. As another example, OP_RETURN is a scripting language opcode used to create an unspendable output of a transaction, which can store data such as metadata in the transaction, thereby recording the metadata immutably in the blockchain.

[0382] A chain of dust (or dust chain) is an unbroken chain of inputs and outputs that are used to impose a spending dependency on each blockchain transaction in a sequence on its immediate predecessor.

[0383] The use of dust outputs in transactions is advantageous and essential for maintaining an immutable sequential record of all transactions as they occur in an ordered, append-only data storage system such as an event stream. This is because, although by publishing transactions to the blockchain, all blockchain transactions will be timestamped and, once confirmed or added to the blockchain, will be preserved in order in the blockchain, this does not guarantee that their order remains unchanged. This is because transactions may be mined into blocks at different times, and / or transactions may even be in the same block in different orders. The use of dust outputs spent by the first input of the next transaction in the sequence advantageously ensures that the order of transactions is tracked in chronological order, and creates a tamper-proof record of both the events themselves and the sequential ordering of events. This is because, once mined into a block, the dust payments from the previous transaction to the next transaction in the sequence ensure that: according to some blockchain protocol rules, the sequence of embedded data carrier elements called payloads cannot be reordered, and no insertions or deletions can occur that could change the sequence without it being immediately obvious that the event stream has been broken. In some embodiments, double-spend protection mechanisms ensure that the movement of dust between different transaction inputs and outputs maintains chronological order. The chaining of dust transactions utilizes topological sorting to preserve the order of transactions (and related events and data) across and within blocks. This therefore improves the integrity of ordered append-only data item storage.

[0384] In this manner, blockchain transactions 504 form a directed graph of transactions. It should be noted that the direction of the graph can be considered unidirectional, i.e., pointing from the previous transaction in the sequence to the next transaction, as shown by edge 806. Although Figure 8The arrow on edge 506 in indicates pointing to the next transaction, but the cost relationship in the transaction is actually from one transaction to the previous transaction. The graph is created by the cost relationship between transactions. These cost relationships can be considered as a reference type. More details on how to attach events to event streams can be found in the UK patent application with application number 2102314.8, specifically but not completely, which mentions "ordered, append-only data storage", "event streams and dust chains" and "backward references in dust chains".

[0385] Converging blockchain transactions (e.g. Figure 7 Transaction 706 shown in is a blockchain transaction for synchronizing multiple event streams, each associated with a given entity / user as described above. This is achieved by spending multiple dust outputs as corresponding inputs. In this example, this allows the dust chains (i.e., dust input / output pairs) corresponding to each of Alice and Bob to pass through a single transaction. The dust chain input / output pairs must have corresponding input / output indexes in the transaction. In this case, dust chain input / output pairs are used (described below) to enable payments to be recorded in all event streams associated with the transaction.

[0386] The dust input that spends Alice's dust output is denoted as Tx1,Alice, and the dust input that spends Bob's dust output is denoted as Tx1,Bob. A new rendezvous blockchain transaction 706 is generated in step S602.

[0387] The funds in the rendezvous blockchain transaction 706 are added by the payment processing resource 106 and will be returned to the payment processing resource 106. The rendezvous blockchain transaction 706 may be sent to the blockchain 112 for verification.

[0388] The rendezvous blockchain transaction 706 includes other dust outputs that spend Tx1, Alice and Tx1, Bob, respectively. Since it is a rendezvous transaction, the indexes of the input / output pairs corresponding to Alice and Bob, respectively, are the same, for example, the input index of Tx1, Alice can be assigned as number 1, and the output index of the corresponding dust output can be assigned as output index number 1.

[0389] The payment processing resource 106 also adds provably unspendable outputs to the blockchain transaction 706 for each of Alice and Bob in the form of data carriers 712a and 712b.

[0390] Each of these data carriers can store a different data digest and / or a different stream digest, wherein the stream digest can also be salted.

[0391] The data payload (i.e., the hash of the payment instruction metadata) saved within the corresponding data carrier is saved in the unspendable OP_RETURN output of the transaction, which means that the data payload can subsequently be stored as an unspendable output in the blockchain.

[0392] The data within the data carrier 712 includes a hash of the instruction data generated by the payment processing resource 195. This hash is generated in step S334. The provably unspendable output enables the rendezvous transaction 706 to carry the hash of the payment instruction data set in the transaction, and enables the hash to be stored on the blockchain. This means that the payment instruction data set is stored on the blockchain as well as the payment record. This means that the payment record benefits from the immutability of the blockchain.

[0393] The blockchain transaction 706 can then be checked to see if the correspondence of the user to the transaction is correct and corresponds to the users (ie, Alice and Bob). This is step S604.

[0394] The payment processing resource 106 issues a notification to the event stream resource 110 confirming that the blockchain transaction 706 generated in step S602 can be used as a basis for appending data to the event stream (i.e., the event stream regarding Alice and Bob).

[0395] An event stream is an append-only log supported by the blockchain. In this example, Alice and Bob each have their own event stream, but if they do not, an event stream can be initialized. That is, Alice has an event stream (E-Alice) and Bob has an event stream (E-Bob). An entry in an event stream can be represented as ESn, where n can be a non-zero positive integer or a non-negative integer.

[0396] like Figure 8 As shown, an event stream can be shown as a series of entries, where any entry in the stream can be referenced by a monotonically increasing sequence number, i.e., the first entry can be referred to as ES1 and the second entry can be referred to as ES2.

[0397] The payment processing resource 106 is only appended to the corresponding event stream if Alice and Bob are authorized to access or append to the event stream. For example, authorization can be checked by comparing the cryptographic signature used to sign the instruction data with the signature stored at the payment processing resource 106. By appending the payment data to the event stream, the payment can be recorded and benefit from being recorded in an immutable log associated with the blockchain 112. In short, the event stream is used to track the transaction sequence of the accounts associated with Alice and Bob. That is, the entries in the event stream are an immutable log associated with the blockchain 112. The above event stream ensures that:

[0398] ● Each entry in the event stream has not been modified since it was written;

[0399] ● No entry was inserted between previous consecutive entries;

[0400] ●No entries were deleted;

[0401] ●No items were reordered;

[0402] ● Unauthorized parties may not append events to the stream.

[0403] The payment processing resource 106 uses the rendezvous transaction 706 to synchronize the payment with the event streams E-Alice and E-Bob by appending an entry to each of these event streams containing a hash of the payment instruction metadata contained in the data carrier in the blockchain transaction 706. This is step S608. Fig. 9 This is schematically shown in . The account manager (eg HSBC) may also have an event stream E-HSBC which also has a hash of the instruction data appended to it.

[0404] The payment processing resource 706 then generates an identifier for the entry added to each of these event streams. This is step S610. The identifier can be an alphanumeric identifier or a number generated based on a hash of the instruction data. For example, if the hash of the instruction data is generated by a SHA256 cipher, the identifier can be generated by applying another SHA256 cipher to the hash of the instruction data. That is, the identifier can be a hash of a hash of the instruction data.

[0405] The payment processing resource 106 then stores the identifier along with a copy of the instruction data in the payment data store 124. This enables the payment between Alice and Bob to be verified upon request. The payment processing resource 106 also stores the cryptographic signature used to sign the instruction data along with the identifier.

[0406] The payment processing resource 106 also maintains a log of all instruction data sets stored in the event stream associated with the payment data store 124 associated with each instance of the payment processing resource 106. This can be used to prevent duplicate transactions from being appended to the event stream.

[0407] That is, the payment from Alice to Bob is processed after transmitting the message to the payment processing resource 106, which then uses the permit data structure and the payment processing protocol to determine whether the payment can be made and what the response should be, i.e., whether the transaction should proceed.

[0408] Reference now Fig.10 Describes how to adjust the settings of an instance of the payment processing resource 106.

[0409] To change the settings corresponding to the instance of the payment processing resource 106, the first computing device 102 provides a call to the API 108, which identifies the instance identifier of the corresponding instance of the payment processing resource 106 to which the settings adjustment is related. This is step S1000. Based on the API call and the instance identifier, the payment processing resource 106 can determine that a request to change the settings is being made and that the adjusted settings protocol needs to be applied.

[0410] The request also includes an instruction data set that includes a timestamp corresponding to the time the request was provided via API 108, an extension identifying the specific computing device corresponding to first computing device 102, a requested adjustment to the maximum balance (if an adjustment is being made), a requested adjustment to the minimum balance (if an adjustment is being made), a freeze amount indicating an amount of currency to be held in the funding account (if an adjustment is being made), an instance identifier of the account to be frozen (if a freeze is being made), a field corresponding to a legal basis for the freeze command, a tag for the instance of payment processing resource 106 (if an adjustment is being made), a number of decimal points used by the account to provide balance updates (if an adjustment is being made), a spending limit for the funding account associated with the instance of payment processing resource 106 (if an adjustment is being made), and a cryptographic signature provided by the account holder.

[0411] The adjusted settings provided in the request are processed in step S1002 to determine whether the settings adjustment is correct (i.e., does not violate the requirements of the payment processing resource 106). For example, if the data is invalid, the settings adjustment may be incorrect. For example, one example may be a timestamp that is a negative number. Another example may be that the instance identifier of the account to be frozen is incorrect, i.e., does not match the instance identifier of the account identified in the request. Another example may be that the minimum balance is greater than the maximum balance. If the settings adjustment is incorrect, the payment processing resource 106 will issue a failed request message to the first computing device. This is step S1004. In a request that includes multiple adjustments, the payment processing resource 106 can be configured to reject requests for all adjustments if one of the adjustments is found to be incorrect.

[0412] If the settings are adjusted correctly, the payment processing resource 106 will proceed to check the cryptographic signature provided in the request. This is step S1006.

[0413] The instance identifier is stored in the instance data structure 170 along with a corresponding license identifier of the license data structure corresponding to the instance of the payment processing resource 106. The payment processing resource 106 retrieves the license identifier from the instance data structure 170. The payment processing resource 106 then issues a request to the license data store 180 to check the cryptographic signature provided in the request in step S1000.

[0414] This will involve providing the data (i.e., data that has been cryptographically signed) in the request along with the cryptographic signature so that the cryptographic signature can be verified using appropriate techniques. If the cryptographic signature provided in the request is the same as the cryptographic signature generated by the public key, then the request for the setting adjustment can proceed in step S1008, and a response can be generated to confirm that the setting was updated. The change to the setting can then be recorded in an event stream corresponding to the instance of the payment processing resource 106. A hash of the instruction data can be generated and included in the event stream, and can be included in the response to the first computing device 102 confirming the setting change. If the compared signatures are not the same, a rejection message is issued to the first computing device 102 in step S1010.

[0415] about Fig.10 The process described can be used to change the settings of an instance of the payment processing resource 106. Determining that the settings are changed correctly and checking the signature can form an adjusted settings agreement. This can be used to change the maximum balance and minimum balance, but can also be used to freeze or unfreeze an account. When a request to change settings is received, the license data structure is checked to see if the signature is correct. If it is correct, the adjustment can be made. If it is not correct, the adjustment cannot be made.

[0416] In some cases, the account manager may generate the setting change and provide the call described in step S1000. In this case, the account manager may check its license data structure to ensure that the license data structure provides the right to make the change.

[0417] We will now describe how to use cryptographic signatures for signing instruction data to prevent duplicate transactions from being processed and duplicate entries from being added to the associated event stream. Fig.11 Although this is described with respect to a single instance of a payment processing resource 106, it should be understood that this can apply to each instance of a payment processing resource 106 involved in a transaction.

[0418] In step S1100, the payment processing resource 106 receives a request to process a transaction. The request includes instruction data as described above in step S400. The request identifies the instance of the payment processing resource 106, and parsing the instruction data (in step S404) can identify the other parties to the transaction (i.e., Bob), and therefore the other instances involved in the transaction processing.

[0419] In step S1102 , the payment processing resource 106 identifies the cryptographic signature that the debitor (Alice in the example above) used to cryptographically sign the instruction data.

[0420] Alternatively, the payment processing resource 106 may identify the signature of the other party to the transaction (eg, a lender).

[0421] In step S1104, the payment processing resource 106 accesses the payment data storage 124 to determine whether the cryptographic signature has been recorded in the payment data storage 124, i.e., as a transaction that has been carried out and will be associated with the parties involved in the transaction in the event stream. The payment data storage 124 can classify transactions according to any suitable value, such as the transaction date, the cryptographic signature used to sign the instruction data, or any other suitable value.

[0422] If the cryptographic signature already exists in the payment data store 124, then the transaction has likely already been processed and a rejection message is provided in step S1106. In some embodiments, the log in the payment data store 124 may be checked only within a predefined time period (e.g., the previous 30 days), or the check may be limited to the most recent 100 entries.

[0423] If the cryptographic signature is not already present in the payment data store 124, then the transaction has most likely not been processed and the transaction passes to the steps outlined in steps S406 to S428 and steps S500 to S520.

[0424] That is, the payment processing resource 106 may determine that the transaction may have been processed previously. Duplicate transactions (ie, executing the same instructions at the same time) are undesirable for both account holders and account managers and need to be prevented.

[0425] Alice and Bob (using the previous example) may submit instruction data at the same time, which will generate a continue response for Alice and a reject response for Bob. In this case, the payment processing resource 106 can then respond by reprocessing after a specified period of time (e.g., 100-300 milliseconds) to allow the corresponding event stream to be correctly updated, and thus it can be determined again whether there is a duplication.

[0426] It should be noted that the above aspects and embodiments illustrate rather than limit the present disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present disclosure as defined by the appended claims. In the claims, any reference numerals in parentheses shall not be interpreted as limiting the claims. The words "comprises" and the like do not exclude the presence of elements or steps other than those listed as a whole in any claim or in the specification. In this specification, "comprises" means "includes" or "consists of...". The singular form of an element does not exclude the plural form of such elements, and vice versa. The present disclosure may be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by the same hardware. The fact that certain measures are cited in mutually different dependent claims does not mean that a combination of these measures cannot be used to advantage.

Claims

1. A computer-implemented method for verifying at least one data item provided during an asset transfer event, the method being implemented by a processing resource, the method comprising: Receive request data from a computing device, the request data comprising: - an instruction data set comprising an identifier of an entity associated with the asset transfer event; - a challenge data structure, wherein the challenge data structure comprises: o a first numeric identifier of the at least one data item; ○ a representation of the at least one data item; The validity of the at least one data item is determined by: - determining a consistency between said representation of said at least one data item and a data item stored in said license data structure by determining that a corresponding voucher is present in said instruction data set or in a license data structure associated with said entity; generating a second digital identifier for the corresponding credential in the corresponding instruction data set or license data structure; Generate response data, the response data including: - an identifier of the corresponding credential; - said second numeric identifier; - a signature associated with said first digital identifier and said second digital identifier; The response data is sent to the computing device. 2 . The method according to claim 1 , wherein the first digital identifier and the second digital identifier are random numbers generated for the corresponding data item or response data.

3. The method according to claim 1 or 2, wherein the combination of the first digital identifier and the second digital identifier is a concatenation of the first digital identifier and the second digital identifier. 4 . The method of claim 3 , wherein the second digital identifier is located at a first position in the concatenation of the first digital identifier and the second digital identifier.

5. A method according to any preceding claim, wherein the representation of the data item comprises at least one alphanumeric sequence of characters.

6. A method according to any preceding claim, wherein determining the consistency between the representation of the data item and a data item stored in a license data structure, wherein the license data structure is associated with the entity, comprises the following steps: - obtaining said representation of said data item from said challenge data structure; Page 2 / 2 - querying the instruction data set to obtain a credential corresponding to the data item; as well as - based on the query, retrieving an identifier corresponding to the credential, or querying a license data structure associated with the identifier of the entity to obtain a credential corresponding to the data item; as well as - based on said query of said license data structure, retrieving an identifier corresponding to said voucher corresponding to said data item.

7. A method according to claim 6, wherein the query returns a voucher corresponding to the data item if the corresponding instruction data or license data structure contains a field containing an identical representation of the data item.

8. The method of claim 6, wherein the query provides a rejection response if the corresponding instruction data or license data structure does not contain a field containing an identical representation of the data item.

9. A method according to any preceding claim, wherein the challenge data structure further comprises an identifier of the challenge data structure, and the response data comprises an identifier of the response data structure.

10. The method of claim 9, wherein the identifier of the challenge data structure and the identifier of the response data structure are the same.

11. A computer-implemented method for verifying at least one data item during an asset transfer event, the method being implemented by a first processing resource, the method comprising: Generate request data, the request data including: - an instruction data set comprising an identifier of an entity associated with the asset transfer event; - a challenge data structure, wherein the challenge data structure comprises: o a first numeric identifier of the at least one data item; ○ a representation of the at least one data item; sending the request data to a second processing resource; receiving response data from the second processing resource; The data item is verified by determining from the response data that there is a signature of the combination of the second digital identifier in combination with the first digital identifier.

12. A system comprising hardware configured to implement the method according to any one of claims 1 to 10.

Images