COMPUTER-IMPLEMENTED METHOD AND SYSTEM FOR PROVIDING ACCESS TO MULTIPLE BLOCKCHAIN-RELATED FUNCTIONALITY AND APPLICATIONS

Abstract

A computer-implemented method and system are provided that allows interaction between a device and an asset transfer platform. Interactions can occur only if a permissions data structure allows the interaction to occur.

Description

[Technical field]

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

[0002] The term "blockchain" is used herein to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and non-permissioned ledgers, shared ledgers, public and private blockchains, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. For convenience and illustrative purposes, Bitcoin may be referenced herein, but it should be noted that the present disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols related to any type of digital asset or representation of a digital asset are within the scope of the present disclosure. The terms "client," "entity," "node," "user," "sender," "recipient," "payer," and "payee" may refer to computing or processor-based resources herein. The term "Bitcoin" is used herein to include any version or variation derived from or based on the Bitcoin protocol. The term "digital asset" may refer to any transferable asset, such as cryptocurrency, 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 will be understood that the term "digital asset" is used throughout this specification to refer to an artifact that may be associated with value that may be transferred or provided as payment in a transaction from one entity to another.

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

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

[0005] It will be appreciated that the nature of the work performed by miners depends on the type of consensus mechanism used to maintain the blockchain. It will be appreciated that while proof of work (PoW) is associated with the original Bitcoin protocol, other consensus mechanisms 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. may be used. Different consensus mechanisms differ in how mining is distributed among nodes, depending on the likelihood of successfully mining a block, for example, depending on the miner's hashing power (PoW), the amount of cryptocurrency held by the miner (PoS), the amount of cryptocurrency pledged to the representative miner (DPoS), the miner's ability to memorize a pre-determined solution to a cryptographic puzzle (PoC), the waiting time randomly assigned to the miner (PoET), etc. Typically, miners are provided with an incentive or reward for mining a block. The Bitcoin blockchain, for example, rewards miners with newly minted cryptocurrency (Bitcoins) and a fee associated with transactions in the block (transaction fee). In the case of the Bitcoin blockchain, the amount of cryptocurrency mined decreases over time, and eventually the incentive consists only of transaction fees. It will be appreciated that the processing of transaction fees is therefore part of the underlying mechanism for entrusting data to a public blockchain, such as the Bitcoin blockchain.

[0006] As mentioned above, each transaction in a given block encodes the transfer of control of a digital asset between participants in the blockchain system. The digital asset does not necessarily have to correspond to a cryptocurrency. For example, a digital asset may relate to a digital representation of a document, an image, a physical object, etc. Payment of the cryptocurrency and / or transaction fees to miners may simply serve as an incentive for maintaining the validity of the blockchain by performing the necessary work. It may be that the blockchain itself is a ledger for transactions that involve mostly non-cryptocurrency digital assets, and the cryptocurrency associated with the blockchain serves as security for the miners. In some cases, it may be that transfers of cryptocurrency between participants are handled by entities different from and / or independent of the entities that use the blockchain to maintain the ledger of transactions.

[0007] Once stored in the blockchain as a UTXO, a user can transfer control of the associated resource to another address associated with an input in another transaction. This transfer is typically, but not inherently, done using a digital wallet. This digital wallet may be a device, a physical medium, a program, an application (app) on a computing device such as a desktop, laptop, or mobile terminal, or a remotely hosted service associated with a domain on a network such as the Internet. Digital wallets can be used to store public and private keys, track ownership of resources associated with a user, i.e., tokens and assets, receive or consume digital assets, and transfer tokens, which may relate to digital assets such as cryptocurrencies, licenses, property, or other types of resources.

[0008] While blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are exploring the use of both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be extremely advantageous if blockchain could be used for automating tasks and processes that are not limited to the scope of cryptocurrency. Such solutions would be more versatile in their applications, yet be able to take advantage of the benefits of blockchain (e.g., permanent, tamper-proof records of events, distributed processing, etc.).

[0009] One area of ​​current research is the use of blockchain for the implementation of "smart contracts". These are computer programs designed to automate the execution of the terms of a machine-readable contract or agreement. Unlike traditional contracts, which would be written in natural language, smart contracts are machine-executable programs with rules that can process inputs to produce outcomes, which can then cause actions to be taken depending on those outcomes.

[0010] In particular, one area of ​​research concerns the transfer of assets and how they can be recorded on the blockchain to ensure that the transfer benefits from the immutability of the blockchain. Furthermore, it is of particular interest to provide efficient and secure protocols for the transfer of assets, as well as a means of logging such transfers to ensure that transfers are securely recorded and logged with the support of the underlying blockchain infrastructure. [Prior art documents] [Patent documents]

[0011] [Patent Document 1] UK Patent Application No. 2102314.8 [Patent Document 2] GB2002285.1 [Patent Document 3] GB2020279.2 [Patent Document 4] PCT / IB2021 / 051261 [Patent Document 5] PCT / IB2021 / 051258 [Patent Document 6] PCT / IB2021 / 051260 [Patent Document 7] PCT / IB2021 / 051333 [Patent Document 8] GB2109064.2 [Patent Document 9] UK Patent Application No. 2102217.3 Summary of the Invention [Means for solving the problem]

[0012] Throughout this specification, the word "comprise" or variations such as "includes," "comprises," or "comprising" are understood to imply the inclusion of a stated element, integer, step, or group of elements, integers, or steps, but not the exclusion of any other element, integer, step, or group of elements, integers, or steps.

[0013] In some embodiments, a computer-implemented method of appending entries to at least one event stream is provided. The event stream may comprise a blockchain-supported append-only log, where data recorded in a blockchain transaction is added to a time-ordered log. That is, the event stream logs data recorded on the blockchain in chronological order, i.e., as they appear on the blockchain. The event stream may be implemented using any suitable data structure. The event stream may comprise a series of entries stored in sequence, where 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. The use of an underlying blockchain means that it can be guaranteed that individual entries in the event stream have not been modified since they were written, that entries have not been inserted between previous consecutive entries, that entries have not been removed, and that entries have not been reordered. It is also not possible for unauthorized parties to append events to the event stream. At least one event stream may relate to an asset account associated with a user registered on the asset transfer platform. The method may be performed on a processing resource, which may be hardware or software implemented.

[0014] The method may comprise receiving a request to append an entry to at least one event stream, the entry comprising instruction data and an identifier for the at least one event stream. The instruction data may relate to a transaction being processed by the processing resource or by a further resource in communication with the processing resource. The request may be received via a data communications network or via an application programming interface (API) call. The method may further comprise retrieving an identifier for 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 further comprise accessing the at least one event stream and retrieving 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 remove entries older than a specified expiration date. The method may further comprise retrieving instruction data from the request. The instruction data may comprise a number of data items that may be further processed by the processing resource.

[0015] The method may comprise generating a unique identifier for the instruction data. Generating the unique identifier may comprise extracting the unique identifier from the instruction data. Such a unique identifier may be a cryptographic signature used to sign the instruction data. Generating the unique identifier may comprise processing the instruction data to generate the identifier, for example, using a hashing algorithm.

[0016] Based on the generated unique identifier, the method may further comprise determining whether data identical to the instruction data is present in a log of prior entries associated with the identified event stream. This may comprise searching through the log for the generated unique identifier to determine its presence or absence in the log of prior entries. The log of prior entries may be a database of transactions that have been recorded on the event stream.

[0017] Based on the result of the determining step, the method may further comprise either appending an entry to at least one event stream, the entry comprising a unique identifier for the instruction data, or rejecting the entry to the event stream as a duplicate entry.

[0018] In some embodiments, a computer-implemented method of validating 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 randomly or pseudo-randomly generated string. The method may be implemented by a processing resource. The processing resource may be a software-based or hardware-based resource. The method may comprise receiving request data from a computing device. The computing device may be a mobile computing device. The request data may comprise an instruction data set comprising an identifier for an entity associated with the asset transfer event. The request data may further comprise a challenge data structure. The challenge data structure may comprise a first numerical identifier for the at least one data item and / or a representation of the at least one data item.

[0019] The method is: - determining the validity of the at least one data item by determining a match between a representation of the at least one data item and a stored data item in the authorization data structure by determining the presence of a corresponding credential in either the instruction data set or an authorization data structure associated with the entity. The corresponding credential may be the same data item or may be another data item equivalent to the data item. For example, the corresponding credential may be a hash of the data item.

[0020] The method may comprise generating a second numeric identifier for the corresponding credential in the respective command data set or authorization data structure.

[0021] The method may comprise generating response data comprising an identifier for the corresponding credential, and / or a second numerical identifier, and / or a signature associated with the first numerical identifier and the second numerical identifier.

[0022] The method may further comprise sending the response data to the computing device.

[0023] In another embodiment, a computer-implemented method of validating 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 randomly or pseudo-randomly generated string. The method may be performed 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 comprise generating request data. The request data may comprise an instruction data set comprising an identifier for an entity associated with the asset transfer event and / or a challenge data structure, where the challenge data structure may comprise a first numeric identifier for the at least one data item and / or a representation of the at least one data item.

[0024] The method may further comprise 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.

[0025] The method may further comprise receiving response data from the second processing resource.

[0026] The method may further comprise validating the data item by determining from the response data the presence of a signature of a combination of the second numeric identifier combined with the first numeric identifier.

[0027] In some embodiments, a computer-implemented method is provided for providing access to 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 by a processing resource that may be implemented through a cloud or through a collection of localized hardware or software resources. The method may comprise receiving a message from a client device associated with a user. The message may be received through a data communication network or another suitable means, such as by an application programming interface (API) call. The client device may be any computing device. The message may comprise at least one identifier of a message type associated with the message. This may be implemented using parameters in the API call. This may also be implemented using parameters in the message sent using the data communication network. The message may also comprise at least one identifier associated with a profile registered on the asset transfer processing platform, the profile relating to at least one event stream provided by the asset transfer processing platform, the at least one event stream associated with at least one asset type.

[0028] The event stream may comprise a blockchain-supported append-only log, where data recorded in a blockchain transaction is added to a log that is ordered in time. That is, the event stream logs data that is for recording on the blockchain in chronological order, i.e., as they occur in a sequence of blockchain transactions. The event stream may be implemented using any suitable data structure. The event stream may comprise a series of entries stored in a sequence, where 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. The use of blockchain transactions to write data into the event stream means that it can be guaranteed that individual entries in the event stream have not been modified since they were written, that entries have not been inserted between previous consecutive entries, that entries have not been removed, and that entries have not been reordered. It is also not possible for unauthorized parties to append events to the event stream. The message may also comprise request data related to a request associated with the message and the profile. The request data may comprise instruction data related to the request. The instruction data may identify the parties and / or authorization data structures that should be used to process the request.

[0029] A profile may correspond to an allocation of asset transfer platform resources used in processing an asset transfer 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 a method.

[0030] The method may further comprise determining from the received message a message type associated with the message and a profile registered on the asset transfer processing platform. Determining the message type may comprise processing the request to determine the presence of parameters in the API call or in the message transmitted over the data communications network.

[0031] The method may further comprise identifying a message response protocol for the determined message type based on the determined message type. The message response protocol defines a set of criteria for determining the response type or content of the response to be provided to the requestor. The message response protocol may define requirements for a request in order for the request to be fulfilled. The message response protocol may require accessing an authorization data structure to determine the presence of a data item or a cryptographic signature.

[0032] The method may further comprise identifying an authorization data structure for the profile, the authorization data structure providing at least criteria defining which users may interact with the profile using the determined message type. The authorization data structure may comprise a public key, a cryptographic signature generated using a private key corresponding to the public key, at least one data item, and an authorization identifier. The private key and the public key may be cryptographically paired. The private key and the public key may be generated using elliptic curve digital signature algorithm (ECDSA) techniques. The data item may be an alphanumeric sequence or a numeric sequence.

[0033] The method may further comprise processing the request data to determine the presence of a cryptographic signature used to sign the request data, and further processing the request data to extract a data item from the request data based on a determination of the presence of a cryptographic signature used to sign the request data.

[0034] The method may further comprise applying the identified message response protocol to the extracted data items. The application may comprise using the data items in the request data to determine whether an action can be taken in response to the request. The data items may comprise an identification of a party, an identification of an authorization data structure, an identification of an account holder, and / or an account administrator and an identification of an asset type.

[0035] An account holder may correspond to a user associated with a profile registered on the asset transfer platform. An account holder may correspond to an account, which may be a funding account including a currency offering to be used in transactions using the asset transfer platform. An account may alternatively or additionally correspond to an asset registry where an asset offering 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 used to operate the asset registry. In the example of a gold account, the account manager may be, for example, the Royal Mint at Llantrisant, UK, CF72 8YT, and the asset registry would be the account that a person has at the Royal Mint. Another example may be a funding account held at HSBC Bank, where the account manager would be HSBC Bank and the asset registry would be the funding account for their GBP (i.e., British Pound) deposits.

[0036] The method may further comprise generating a response to the message based on the message response protocol, the extracted data items, and the permission data structure by determining, using the permission data structure, whether the user is authorized to interact with the profile using the identified message type.

[0037] The method may further comprise determining, using a message response protocol, whether the extracted data item satisfies requirements of the determined message type, and generating response content by interacting with at least one event stream associated with the profile based on the requirements of the determined message type being satisfied.

[0038] In another embodiment, a computer-implemented method is provided that allows 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 performed by a processing resource that may be implemented using software or hardware or using a cloud-based resource.

[0039] The method may further comprise receiving a message from a client device associated with the user.

[0040] The message may further comprise at least one of an identifier associated with the balance update, and at least one identifier associated with a profile registered on the asset transfer processing platform.

[0041] The method may further comprise determining from the received message at least one profile identified in the message. The profile may correspond to an instance of the asset transfer platform.

[0042] The method may further comprise applying an update request protocol to the extracted data items to determine if the balance may be updated. The update request protocol may comprise a set of criteria that is used to determine if the balance may be updated, i.e., whether a transfer from the account may occur. A transfer from an account may be a transfer of a portion of an asset to another party.

[0043] The method may further comprise determining using the permissions data structure whether the user has the required cryptographic rights to update the balance, determining using an update request protocol whether the update can be made, and generating a response to the message based on the update request protocol, the extracted data items, and the permissions data structure by updating the balance based on a match with the determined message type requirements and generating response content by interacting with at least one event stream associated with the profile.

[0044] Interacting with an event stream may comprise at least one of looking at the event stream, taking 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 an event stream may generate its own response content. The response content may be a message to an entity requesting interaction with the event stream or a message to an entity associated with the event stream.

[0045] In some embodiments, a computer-implemented method is provided for enabling access to an asset transfer processing platform. The method may be implemented by a processing resource. The method may comprise initializing an application on a computing device, the application configured to generate a message. The message may comprise at least one of: 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, the profile associated with at least one event stream implemented by the asset transfer processing platform, the at least one event stream associated with at least one asset type, and request data related to a request associated with the message and the profile.

[0046] The method may further comprise receiving input from a user identifying a message type for a message to be sent to the asset transfer processing platform. The input may further identify a profile registered on the asset transfer processing platform. The input may further comprise request data comprising content of a request to be made to the asset transfer processing platform.

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

[0048] The method may further comprise generating a message comprising an identifier of a message type identified by the user, an identifier of a profile registered on the asset transfer processing platform, and the signed request data.

[0049] The method may further comprise sending the message to an asset transfer processing platform.

[0050] In another embodiment, 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: - 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, the profile associated with at least one event stream associated with the asset transfer processing platform, the at least one event stream associated with at least one asset type; and - comprising request data relating to a request associated with a message and a profile;

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

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

[0053] The platform may be further configured to identify a permissions data structure for the profile, the permissions data structure providing criteria that define which users can interact with the profile using the determined message types.

[0054] Interaction with a profile may comprise any interaction with an event stream associated with the profile.

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

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

[0057] The platform may be further configured to generate a response to the message based on the message response protocol, the extracted data items, and the permission data structure by determining, using the permission data structure, whether the user has required cryptographic rights to interact with the profile using the identified message type, determining, using the message response protocol, whether the extracted data items satisfy requirements of the determined message type, and generating response content by interacting with at least one event stream associated with the profile based on the requirements of the determined message type.

[0058] The embodiments may be combined either in whole or in part.

[0059] Aspects and embodiments of the present disclosure will now be described, by way of example only, and with reference to the accompanying drawings. [Brief description of the drawings]

[0060] [Figure 1a] FIG. 1 illustrates a system according to one embodiment. [Figure 1b] FIG. 1 illustrates a node configured to implement Bitcoin software to enable blockchain transactions. [Figure 1c]FIG. 1 illustrates a blockchain network. [Figure 1d] FIG. 2 is a schematic diagram of a hierarchical permission structure. [Figure 1e] FIG. 2 is a schematic diagram of a hierarchical permission structure. [Figure 1f] FIG. 2 is a schematic diagram of a hierarchical permission structure. [Diagram 2] FIG. 1 illustrates the establishment of an instance of a payment processing resource according to one embodiment. [Diagram 3] 1 is a flowchart illustrating how computing devices may interact to extract information from an event stream. [Figure 4a] 1 is a flowchart illustrating how a payment processing device may process a transaction. [Figure 4b] 1 is a flowchart illustrating how a payment processing device may process a transaction. [Figure 5a] 11 is a flowchart illustrating how a challenge data structure and a response data structure may be used to validate a data item. [Figure 5b] 11 is a flowchart illustrating how a challenge data structure and a response data structure may be used to validate a data item. [Figure 6] 1 is a flowchart illustrating how an event stream is appended with data related to a transaction. [Figure 7] FIG. 2 illustrates a rendezvous transaction. [Figure 8] FIG. 1 shows a dust chain. [Figure 9] FIG. 2 illustrates an event stream for parties to a transaction. [Figure 10] 13 is a flowchart illustrating how the configuration of an instance of a payment processing resource may be adjusted. [Figure 11] 1 is a flowchart illustrating how duplicate transactions are prevented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0061] Next, detailed descriptions of aspects and embodiments of the present disclosure are provided in order to provide the reader with a full and complete understanding of the present disclosure.

[0062] Considering the first aspect, a computer-implemented method of appending entries to at least one event stream is provided. The event stream may comprise a blockchain-supported append-only log, where data recorded in blockchain transactions are added to a time-ordered log. That is, the event stream logs data recorded on the blockchain in chronological order, i.e., as they appear on the blockchain. The event stream may be implemented using any suitable data structure. The event stream may comprise a series of entries stored in a sequence, where 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. The use of an underlying blockchain means that it can be guaranteed that individual entries in the event stream have not been modified since they were written, that entries have not been inserted between previous consecutive entries, that entries have not been removed, and that entries have not been reordered. It is also not possible for unauthorized parties to append events to the event stream.

[0063] The at least one event stream may relate to an asset account associated with a user registered on the asset transfer platform. Registration of the user may comprise the generation of a profile on the asset transfer platform. The profile may correspond to an instance of a processing resource, such as, for example, a payment processing resource. The method may be implemented on the processing resource. The processing resource may comprise a hardware-based resource or a software-based resource. The method may comprise receiving a request to append an entry to the at least one event stream, the entry comprising instruction data and an identifier for the at least one event stream. The request may be received through a data communications network or an API call receiving the identifier for the at least one event stream as a parameter. The identifier for the at least one event stream may also identify the instance of the payment processing resource.

[0064] The method may comprise retrieving an identifier for the at least one event stream from the request. Based on the identifier, the method may further comprise accessing the at least one event stream and retrieving 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 by a predefined time period, i.e., seconds, minutes, hours, days, months, or years.

[0065] The method may comprise extracting instruction data from the request. The instruction data may comprise data items identifying the account, a party associated with the account, an authorization data structure associated with the account and an account administrator.

[0066] The method may comprise generating a unique identifier for the instruction data. Generating the unique identifier may comprise retrieving the unique identifier from the instruction data. The unique identifier may be a cryptographic signature used to sign the instruction data. Generating the unique identifier may also comprise applying a hashing algorithm to the instruction data or generating the unique identifier by another suitable technique.

[0067] Based on the generated unique identifier, the method may further comprise determining whether data identical to the instruction data is present in a log of previous entries associated with the identified event stream, which may be by using the generated unique identifier as a search key within the log of previous entries.

[0068] Based on the result of the determining step, the method may further comprise either appending an entry to at least one event stream, the entry comprising a unique identifier for the instruction data, or rejecting the entry to the event stream as a duplicate entry.

[0069] The method according to the first aspect prevents duplicate entries from being placed on the event stream, which is important because duplicate entries may comprise immutable portions of the event stream, which reduces confidence in the integrity of the data recorded therein.

[0070] The unique identifier for the instruction data may comprise a cryptographic signature used to cryptographically sign the instruction data. The cryptographic signature may be generated using ECDSA techniques. The cryptographic signature may be retrieved from an authorization data structure associated with an entity associated with the transaction.

[0071] The request may be to append an entry to a plurality of event streams, and the method may further comprise retrieving an identifier for each of the plurality of event streams from the request. The request may further comprise identifying each of the plurality of event streams and a corresponding log of a previous entry. The method may further comprise using the unique identifier as a search key and determining 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 comprises either appending an entry to each of the event streams using the unique identifier or rejecting the entry to the plurality of event streams.

[0072] The effect of this is that if a request identifies multiple event streams, a transaction cannot be processed even if it has already been recorded in one of those event streams.

[0073] The method may further comprise determining from the instruction data a condition for the at least one event stream that must be satisfied in order for an entry to be added to the at least one event stream and determining whether the condition is satisfied before adding the entry to the at least one event stream, where the condition may be that an 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.

[0074] The processing resources may be configured to maintain the log at a maximum size by removing entries that have been in the log longer than a predefined maximum period of time.

[0075] When a further request is received substantially simultaneously with the request to append an entry to the at least one event stream, and the further request comprises identical instruction data as the request to append an entry to the at least one event stream, the method comprises rejecting both requests, the effect of which is that data integrity of the event stream is not compromised by a situation in which instruction data is sent twice at the same time, i.e. before processing can be performed to realise that there is a duplication in the log of entries.

[0076] Considering the first aspect, there is a computer-implemented method of validating 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 randomly or pseudo-randomly generated string. 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 comprise receiving request data from the 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.

[0077] The request data may comprise an instruction data set comprising an identifier for an entity associated with the asset transfer event. The request data may comprise a challenge data structure, where the challenge data structure may comprise a first numeric identifier for 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.

[0078] The method may further comprise determining validity of the at least one data item by determining a match between a representation of the at least one data item and a stored data item in the authorization data structure by determining the presence of a corresponding credential in either the instruction data set or an authorization data structure associated with the entity. The corresponding credential may be a hash of the data item.

[0079] The method may further comprise generating a second numeric identifier for the corresponding credential in the respective command data set or authorization data structure.

[0080] The method may further comprise generating response data comprising an identifier for the corresponding credential and / or the second numeric identifier and / or a signature associated with the first numeric identifier and the second numeric identifier.

[0081] The method may further comprise sending the response data to the computing device.

[0082] The method according to the first aspect provides a way to securely validate a data item. The data items may be exchanged during an asset transfer event, such as a transfer of funds. The data items are securely validated because a signature is provided only if the data item can be validated based on either the authorization data structure or another data structure. Multiple data items may be provided, and the method may be repeated for each of the multiple data items. The provider of the response data structure is required to provide a signature associated with the first and second numerical identifiers to indicate that they have validated the data item. A signature cannot be provided based on an authorization data structure that the provider of the response data does not own, since the owner's private key is required to generate that signature. The response data structure may identify a satisfactory authorization data structure (e.g., using the authorization identifier), which allows the parties to determine an authorization data structure that can be used to check the signature that has been used to generate the signature associated with the identifier. The signature may be a cryptographic signature. The provider of the challenge data structure provides the numerical identifier (the second numerical identifier) ​​so that the provider of the response data structure cannot regenerate the signature just from an authorization data structure that they do not own. The provider of the response data structure provides a numeric identifier so that the provider of the challenge data structure cannot easily "phish" for a signature across several useful messages.

[0083] The first and second numeric identifiers may be nonces generated for the respective data items or response data. The first and second numeric identifiers may be nonces based on the respective data items or response data. The combination of the first and second numeric identifiers may be a concatenation of the first and second numeric identifiers, and the second numeric identifier may be placed first in the concatenation of the first and second numeric identifiers.

[0084] The method is: - obtaining a representation of a data item from a challenge data structure; - querying the instruction dataset for credentials corresponding to the data item; - retrieving an identifier corresponding to the credential based on the query or querying an authorization data structure associated with the identifier for the entity for a credential corresponding to the data item; and - by retrieving an identifier corresponding to a credential corresponding to a data item based on a query of an authorization data structure; The method may comprise determining a match between the representation of the data item and a stored data item in a permissions data structure associated with the entity. The method may further comprise generating response content comprising an indication of the validation of the data item.

[0085] The query may return credentials corresponding to a data item only if the respective command data or permission data structure includes a field containing an identical representation of the data item. The query provides a rejection response if the respective command data or permission data structure does not include a field containing an identical representation of the data item.

[0086] The challenge data structure may further comprise an identifier for the challenge data structure, and the response data comprises an identifier for the response data structure. The identifiers for the challenge data structure and the response data structure may correspond in a number of suitable ways. This may mean that the response data structure references the challenge data structure. The identifier for the challenge data structure may be identical to the identifier for the response data structure. The identifier for the response data structure provides the advantage of a recordable link between the response and challenge data structures and the corresponding authorization data structures.

[0087] Viewed from a second aspect, there is provided a computer-implemented method for validating at least one data item during an asset transfer event. The method may be implemented by a first processing resource. The method may comprise generating request data. The request data may include: - an instruction data set that may comprise an identifier for an entity associated with the asset transfer event; and / or A challenge data structure may be provided, where the challenge data structure comprises: a first numeric identifier for at least one data item, and / or ○Has a representation of at least one data item.

[0088] The method may comprise sending the request data to the second processing resource. The request data may be sent using any suitable means, such as a data communications network or an API call.

[0089] The method may comprise receiving response data from the second processing resource.

[0090] The method may comprise validating the data item by determining from the response data the presence of a signature of a combination of the second numeric identifier combined with the first numeric identifier.

[0091] A method according to a second aspect provides a method of validating a data item that involves sending request data to a second processing resource comprising a challenge data structure that identifies the data item and comprises a representation of the data item. The data item can only be determined if a signature is provided. The signature can be checked using an authorization identifier that may be provided in the response data.

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

[0093] Considered from a further aspect, a computer-implemented method of providing access to an asset transfer processing platform is provided. The method may be implemented by a processing resource. The method may comprise receiving a message from a client device associated with a user. The message may comprise at least one identifier of a message type associated with the message. The message may further comprise at least one identifier associated with a profile registered on the asset transfer processing platform, the profile relating to at least one event stream provided by the asset transfer processing platform, the at least one event stream relating to the at least one asset type. The message may further comprise request data related to a request associated with the message and the profile. The method may further comprise determining from the received message a message type associated with the message and a profile registered on the asset transfer processing platform. The method may further comprise identifying a message response protocol for the determined message type based on the determined message type. The method may further comprise identifying an authorization data structure for the profile, the authorization data structure providing at least criteria defining which users can interact with the profile using the determined message type. The method may further comprise processing the request data to determine the presence of a cryptographic signature used to sign the request data, and further processing the request data to extract a data item from the request data based on a determination of the presence of a cryptographic signature used to sign the request data. The method may further comprise applying the identified message response protocol to the extracted data item.The method may further comprise determining, using a permission data structure, whether the user is authorized to interact with the profile using the identified message type, determining, using a message response protocol, whether the extracted data items satisfy requirements of the determined message type, and generating a response to the message based on the message response protocol, the extracted data items, and the permission data structure by generating response content by interacting with at least one event stream associated with the profile based on the requirements of the determined message type being satisfied.

[0094] A method according to a further aspect provides a way by which a user can interact with the asset transfer platform, the interaction being determined by the permissions provided by a permission data structure that provides cryptographic security for the interaction, meaning that some interactions may be allowed by the permissions, where some interactions may not be allowed.

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

[0096] The method allows content to be extracted from the event stream and provided to clients, what with the cryptographic security provided by the authorization data structure being made possible.

[0097] The permissions data structure may comprise data identifying at least one of an asset type associated with the profile, an asset manager identifier, permissions provided to the asset manager by the profile, and permissions provided to a user associated with the profile.

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

[0099] The effect of this is that only certain actions on the event stream are permitted, and these are determined by the message-response protocol and the criteria it sets regarding the contents of the permission data structure.

[0100] The identified message type may correspond to a retrieval request, and further, the message response protocol is a retrieval request protocol, and applying the retrieval request protocol may comprise determining whether the client device is authorized to access the profile by determining whether a session permission has been issued to the client device, and if a session permission 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 a response provided to the client device, and further, if a session permission has not been issued to the client device, the processing resource generates a rejection message and provides the rejection message to the client device.

[0101] That is, the method may allow a client to retrieve data from an event stream, provided that a session authorization may be provided. A session authorization may be provided that is valid only for a specified period of time. A session authorization may also be revoked by the holder of the authorization data structure.

[0102] The identified message type corresponds to an update request requesting an update to at least one account associated with the asset type, and further, the message response protocol is an update request protocol, and applying the update request protocol comprises determining whether the update is a duplicate based on a data item extracted from the request data by determining the presence of corresponding instruction data on a log of events previously appended to the event stream, and further, if the update is a duplicate update, generating a response message to be provided to the client device indicating that the update is a duplicate, and further, if the update is not a duplicate, applying an update processing protocol to the request data to determine validity of the update, and if the update is valid, appending the update to the event stream, and if the update is not valid, generating a rejection message for the client device.

[0103] That is, the method may allow a client to update a balance, subject to what is allowed by the authorization data structure, provided an update request has not been made previously.

[0104] Generating the update request may comprise generating a blockchain transaction for synchronizing event streams corresponding to entities identified in the request data, where the blockchain transaction comprises, for each of the entities identified in the request data, a dust input that consumes a dust output associated with a previous transaction and a respective unconsumed transaction output corresponding to the dust input, where the unconsumed transaction output is associated with the request, and updating the event streams corresponding to the entities identified in the request data.

[0105] The identified message type may correspond to a setting request requesting a change to at least one field in a profile associated with the asset transfer processing platform, and the message response protocol is a setting request protocol, and applying the setting request protocol comprises extracting from the data item at least one identifier that respectively identifies a profile setting to be modified, determining from a permissions data structure whether the user is authorized to make the modification, and modifying the at least one setting based on the permissions data structure.

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

[0107] The data item may comprise a timestamp identifying the time the message was generated, and the processing resource may be configured to approve the request if the timestamp indicates that the message was generated within a determined time period from the current time, and to reject the request if the timestamp indicates that the time the message was generated was outside the determined period.

[0108] Considered from a further 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 comprise receiving a message from a client device associated with the user. The message may comprise an identifier associated with the balance update, at least one identifier associated with a profile registered on the asset transfer processing platform, the profile associated with at least one event stream provided by the asset transfer processing platform, the at least one event stream associated with at least one asset type, and request data related to the balance update. The method may further comprise determining from the received message at least one profile identified in the 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 through the cloud or through hardware or software. The method may further comprise identifying an authorization data structure, the authorization data structure providing criteria defining which users may update the balance. The authorization data structure may associate a cryptographic signature with a data item. The data item may be an alphanumeric or numeric sequence. The data items may be generated randomly, deterministically, or pseudo-randomly.

[0109] A method according to a further aspect provides a secure manner in which an asset transfer platform can process requests to update balances. The method utilizes an authorization data structure to provide cryptographic support for preventing users from updating balances who do not have the right to do so.

[0110] The method may further comprise processing the request data to determine the presence of a cryptographic signature used to sign the request data, and further processing the request data to extract from the request data a data item to be used in updating the balance based on a determination of the presence of a cryptographic signature used to sign the request data. The method may further comprise applying an update request protocol to the extracted data item to determine whether the balance can be updated. The balance update may result from a transaction based on instruction data provided by the client. The instruction data may be signed with a cryptographic signature that is validated based on the authorization data structure.

[0111] The method may further comprise generating a response to the message based on the update request protocol, the extracted data items, and the permissions data structure by determining if the user has the required cryptographic rights to update the balance using the permissions data structure, determining if the update can be made using the update request protocol, and updating the balance based on a match with the requirements of the determined message type and generating response content by interacting with at least one event stream associated with the profile.

[0112] Considered from a further aspect, a computer-implemented method is provided that allows a user to use a computing device to access an asset transfer processing platform. The user may use an identifier to access the asset transfer processing platform. The asset transfer processing platform may be a payment processing resource. The asset transfer processing platform may be implemented in software or hardware. Access to the asset transfer processing platform may be via a data communication network or by another suitable method, such as by an API call that utilizes an identifier for the user and parameters to identify what the interaction is required. The method may be implemented by a processing resource. The processing resource may be software or hardware implemented. The processing resource may be a cloud implemented or distributed across multiple processors. The method may comprise initializing an application on the computing device, the application may be configured to generate a message, 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, the profile associated with at least one event stream implemented by the asset transfer processing platform, the at least one event stream associated with the at least one asset type, and request data relating to a request associated with the message and the profile. The method may comprise receiving input from a user identifying a message type for a message to be sent to the asset transfer processing platform, the profile registered on the asset transfer processing platform, and request data comprising content of the request to be made to the asset transfer processing platform. The method may further comprise applying a cryptographic signature to the request data to generate signed request data.The method may further comprise generating a message comprising an identifier of a message type identified by the user, an identifier of a profile registered on the asset transfer processing platform, and signed request data. The method may further comprise sending the message to the asset transfer processing platform.

[0113] A method according to a further aspect provides a method by which a user can send messages to the asset transfer platform. An application allows a user to provide instruction data that is then signed such that it can be used in combination with an authorization data structure to securely enable the user to interact with the asset transfer platform.

[0114] Considered from a further aspect, an asset transfer processing platform is provided that is 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, the profile associated with at least one event stream implemented by the asset transfer processing platform, the at least one event stream associated with the at least one asset type, and request data related to a request associated with the message and the profile. The asset transfer processing platform may be configured to determine a message type associated with the message and a profile registered on the asset transfer processing platform from the received message. The asset transfer processing platform may further 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 an authorization data structure for the profile, the authorization data structure providing criteria that define which users can interact with the profile using the determined message type. The asset transfer processing platform may be further configured to process the request data to determine the presence of a cryptographic signature used to sign the request data, and further process the request data to extract data items from the request data to be used in determining a response using the identified message response protocol based on a determination of the presence of a cryptographic signature used to sign the request data. 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 comprise a set of criteria that is used to determine whether a response may be provided and what that response may be.The message response protocol may generate a response to the message based on the message response protocol, the extracted data item, and the permission data structure by determining, using the permission data structure, whether the user has the required cryptographic rights to interact with the profile using the identified message type, determining, using the message response protocol, whether the extracted data item satisfies the requirements of the determined message type, and generating response content by interacting with at least one event stream associated with the profile based on the requirements of the determined message type.

[0115] A method according to a further aspect provides a platform by which a user can interact with an event stream associated with an account. The interactions are determined by permissions provided by a permission data structure that provides cryptographic security for the interactions. This means that some interactions may be allowed by the permissions, where some interactions may not be allowed.

[0116] The embodiments and aspects according to the present invention may be combined in whole or in part.

[0117] Specific embodiments will now be described by way of example with reference to the accompanying drawings, in which like reference numbers refer to like features and in which:

[0118] Referring now to FIG. 1a, a system 100 will be described that allows a transfer of assets between a first user and a second user of the system 100 to be recorded.

[0119] The system 100 comprises a first computing device 102 and a second computing device 104. The first computing device 102 and the second computing device 104 may be any computing resource. Each of the first computing device 102 and the second computing device 104 is configured to interact with a payment processing resource 106 via respective first and second application programming interfaces (APIs) 108.

[0120] The payment processing resource 106 is configured to initialize and / or interact with event streams provided for at least each of a first user named Alice (110a), a second user named Bob (110b), and a payment processing resource (110c) using the event stream resource 110. The initialization of and interaction with the event streams by the payment processing resource 106 may be understood from UK Patent Application No. 2102314.8, filed on 18 February 2021 in the name of nChain Holdings Limited.

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

[0122] The blockchain 112 comprises at least one public proof-of-work blockchain according to the Bitcoin Satoshi Vision (BSV) protocol in that it is an append-only ledger of blocks (BSV1, BSV2, BSV3) composed of transactions.

[0123] The blockchain 112 comprises a number of nodes 126 configured with software as described below with respect to Figure 1b, each node being configured in accordance with this software as part of the blockchain, as described below with respect to Figure 1c.

[0124] FIG. 1b illustrates an example of node software 450 executed on each blockchain node 126 of the network 132 in an example UTXO-based or output-based model. Note that another entity may execute the node software 450 without being classified as a node 126 on the network 132, i.e., without performing the actions required of a node 126. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 126 may execute node software including, but is not limited to, all three of a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 451 is typically configured to recognize various fields of the transaction 152 and process them according to the node protocol. Another preceding transaction 152i (Tx m-1 ) j ) is received, then the protocol engine 451 j The protocol engine 451 also identifies the unlocking script in the Tx j Based on the pointer in the input of Tx i Identify and extract Tx i may be published on the blockchain 150, in which case the protocol engine calculates Tx iAlternatively, Tx i , may not yet be published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 maintained by the node 126. i Either way, the script engine 451 can extract Tx i The script engine 452 then identifies the locking script among the referenced outputs of the script.

[0125] The script engine 452 executes the Tx i Locking script and Tx j 1b. For example, transactions labeled Tx0 and Tx1 are shown in FIG. 1b, but the same can apply to any pair of transactions. The script engine 452 executes the two scripts together as previously described, including placing and popping data on and from the stack 453 according to the stack-based scripting language being used (e.g., Script).

[0126] By executing the scripts together, the script engine 452 determines whether the unlocking script satisfies one or more criteria specified in the locking script (i.e., whether the unlocking script "unlocks" the output that the locking script contains). The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script satisfies one or more criteria specified in the corresponding locking script, it returns a result of "true". Otherwise, the script engine 452 returns a result of "false".

[0127] In the output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of a transaction.j the aggregate value of the Digital Assets specified in the output of Tx will not exceed the aggregate value indicated by its input; i There are also one or more further protocol-level conditions evaluated by protocol engine 451 that must also be satisfied, such as that the pointed-to output of Tx has not already been consumed by another valid transaction. Protocol engine 451 evaluates the result from script engine 452 together with one or more protocol-level conditions, and accepts transaction Tx only if they are all true. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. j is indeed enabled, the decision engine 454 j , . This means that the consensus module 455C may choose to control both the consensus module 455C and the propagation module 455P to perform their respective blockchain-related functions with respect to Tx. j and the propagation module 455P transmits the Tx j 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 both valid and has sufficient transaction fees remaining.

[0128] It should also be noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model, a "true" outcome can be indicated by a combination of an implicit protocol-level enablement of a signature and an additional positive output of a smart contract (where both individual outcomes are true, the overall outcome is considered to signal true).

[0129] Other variations or uses of the disclosed techniques may become apparent to those of ordinary skill in the art given the disclosure herein, and the scope of the disclosure is limited only by the appended claims, and not by the described embodiments.

[0130] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 126. However, it will be appreciated that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 126 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 126, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 126 as described above.

[0131] In a preferred embodiment of the present invention, the blockchain network 132 is the Bitcoin network, and the Bitcoin nodes 126 perform at least all of the described functions of 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 one or some, but not all, of these functions. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be suitable Bitcoin network 132 nodes).

[0132] In non-preferred embodiments of the present invention, the blockchain network 132 may not be the Bitcoin network. In these embodiments, it is not precluded that a node may perform at least one, or some, but not all, of the functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, on those other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151, rather than storing and / or propagating those blocks 151 to other nodes.

[0133] Even more generally, any reference above to the term "Bitcoin 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 of creating, publishing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in a similar manner as described above with reference to blockchain node 126.

[0134] Even more generally, any reference above to the term "Bitcoin 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 of creating, publishing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in a similar manner as described above with reference to blockchain node 126.

[0135] 1c illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may be comprised of a packet-switched network 130, typically a wide-area internetwork such as the Internet. The packet-switched network 130 comprises a number of blockchain nodes 126 that may be configured to form a peer-to-peer (P2P) network 132 within the packet-switched network 130. Although not shown, the blockchain nodes 126 may be configured as a nearly complete graph. Each blockchain node 126 is therefore highly connected to other blockchain nodes 126.

[0136] Each blockchain node 126 comprises a peer's computer equipment, with different nodes 126 of the nodes 126 belonging to different peers. Each blockchain node 126 comprises a processing device comprising one or more processors, for example, one or more central processing units (CPUs), accelerator processors, application specific processors, and / or other equipment, such as field programmable gate arrays (FPGAs), and application specific integrated circuits (ASICs). Each node also comprises a memory, i.e., computer readable storage in the form of one or more non-transitory computer readable media. The memory may comprise one or more memory units employing one or more memory media, for example, magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memories, or EEPROMs, and / or optical media such as optical disk drives.

[0137] The blockchain 150 comprises a chain of blocks 151 of data, with a respective copy of the blockchain 150 maintained at each of a number of blockchain nodes 126 in a distributed network or blockchain network 130. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be pruned of data, so long as each blockchain node 126 stores the block header (described below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, a transaction in this context referring to a certain kind of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or transaction scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing a quantity of a digital asset as property, such as a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution in order to be unlocked and thereby redeemed or spent). Each input points back to the output of a preceding transaction 152, thereby linking the transactions.

[0138] Each block 151 also has a block pointer 155 that points back to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than coinbase transactions) has a pointer back to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes all the way back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0139] Each of the blockchain nodes 126 is configured to forward transactions 152 to other blockchain nodes 126, thereby propagating the transactions 152 throughout the network 132. Each blockchain node 126 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Each blockchain node 126 also maintains an ordered set 154 of transactions 152 waiting to be incorporated into a block 151. The ordered set 154 is often referred to as a "mempool." This term in this specification is not intended to limit any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 126 has accepted as valid and for which the node 126 is obligated not to accept any other transactions that attempt to consume the same output.

[0140] For a given current transaction 152j, the (or each) input comprises a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the current transaction 152j. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. The previous transaction 152i does not necessarily have to exist at the time that the current transaction 152j is created and even sent to the network 132, but the previous transaction 152i needs to exist and be valid for the current transaction to be valid. Thus, "preceding" in this specification refers to a predecessor in a logical sequence linked by a pointer, not necessarily to the time of creation or sending in a temporal sequence, and therefore does not necessarily exclude transactions 152i, 152j being created or sent out of order (see the discussion below on orphan transactions). The preceding transaction 152i may be equivalently referred to as an antecedent transaction or a predecessor transaction.

[0141] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of the user 103a to whom the output of the preceding transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to the new user or entity 103b. The current transaction 152j can thus transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152 may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to give change). In some cases, the transaction can also have multiple inputs to collect together the amount from multiple outputs of one or more preceding transactions and redistribute it to one or more outputs of the current transaction.

[0142] According to an output-based transaction protocol such as Bitcoin, when an entity 103, such as a user or a machine, wants to perform a new transaction 152j, it then sends the new transaction from its computer terminal to a recipient. The entity or recipient finally sends this transaction to one or more of the blockchain nodes 126 of the network 132 (today usually a server or a data center, but in principle it could be other user terminals). It is not excluded that the entity 103 performing the new transaction 152j may in some examples send the transaction to one or more of the blockchain nodes 126, rather than to the recipient. The blockchain nodes 126 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied in each of the blockchain nodes 126. The blockchain node protocol usually requires the blockchain nodes 126 to check that the cryptographic signature in the new transaction 152j matches an 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 comprise checking that a cryptographic signature or other authorization of the entity 103 included in the input of the new transaction 152j matches a condition specified in the output of the previous transaction 152i that the new transaction assigns, which typically comprises at least checking that 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 at least partially specified by a script included in the output of the previous transaction 152i. Alternatively, it may simply be fixed by the blockchain node protocol alone, or may result from a combination of these.Either way, 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 tests according to the same blockchain node protocol, and so forward the new transaction 152j to one or more further nodes 126, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 126.

[0143] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated is whether it has yet been validly redeemed by the input of another forward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to allocate or redeem has not already been allocated / redeemed by another transaction. Again, if not valid, the transaction 152j is not propagated or recorded in the blockchain 150 (unless it is flagged as invalid and propagated for warning). This protects against double-spending, whereby a transactor attempts to allocate the output of the same transaction more than once. On the other hand, the account-based model protects against double-spending by maintaining an account balance. Again, since there is a defined order of transactions, at any one time the account balance has a defined single state.

[0144] In addition to validating transactions, blockchain nodes 126 also compete to be the first to create a block of transactions, in a process supported by "proof of work," usually called mining. At the blockchain nodes 126, new transactions are added to an ordered set 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered set 154 of transactions and hashed, the output of the hash then satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has some predefined number of leading zeros. Note that this is just one particular type of proof of work puzzle, other types are not excluded. A property of a hash function is that it has an output that is unpredictable given its input. Therefore, this search can only be performed by brute force and therefore consumes a significant amount of processing resources at each blockchain node 126 attempting to solve the puzzle.

[0145] The first blockchain node 126 to solve the puzzle announces this to the network 132 and provides the solution as a proof, which can then be easily checked by other blockchain nodes 126 in the network (when the solution is given a hash, it is easy to check that the solution satisfies the conditions on the output of the hash). The first blockchain node 126 accepts the block and propagates it up to a threshold consensus of other nodes, thus enforcing the protocol rules. The ordered set of transactions 154 is then recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 126. A block pointer 155 is also assigned to the new block 151n, pointing back to the previously created block 151n-1 in the chain. A significant amount of effort, e.g., in the form of a hash, required to create a proof-of-work solution signals the intention of the first node 126 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it allocates the same output as a previously validated transaction, sometimes referred to as double spend. Once created, blocks 151 cannot be modified as they are known and maintained at each of the blockchain nodes 126 in the blockchain network 132. Block pointers 155 also impose a sequential order on the blocks 151. This therefore provides an immutable public ledger of transactions as transactions 152 are recorded in ordered blocks at each blockchain node 126 in the network 132.

[0146] Note that different blockchain nodes 126 competing to solve the puzzle at any given time may be doing so based on different snapshots of the ordered set of unpublished transactions 154 at any given time, depending on when they started searching for a solution, or the order in which the transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n, in which order the current set of unpublished transactions 154 is updated. The blockchain nodes 126 then continue competing to create blocks from the newly defined outstanding ordered set of unpublished transactions 154, and so on. There is also a protocol to resolve any "forks" that may arise, which is when two blockchain nodes 126 solve their puzzles within a very short time of each other, such that competing views of the blockchain are propagated between the nodes 126. In essence, whichever prong of the fork grows the longest becomes the final blockchain 150. Note that this should have no impact on users or agents of the network, since the same transactions appear in both forks.

[0147] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 126 is given the ability to allocate the accepted amount of digital assets in a new special type of transaction that distributes a prescribed quantity of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction" but is sometimes 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 constructing the new block to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generating) transaction 152 also specifies 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 commonly referred to as the "transaction fee" and is explained below.

[0148] Due to the resources involved in transaction validation and transaction publishing, at least each of the blockchain nodes 126 typically 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.

[0149] The memory of each blockchain node 126 stores software configured to execute on the processing unit of the blockchain node 126 to perform its respective one or more roles and to process transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed to a blockchain node 126 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0150] Also connected to the network 130 are computing devices of each of a number of parties 103 in the role of consuming users. These users may interact with the blockchain network but do not participate in validating, constructing, or propagating transactions and blocks. Some of these users or agents 103 may act as senders and recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from the blockchain node 126).

[0151] Some or all of the parties 103 may be connected as part of a different network, for example, a network superimposed on top of the blockchain network 132. Although users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network, these users are not blockchain nodes 126 because they do not perform the required role of a blockchain node. 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. Two parties 103 and their respective devices are illustrated for illustrative purposes: a first party 103a and his / her respective computer device 102a, and a second party 103b and his / her respective computer device 102b. The first computing device 102 and the second computing device 104 may be configured to perform any of the functionality of the respective computer devices 102a or 102b. It will be understood that many more such parties 103 and their respective computing 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. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0152] The computing equipment of each party 103 comprises a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing equipment of each party 103 further comprises a memory, i.e., computer readable storage in the form of one or more non-transitory computer readable media. This memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment of each party 103 stores software comprising a respective instance of at least one client application 105 configured to execute on the processing equipment. It will be understood that any action attributed to a given party 103 herein may be performed using software executed on the processing equipment of the respective computing equipment. The computing equipment of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment of a given party 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

[0153] The client application 105 may be initially provided to the computing equipment of any given party 103 on one or more suitable computer readable storage media, for example downloaded from a server or provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive. The client applications 105 correspond to 105a and 105b on devices 102a and 102b shown in Figure 1c, respectively.

[0154] The client application 105 comprises at least a "wallet" function. It has two main functionalities. One of them is to allow each party 103 to create, authorize (e.g., sign) and send to one or more Bitcoin nodes 126 transactions 152 that are then propagated throughout the network of blockchain nodes 126 and thereby included in the blockchain 150. The other is to report back to each party the amount of digital assets that he or she currently owns. In an output-based system, this second functionality comprises reconciling the amounts defined in the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0155] NOTE: Although various client functionalities may be described as being integrated within a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented within a set of two or more separate applications, for example, interfacing via an API or one plugging into the other. More generally, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or a combination of both. While the following is described with respect to client application 105, it will be appreciated that this is not limiting.

[0156] An instance of a client application or software 105 on each computing device is operatively coupled to at least one of the blockchain nodes 126 of the network 132. This allows 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 in which its respective party 103 is a payee (or, in an embodiment, to actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public function that provides trust in transactions, in part through its public visibility). The wallet function on each computing device is configured to organize and send the transactions 152 according to a transaction protocol. As described above, each blockchain node 126 executes software configured to validate the transactions 152 according to the blockchain node protocol and to forward the transactions 152 for propagation throughout the blockchain network 132. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is accompanied by a given node protocol that together implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 126 in the network 132.

[0157] When a given party 103, for example Alice, wants to send a new transaction 152j to be included in the blockchain 150, she organizes the new transaction according to the relevant transaction protocol (using a wallet function in Alice's client application 105). Alice then sends the transaction 152 from the client application 105 to one or more blockchain nodes 126 to which Alice is connected. For example, this may be the blockchain node 126 that is best connected to Alice's computer. When any given blockchain node 126 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This comprises first checking whether the newly received transaction 152j meets some conditions to be "valid", examples of which will be explained in more detail shortly. In some transaction protocols, the conditions for validity may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be specified by a combination of the script and the node protocol.

[0158] On condition that the newly received transaction 152j passes the test to be considered valid (i.e., it is "validated"), any blockchain node 126 that receives the transaction 152j adds the new validated transaction 152 to the ordered set 154 of transactions maintained at that blockchain node 126. Additionally, any blockchain node 126 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 126 in the network 132. Since each blockchain node 126 applies the same protocol, then assuming the transaction 152j is valid, this means that it will soon be propagated throughout the entire network 132.

[0159] Once the ordered sets 154 of transactions maintained at a given blockchain node 126 are approved, that blockchain node 126 begins competing to solve the proof-of-work puzzle on the latest version of their respective ordered sets 154 of transactions, including the new transaction 152. (Recall that other blockchain nodes 126 may be attempting to solve the puzzle based on different ordered sets 154 of transactions, but whoever succeeds first defines the ordered set of transactions to be included in the latest block 151. Eventually, the blockchain node 126 solves the puzzle for the part of the ordered set 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the ordered set 154 that includes the new transaction 152j, it becomes immutably part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer back to an earlier transaction, so that the order of transactions is also immutably recorded.

[0160] Different blockchain nodes 126 may initially receive different instances of a given transaction and therefore may have competing views of 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, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not published in block 151).

[0161] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction specifies the amount to be transferred not by referencing back to the UTXO of a preceding transaction in the sequence of past transactions, but rather by reference to an absolute account balance. The current state of every account is stored and constantly updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called the "position") of the account. This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed in the transaction. This data field may point back to a previous transaction, for example if a previous transaction ID is included in the data field.

[0162] Transactions recorded in the blockchain 112 model transfers of value that are either spent or not spent, and are protected by a locking script. A transaction consumes value through its inputs and pays value forward through its outputs. The value input into a transaction must equal or exceed the value output by the previous transaction, with any excess inputs collected as transaction fees. The solution presented to the locking script, i.e., the unlocking script, is incorrect; if the unlocking script outputs more value than was taken as input, if the unlocking script consumes outputs that have already been consumed, or attempts to consume value that does not exist at all, then the transaction is invalid.

[0163] Both locking and unlocking scripts are expressed in a machine-readable scripting language that allows for a wide variety of scripted consumption conditions, including scripts that can embed arbitrary data (in the form of provably non-consumable output) as data carrier output.

[0164] The payment processing resource 106 in FIG. 1a may be configured to interact with the blockchain 112. This may be in the generation of a blockchain transaction where it may retrieve unconsumed outputs for use as a basis for input to a further blockchain transaction. Upon generation of the blockchain transaction, the payment processing resource 106 may record the generation of the blockchain transaction as an event in a corresponding event stream implemented by the event stream manager 110. Further details of the functionality of the event stream may be found in GB2002285.1 filed in the name of nChain Holdings Limited, GB2020279.2 filed in the name of nChain Holdings Limited, and PCT / IB2021 / 051261 filed in the name of nChain Holdings Limited.

[0165] The payment processing resource 106 in Figure 1a is configured to interact with a key storage module 122 and a payment data store 124. The key storage module 122 is configured to store cryptographic keys corresponding to the accounts of parties using the payment processing resource 106 to enable transactions to take place. The key storage module 122 may utilize any suitable storage and utilizes a database management system (DBMS) to initialize, store, and retrieve data from the internal database records of parties that store cryptographic keys in the key storage module 122. The payment data store 124 is configured to store data related to any payments made using the payment processing resource 106.

[0166] Interactions between each computing device and the payment processing resource 106 may be determined according to an authorization data structure generated by the payment processing resource 106 .

[0167] We now describe the concept of an authorization data structure that relates to the authorizations associated with a user of the payment processing resource 106. Authorization provides a way to identify a user and the state of what that user can do. The identity aspect is conveyed through the use of public key cryptography, and aspects related to the authorization of that user are managed through the use of permissions.

[0168] Permissions provide a way to identify a user and the state of what the permission holder can do. The identity aspect is conveyed through the use of public key cryptography, and "what the holder can do" is conveyed through the use of permissions as described herein.

[0169] In one embodiment, each permission has an associated permission data instance (also described as associated permission data, or permission data). The permission data instance comprises the permission itself as well as data about the permission that describes what the holder of the permission can do. Optionally, each permission comprises at least one permission, and more optionally, multiple permissions. The permission is configured to determine what the holder of the permission can do. Optionally, the permission is defined by a name-value pair (also called a key-value). Optionally, the name is a string of characters. More optionally, the string of characters is human readable and provides an indication as to what the permission pertains to. Optionally, the value is a string, number, or data structure, where the data structure is one or more pairs of name and value. The permission is optionally of a form as described in more detail below under the heading "Permissions". When referring to a permission comprising one or more permissions as used herein, this optionally refers to the permission data instance comprising the name and value permissions. Permissions are optionally provided in sets or groups (called permissionSets in one example described herein). Optionally, groups of permissions are part of each permission as an "extension."

[0170] Each permission also comprises data such that the identity of the permission holder can be verified. Optionally, the permission comprises a public key associated with the permission holder. Verification of the permission holder's identity can be determined by the holder signing a message (or any data) with their private key, and then a party verifying the permission holder's identity can compare the signature and message against the public key associated with the permission holder. Optionally, the public key associated with the permission holder is stored in the associated permission data instance.

[0171] Optionally, each permission is identified by a permission identifier. Optionally, the permission identifier provides no indication as to the contents of the permission. Optionally, the permission identifier is a pseudo-randomly generated string.

[0172] In one embodiment, the system verifies the signature of a user against their permission, thus providing a way to verify that a user is or is not the holder of a permission.

[0173] Optionally, a permission is part of a hierarchy. Referring to Fig. 1d, a hierarchy 200 of permissions is illustrated. Every permission (except for the root 202) has a parent permission and optionally one or more child permissions. Optionally, a child permission cannot have more than one parent. The resulting permission hierarchy is a tree. A parent permission can create a child permission.

[0174] Optionally, a permission is provided with a set of rules that allow a permission holder to create child permissions that contain the permission within a given "domain" or "namespace" without traversing other domains or namespaces. The use of these namespaces prevents separate organizations from interfering with other organizations that use the permission system. The set of rules can be found in special permissions, as described below.

[0175] Additionally, the set of rules allows delegation of capabilities to child permissions, granting the child permission the right to create grandchildren recursively downward within a domain or namespace, subject to optional depth and total count limits.

[0176] The top-level root permission 202 has the capability to create a large, even unlimited, number of child permissions with almost no limit. With such a wide range of capabilities, the private / public key pair used in the creation of the root permission is optionally managed securely. Optionally, the private key associated with the root permission is kept offline on a secure device.

[0177] Creating a top root permission 202 (as opposed to organization-level root permissions 206, 208, 210) is a one-time process. The method is similar to creating a child permission, except that there is no parent permission to reference, and therefore all checks related to checking parent permissions, authentication, authorization, and other functions are skipped or otherwise ignored. In this embodiment, this is optionally done only once and never again.

[0178] In the exemplary permission hierarchy 200 of FIG. 1d, there are four different organizations using permissions. nChain™ is the root permission holder, and Org ABC, Org PQR, and Org XYZ are all using permissions that are children of nChain's permission. Those skilled in the art will appreciate that specific companies are used merely as examples. Furthermore, there may be any number of organizations in such a permission system. The exemplary hierarchy and organizations shown in FIG. 1d illustrate the flexibility of permission construction when using some of the present embodiments described herein.

[0179] Continuing with the example, Org ABC has an organization level root permission 206. This is a root permission in that it is the root of permissions for Org ABC, rather than a top level root 202 for the overall tree. Org ABC has created at least two child permissions 212, 214. These child permissions are for different customers and / or end users.

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

[0181] In one embodiment, the holder of a root permission creates several child permissions 204 with the same holder. These child permissions are configured so that they can create further child permissions 206, 208, 210 for other users of the system. In this way, the top-level root permission 202 does not need to be used to create further permissions each time a new user or organization desires a permission, thus reducing the opportunities for attacks and improving the security of the root permission.

[0182] Optionally, every permission includes a reference to its parent, and one or more named permissions. At creation time, the parent provides data indicating the set of permissions, and a public key (holderPubKey) associated with the permission holder. Permissions are stored by default under the extension["default"] object, as can be seen in the example permission data instance below.

[0183] Optionally, the permission information is tracked in a data structure called a permission data instance or permission data. The data structure comprises at least some of the following elements, presented in the table below. Optionally, all of the elements are required. Some of the values ​​for the elements can be set to null, 0, or are zero length. More optionally, a parent is required and is not null.

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

[0185] Optionally, determining whether a permission is revoked depends on the current time. Each permission comprises a "revoked" element comprising a time. For a permission to be considered for revocation, the current time must be after the revoked time stored for the permission. More optionally, and according to a further embodiment, a method is provided in which a time in the future is provided to the permission, and the permission returns whether the permission is valid at that time.

[0186] Optionally, named permission maps are referenced by their name in the extension map. When storing the initial extension, the name "default" is used.

[0187] Alternatively, no extension map is used and only one set of permissions is associated with a grant.

[0188] An example authorization data instance with all of the elements used (although some are set to null) is shown below in JSON format: { "parent": "<instanceId of parent> ", "extensions": { "default": { "holderPubKey": "12c6DSiU4Rq3P4ZxziKxzrL5...", "revoked": null, "permissionSet": { "$.children.namespace": [ "com.example.user", "com.example.country.uk" ], "$.children.levels": 2, "$.children.max": [10, 10], "$.extensions.max": 2, "$.root": false, "$.valid.after": "2021-11-16T10:30:05Z", "$.valid.before": "2022-11-16T10:30:05Z", "com.example.distributor": { "id": " <uuid>", "name": "uk321" } } }, }, "children": [ "<instanceId of child 1> ", "<instanceId of child 2> ", ], "revoked": null, }

[0189] Those skilled in the art will appreciate that the above are exemplary permissions, and that some features of this permission data instance may be removed, not used, or modified depending on the particular embodiment described herein. Those skilled in the art will further appreciate that JSON is provided here as an example of representing permissions. Permissions and their contents may be represented using other formats, such as XML, binary encoding format, or any other suitable format.

[0190] Referring to FIG. 1e, a simple example (with the farthest top-level root permission omitted) is illustrated, where an organization root permission 302 has at least two child permissions 304, 306. The organization is the NBW (National Bureau of Waterways) which issues fishing permits 304, 306 (limited to anglers in this example). Optionally, the NBW provides a mobile application that holds an identifier to the holder's permit, and a secret key that allows the holder of the permit to verify that the holder holds the identifier to the holder's permit. Each angler permit 304, 306 has a permission called "org.nbw.angler.rights" and optionally has the following structure: { "type": "rod", "species": ["carp", "tench", "pike"] }

[0191] Optionally, other permissions are associated with personal identification information such as a membership number and the user's name.

[0192] In use, a fishing inspector wanting to verify that a user (such as Fred Bass holding the first child permission 304) is fishing with the right type of equipment and catching the right type of fish may use this permission to do so. The inspector can use the permission identifier (optionally obtained via a QR code from Fred Bass' phone). Using this permission identifier, the inspector can query the permission instance itself to verify both the permissions (such as Fred Bass is using a fishing rod and has only caught carp, tench, or pike) and the identity (such that Fred is actually the holder of the permission and has not copied someone else's permission identifier).

[0193] permission Optionally, permissions are namespaced. More optionally, permissions are namespaced by restricting what the names in the name-value pairs can be. These namespaces use a structure like inverted DNS domains, separated by "." (full stop). Some example namespaces are: com.example.user.id com.example.user.type com.example.acme.user.id org.nbw.angler

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

[0195] Optionally, both the name and the value of these permission name-value pairs are customizable (as long as the name is within the allowed namespace of the parent permission). Optionally, both the name and the value can be any arbitrary value. Optionally, both the name and the value are provided by a user of the permission system; thus, the names and values ​​are user-generated. By providing user-generated and / or customizable names and values, the use cases for the permissions can be extremely flexible, thereby enabling their use in many different applications.

[0196] Optionally, the namespace can only be longer. This can also be understood as saying that the permissions of a child permission can only be a subset of those allowed according to the parent permission. Optionally, the namespace allows the permissions to be structured hierarchically (this is in addition to, and separate from, but often consistent with, the permissions also being hierarchical).

[0197] Optionally, the permission hierarchy follows the same structure as the permissions, which can also be understood as each child permission having permissions that are a subset (per namespace) of the parent.

[0198] A special set of permissions, prefixed with the "$" namespace, provide information and / or limitations about the permission itself. The "$" namespace provides limitations on what permissions these permissions can add to child permissions. These limitations are: Enforcing one or more namespace prefixes on all permissions in the children, Delegation of rights to create further permissions to children recursively to a given depth, Limiting the number of children and further offspring that may be produced; and / or This may include limiting the number of extensions (discussed below under the heading "Extensions") that may be created.

[0199] Alternatively, the information stored in these special permissions (i.e., the permissions and other information limitations) is not stored in the special permissions, but instead is stored on the permission data instance. Optionally, each of the limitations is stored as its own element on the permission data instance. Those skilled in the art will appreciate that these limitations may be stored in any number of different locations associated with the permissions.

[0200] Optionally, the "$" namespace is also used to specify the validity period of the permission.

[0201] [Table 1]

[0202] The special ($) namespace does not have to adhere to the "$.children.namespace" convention as described above. Optionally, only a specific set of special permissions can be created. More optionally, the above set is just the special permissions a permission can have.

[0203] Optionally, the $.valid.after and $.valid.before permissions use local time. Optionally, the permission is optional and not required. Optionally, $.valid.after and $.valid.before specify the validity period of the permission and / or extension. Optionally, if a parent has either the $.valid.after and $.valid.before permissions set, any child created from it must inherit the same or a narrower time window. Thus, it can be seen that the validity period of a child's permission cannot exceed the validity period of its parent's permission.

[0204] These special permissions are optionally stored in the initial / default extension only if they refer to the permission as a whole. Any special permissions stored in a different extension are either ignored or denied.

[0205] Referring to the previous example of FIG. 1e, the NBW root permissions 302 comprise at least the following permissions: $.children.namespace = "org.nbw" $.children.levels = 1

[0206] These permissions state that the holder of the NBW root permission 302 can create as many child permissions as needed, as long as the child permissions start with "org.nbw" and the children are only one level deep.

[0207] Referring to FIG. 1f, a further exemplary permission structure 320 is now shown. The structure is similar to that described with reference to FIG. 1e. The NBW root permission 302 has their "$.children.levels" permissions equal to (or greater than) two. In this example, the NBW permission 302 holder wants to enable clubs to create permissions for their own members. The NBW permission 302 creates a club permission BLFC 322 (Big Lake Fishing Club) with the following permissions: org.nbw.club.id = "BLFC" $.children.namespace = "org.nbw.angler" $.children.levels = 1 $.children.max = 50

[0208] These permissions allow the BLFC to create up to 50 permissions for its members, but only those permissions that are in the "org.nbw.angler" namespace. Thus, a permission like "org.nbw.club.id" is not allowed for any child, so a child cannot be prevented from impersonating the club permission (e.g., if a child's permission has a permission "org.nbw.club.id", then the child can pretend to be the club itself and propagate any action related to the club), or any other similar permission.

[0209] The BLFC permission 322 creates at least two child permissions 324, 326. These child permissions have permissions that are prefixed with "org.nbw.angler".

[0210] Extension Optionally, permissions are stored in "extensions". Optionally, extensions comprise sets of permissions (called permissionSets), a revocation element, and a holderPubKey element. Extensions are stored on authorization data instances in an extension map and referenced by a name. Optionally, the name is user generated. Optionally, the name is human readable. Optionally, the initial extension and / or the default extension is labeled "default". Here, human readable is any encoding that can be naturally read by a human. Optionally, the encoding is ASCII text or Unicode text.

[0211] The extension optionally 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.

[0212] Each extension comprises several elements. Exemplary elements of an extension are provided below in Table 2. Optionally, all of them are required.

[0213] [Table 2]

[0214] Those skilled in the art will appreciate that strict adherence to the structure and format of extensions and the way they are stored is not necessary. Alternative structures may be possible for the collection of extensions and / or permissions. An exemplary alternative may be that extensions do not have to be strictly stored in an extension map, but may be stored in a list or other suitable data structure. Extension objects as described herein may also alternatively have a different structure in that they merely comprise a list of permissions or a list of permission references, with the permissions themselves being stored elsewhere in the permission.

[0215] Extensions may be used to add or replace permissions during the lifetime of a permission. Extensions may be added or overridden by a parent permission. Optionally, all permissions added to a permission are signed by the holder of the parent permission.

[0216] In one embodiment, the extension allows a permission holder to associate different devices with a permission. For example, if the permission is for access to a particular resource (optionally a computing resource), a single permission holder may have an "iPhone" extension to manage their iPhone's interaction and a "desktop" extension to manage their desktop computer's interaction with the computing resource. As mentioned above, it is possible to disable the extension. Advantageously, if a user were to lose their iPhone, they could contact their permission provider (which has control over the parental permission that created this user's permission) and disable the iPhone extension without affecting the interaction of the user's other devices with the service. Thus, it can be seen that the extension system provides improved flexibility and control when it comes to providing / removing access to resources. This, together with the lack of central control of permissions and / or certificate revocation lists, can save computing resources when it comes to enabling permissions in the associated extensions by not needing to distribute and maintain such lists.

[0217] Interaction with Authorization As explained above, the authorization system described herein optionally interacts with using requests. Optionally, the requests are HTTP requests. More optionally, the requests are sent to a REST endpoint. There are two relevant REST endpoints: ... / send to request actions against the permission, including creating and disabling children, and There is a ... / query to check the validity and permissions of authorizations.

[0218] Optionally, some interactions require that requests be accompanied by a signature, so organizations wishing to interact with their grants for creation, revocation, or other interactions must have a public key / public key pair set up. Any requests must also include the instance id of the grant in question. The instance id and public key can be publicly seen or known, but the private key must be kept secret.

[0219] Sending requests to these endpoints can also be described as "invoking" them as they are presented as RESTful APIs. Thus, the sender of the request can also be considered the "invoker."

[0220] Optionally, any requests sent to the "... / send" endpoint are logged. Optionally, logging is done to a blockchain allowing requests to be audited by a third party. Optionally, any requests sent to the "... / query" endpoint are not logged.

[0221] In one embodiment, the interactions are logged on the blockchain, or at least a subset of the interactions are logged on the blockchain. Optionally, all of these interactions are logged off-chain, and a subset of the interactions are logged on the blockchain. Optionally, the interactions are logged into a set of interactions, where each set of interactions pertains to a single permission. Each set of interactions also has an associated representation on the blockchain (through the use of a transaction). Thus, an auditor wishing to track interactions with a permission of interest can audit only the set of interests.

[0222] Optionally, each interaction logged on the blockchain comprises an immutable reference to a previous interaction (optionally also stored on the blockchain). Optionally, the reference is a hash of the previous interaction. Optionally, every interaction comprises a reference to the previous interaction, thus establishing an immutable chain of all interactions. Thus, the immutable log only requires that a subset of interactions be recorded on the blockchain. Optionally, only the first and last interactions are recorded on the blockchain.

[0223] Optionally, logging is conveyed using an event stream on a per permission basis. Optionally, there is a logging service that is interacted with through an API to provide the logging implementation. The event stream is PCT / IB2021 / 051258, filed on February 15, 2021 by nChain Holdings Limited; PCT / IB2021 / 051260, filed on February 15, 2021 by nChain Holdings Limited; and This document is described with reference to PCT / IB2021 / 051333, filed on February 17, 2021 by nChain Holdings Limited.

[0224] Optionally, data indicating any interactions with the permission is sent to an event stream through use of the event stream API. Optionally, the event stream API is a RESTful API. The current state of the permission can be verified by going through all of the interactions with the permission (including its creation) and recreating a "dummy permission" by replaying / telling all the interaction steps (this can also be represented as a "dry run" in that no new permission is actually created). The final state of the "dummy permission" should have the same current state as the real permission. The same applies for verifying any intermediate states of the permission, where said intermediate states are known.

[0225] Thus, it can be seen that through logging interactions with the authorization, the state of the authorization is logged, and thus the current or any previous state is auditable and verifiable. By submitting these state changes to the blockchain via an event stream, the authorization becomes auditable and verifiable persistently and with high confidence in data integrity.

[0226] Some example requests to an endpoint might have the following capabilities in the header: POST https: / / {AWS ID}.amazonaws.com / api / v1 / processInstance / {instance ID} / send or POST https: / / {AWS ID}.amazonaws.com / api / v1 / processInstance / {instance ID} / query

[0227] where {AWS ID} is the id of the AWS™ endpoint and {instance ID} is the authorization identifier. Those skilled in the art will appreciate that other URLs and services may be used. For example, non-AWS URLs may be used. Those skilled in the art will appreciate that the requests provided herein are exemplary and may take different forms. The request is illustrated as having a URL to which the request is being sent. Optionally, the method does not provide a complete URL, only a path.

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

[0229] Optionally, the body of the POST should be a JSON object containing a single property named for the message or interaction being sent. Optionally, authentication and authorization for the request is conveyed by signing the parameters with the sender's private key and placing the result in the signature property of the request. For example, { "createChild": { "permitContents": "<stringified JSON object> ", "signature": "<base64 signature over permitContents> " } }

[0230] Note that the part of the request being signed needs to be sent as a string representation of the request contents, not the JSON object itself. This is to ensure that both the request sender and the request receiver use the same representation of the object (regardless of spacing, ordering, etc.) to compute the signature. As an alternative to stringifying, a canonical structure of the object can also be used. This canonical structure is optionally specified according to RFC8785. The canonical scheme is a scheme that is agreed upon by both the sender and receiver. The scheme may be agreed upon in advance, or the scheme is identified by the sender so that the receiver understands which scheme is in use.

[0231] Optionally, a response to the above request is provided with a result characteristic and an optional message. For example: { "result": "ok", "msg": "Success! Permit created", ... } { "result": "error", "msg": "Invalid parameters", ... }

[0232] The exact content of the message (msg) depends on the context of the request and how it is processed.

[0233] Below, several different embodiments are presented that represent different interaction permissions. Optionally, any number of these embodiments may be used with any number of different other embodiments. Those skilled in the art will appreciate that in every conceivable system, some embodiments may not be used. For example, extensions may not be used, and therefore any interactions related to creating or disabling extensions may not be used.

[0234] Each authorization data structure may be stored in an authorization data store 180, which is accessible to the payment processing resources 106 by suitable API or other means. The authorization data structures are stored in the authorization data store 180 in any suitable manner, such that an authorization identifier may be used to identify the authorization. This allows other elements of the authorization data structure to be accessed, for example, during cryptographic signature checking.

[0235] The payment processing resources 106 allow a user to establish an instance of the payment processing resources 106 that the user can use to manage an account, as will now be described with respect to Figure 2. The instance of the payment processing resources 106 is used to manage activity surrounding assets managed by an account established on the payment processing resources 106, in accordance with the process described in GB2109064.2, filed on June 24, 2021 in the name of nChain Licensing AG.

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

[0237] The first computing device 102 begins the process of establishing an instance of the payment processing resource 106 by generating an API call to an endpoint of the API 108 that corresponds 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 to the first computing device 102 by the payment processing resource 106.

[0238] The payment processing resource 106 may be associated with a stringified JavaScript Object Notation (JSON) object that may have elements corresponding to identifiers for assets managed by the corresponding account, i.e., an identifier for the account administrator, an identifier for the account administrator's authorization data structure, an identifier for the account holder's authorization data structure, an identifier for the account's guarantor (e.g., this may be a customer of the bank), expressions and terms and conditions to allow expressions in the account holder's authorization to be checked (including a uniform resource location to allow the terms and conditions to be retrieved, a hash of the terms and conditions, and a cryptographic signature of the account holder), configuration parameters (e.g., minimum and maximum balance settings), settings for how numbers are controlled, and spending limits for the corresponding funding account.

[0239] The authorization data structures for the account administrator and account holder may be structured as described above, with various permissions provided, which may be cryptographically verified by the payment processing resource 106 using the authorization data structures.

[0240] The payment processing resources 106 respond by requesting data corresponding to elements used by the corresponding instance of the payment processing resources 106. This is step S202.

[0241] The first computing device 102 then provides the respective elements used by the payment processing resource 106 to establish an instance of and interact with the payment processing resource 106 required by the corresponding user, which is step S204.

[0242] In establishing an instance of the payment processing resources 106, the payment processing resources 106 effectively create a profile for the user, identified by an instance identifier (their creation and use are described below). This means that when the payment processing resources 106 are accessed using the identifier, the payment processing resources 106 can determine which files to access and also determine the appropriate allocation of resources (i.e., memory, directories, and registers) to the activity on that instance. The payment processing resources 106 can run, access, and utilize each instance separately. If the payment processing resources 106 are implemented through cloud-based resources, the instances of the payment processing resources 106 may be implemented using corresponding software that runs through the necessary hardware across the cloud infrastructure. This allows resources to be appropriately allocated by the payment processing resources 106 to any one instance.

[0243] Upon receiving each element, the payment processing resource 106 processes the required elements and validates the data provided in support of the account holder and account administrator authorizations. In doing so, the payment processing resource 106 obtains the public keys corresponding to both authorizations. The payment processing resource 106 also obtains identifiers for both authorizations and checks the validity of the representations for both authorizations. This is step S206. This is by reference to the authorization data structure corresponding to each authorization. The cryptographic signature in the terms and conditions is also checked by reference to the account holder authorization data structure. This may be checked using the methods described above, where the terms and conditions and the cryptographic signature are provided to the authorization data store 180 along with a request for the cryptographic signature to be verified against the corresponding authorization data structure. The cryptographic signature is then verified using known techniques, for example based on the Elliptic Curve Digital Signature Algorithm (ECDSA) or Rivest-Shamir-Adleman (RSA) approach to digital signature generation and verification. If the signature provided in the request is successfully verified, the digital signature is accepted as valid. If not, a rejection message may be issued.

[0244] Identifiers for the assets and account administrator are then recorded in an instance data structure 170 created for the instance. Identifiers corresponding to the permissions for the account holder and account administrator are also recorded in the instance data structure 170. This is step S208. The instance data structure 170 comprises any suitable data structure necessary to provide access to the identifiers for the account holder and account administrator. The instance data structure 170 may be accessed by the payment processing resources 106 using any suitable means, such as by additional APIs or by a data communications network.

[0245] The balance for the corresponding funding account is also set to 0, 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 a message for that account is being received by the user, 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 may be saved for further interaction with the payment processing resource 106. This is step S212. The instance identifier may also be used by other users if they need to interact with the corresponding instance of the payment processing resource 106. The provision of 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 for the assets identified in the information provided in step S204. The provision of the instance identifier to the first computing device 102 also triggers the generation of parameters required for the allocation of resources to the corresponding instance of the payment processing resource 106. Upon completion of the creation of an instance of the payment processing resource 106, the payment processing resource 106 interacts with the event stream manager 110 to initialize an event stream corresponding to the instance of the payment processing resource. This is step S214. The event stream is used to record all history related to the corresponding funding account. Only read and append operations can be performed on the event stream.

[0246] Initialization of an event stream may comprise the setup and configuration of computing resources and data structures required to implement a particular event stream. Alternatively or additionally, completion of the creation of an instance of the payment processing resources 106 may result in accessing a pre-existing event stream. Accessing the pre-existing event stream may also comprise appending an entry to append data that confirms that the instance of the payment processing resources 106 has been established. The pre-existing event stream may be an event stream that includes entries for all instances of the payment processing resources 106. The pre-existing event stream may also be an event stream that synchronizes each of the other event streams into a single event stream that is also managed by the event stream manager 110. Additional details of the functionality of the event stream may be found in GB2002285.1 filed in the name of nChain Holdings Limited, GB2020279.2 filed in the name of nChain Holdings Limited, and PCT / IB2021 / 051261 filed in the name of nChain Holdings Limited.

[0247] Establishing an instance of the payment processing resources 106, and providing an instance identifier, enables a device, such as the first computing device 102, to interact with the instance of the payment processing resources 106. Other devices aside from the first computing device 102 may also interact with the created instance, provided they are permitted to do so by an authorization data structure, as described below.

[0248] In a first example of an interaction between a computing device and an instance of a payment processing resource 106, the following describes how a first computing device 102 may utilize the API 108 to initiate a session with the instance of a payment processing resource created in steps S200-S214. As described below, the session may then be used to enable other interactions with the instance.

[0249] In particular, with reference to FIG. 3, we will explain how a first computing device 102 may obtain a session key to enable interaction with a funding account associated with an instance of a payment processing resource 106.

[0250] In step S300, the first computing device 102 issues a call using the API 108 to request a session with an instance of a payment processing resource 106. This utilizes a session endpoint for the API 108. The API call to request the session passes an instance identifier (associated with the respective instance of the payment processing resource 106) to the session endpoint to initialize a session with the instance of the payment processing resource 106. The API call also includes instruction data, including a timestamp identifying the time the call was made. The instruction data may also comprise a time period during which the session may be utilized (and essentially the period during which the corresponding session key is to be used), and a flag identifying whether the instruction is coming from an account administrator (set to false if the instruction is coming from an account holder).

[0251] The instruction data may also include data, including an authorization identifier that identifies the authorization data structure, and credentials in the authorization data structure that may indicate authorization of the first computing device 102 to access the event stream. Validation of such credentials is described later in the context of how to validate a data item. Such credentials may also be described as permissions in the authorization data structure. The instruction data may also include a public key that corresponds to the authorization data structure.

[0252] 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.

[0253] The instruction data also comprises a cryptographic signature from an account holder corresponding to the 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 included with the instruction data. The cryptographic signature may be generated using Elliptic Curve Digital Signature Algorithm (ECDSA) techniques using a private key associated with the account holder authorization data structure. Alternatively, the signature may be generated using RSA-based techniques.

[0254] 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 if 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 from the current time. If the timestamp is more than one minute away from the current time, the request for the session is rejected. If the timestamp is one minute or less from the current time, the request for the session is approved. The time period does not have to be one minute from the time indicated by the timestamp. For more security conscious applications, the time period can be much shorter than one minute, but for less security conscious applications, it may be longer.

[0255] By checking the current time against the time indicated by the timestamp to determine how long since the request was made, the payment processing resource 106 can prevent replay attacks.

[0256] The time period (sometimes called the session period) is also checked by the payment processing resource 106 to determine the time during which the session is likely to be in use. The time period is usually expressed in terms of seconds or minutes, but may be expressed as a range of dates during which the session is expected to be in use.

[0257] In step S304, the payment processing resource 106 issues a request to the authorization data store 180 for the cryptographic signature (contained in the instruction data) to be verified. This may be through a separate API or through a message sent to the authorization data store 180 over a telecommunications network. Alternatively, the authorization data store 180 may be local to the payment processing resource 106 in that it occupies the same localized group of hardware resources. The request includes 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 particular instance of the payment processing resource 106 that is making the verification request, and may also include a string that identifies the device that was the source of the request. For example, if the request was made from an Apple iPhone, the string may be "iPhone". This string may be provided in the instruction data or may be extracted from the instruction data by the payment processing resource 106. The reference used by the particular instance may be an event stream index to the request made in step S300. This is advantageous in that it helps to verify the state of the authorization data structure in combination with the state of the associated event stream (i.e., the event stream generated for the instance of the payment processing resource 106) at the time the request was made. That is, it can help to verify that the authorization data structure produced the correct response given its current state when the request was made to verify the cryptographic signature. The request also comprises an instance identifier for the respective instance of the payment processing resource 106, and additionally comprises an authorization identifier to enable the authorization to be identified by the authorization data store 180.

[0258] The permission data store 180 then performs a check against the record corresponding to the permission identified by the permission identifier. This is step S306. If a cryptographic signature is found in the permission data structure corresponding to that permission, the check returns a confirmation. This involves verifying the signature using standard ECDSA or RSA signature verification techniques. The generated signature is compared to the cryptographic signature provided in the instruction data. This is step S308. If the cryptographic signatures do not match, the check returns a denial. This is step S310 and the request fails or is no longer processed. If a flag that identifies whether the instruction is from an account administrator is set to true, the public key used to verify the signature is from the permission data structure owned by the account administrator.

[0259] If the check returns a confirmation, i.e., the signatures match, the requested session duration in step S300 is then compared by the payment processing resource 106 to the maximum duration set by the payment processing resource 106 for a session with the corresponding instance of the payment processing resource 106. This is step S312. If the session duration is less than the maximum duration set by the payment processing resource 106, the payment processing resource 106 generates a session key (also called a session token) for the requested session having the requested session duration. This is step S314. The session key is generated by the payment processing resource using any suitable technique. It may be generated using a public key corresponding to the authorization found in the authorization data structure. The session key may be generated using a hierarchical key generation technique that uses a public / private key pair associated with the account holder authorization as a base key. The session key may then be returned to the first computing device 102 with a message that the session has been initialized. The session key may then be used with the instruction data for further requests that require interaction with the event stream. However, the session key can only be used for the duration of the requested session.

[0260] If the comparison in step S312 returns a result indicating that the session duration is longer than the maximum duration or shorter than the minimum value also set by the instance of the payment processing resource for a session involving the payment processing resource 106, the payment processing resource 106 does not generate a session key and the request fails, i.e., is no longer processed.

[0261] Alternatively or additionally, if the cryptographic signature is verified but the requested session duration is less than the configured minimum for a session involving an instance of the payment processing resource 106, the payment processing resource 106 may generate a session key and increase the allowed session duration to the minimum.

[0262] Upon generation of the session key, the payment processing resource 106 may retrieve the balance from locally maintained storage. Optionally, the payment processing resource 106 may also issue a query to the event stream manager 110 for a continuous log of transactions from the event stream corresponding to the funding account associated with the instance of the payment processing resource identified by the instance identifier. The query may return a partial or complete version of the event stream that provides 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 where the event stream manager 110 returns all entries between those dates. 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.

[0263] The event stream manager 110 generates a timestamp for the query and an index into the event stream, which is step S318. In response to the query, an entry may be added to the event stream by the event stream manager 110.

[0264] The balance (if obtained), the timestamp, and the index of the event stream are then returned to the first computing device 102. This is step S320. The session key may then also be transferred to the first computing device 102 in step S320.

[0265] The first computing device 102 can then use the session key to request read-only data from the 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.

[0266] This may be part of a request to see the state of an account tracked by an event stream, or to get information about the history of said account. A request to get information about history may request transaction details specified by a date range, an index range, or even a hash of the respective transaction data. The request may also be for the entire transaction history.

[0267] That is, the computing device may interact with an instance of the payment processing resource 106 using the instance identifier and then obtain the read-only information from the associated event stream. Alternatively, the computing device may interact with an instance of the payment processing resource 106 to generate a session key, which may then be used during further interactions with the event stream. Upon making a request, the authorization data structure corresponding to the provided cryptographic signature is verified using the authorization data structure, and the request proceeds only if the cryptographic signature is verified. The use of the authorization data structure to verify the cryptographic signature and determine that the session duration is neither too short nor too long serves as a protocol for determining the acceptability of a message, and in particular, a request to obtain read-only data regarding the event stream associated with an instance of the payment processing resource. The user of the first computing device 102 can only access the read-only data if the session can be authorized, and the session can only be authorized if the requirements of the protocol, i.e., the presence of a signature and the length of the session duration, can be met. Authorization of the session comprises the provision of a session key to the requesting user. When a user request accesses the corresponding event stream, the user may sign the instruction data with a session key, and the signature may be checked by the payment processing resource 106. The payment processing resource 106 may determine that the protocol described above is required based on the received API call from the first computing device, in that it may provide a parameter that identifies the type of request being made. Alternatively or additionally, if the first computing device 102 provides the request over a data communications network, the message may provide a parameter that identifies the particular type of request.

[0268] 4a, it will now be described how a first computing device 102 may interact with an instance of a payment processing resource 106 during a transfer of funds from a funding account associated with one instance of a payment processing resource 106 to another instance of the payment processing resource 106, which results in the transfer being recorded on an associated event stream.

[0269] In step S400, the payment processing management module 195 generates instruction data for a payment of 5 GBP from Alice to Bob. The instruction data is generated from payment metadata received from Alice (perhaps using the first computing device 102 or the second computing device 104) indicating the amount Alice wishes to pay Bob, an instance identifier for Alice's instance of payment processing resource 106 (the instance corresponding to the funding account from which Bob is to be paid), the currency in which Alice wishes to pay (i.e., GBP), an identifier for Bob, and an identifier of the instance of payment processing resource 106 associated with Bob's funding account, which for simplicity is a GBP account managed by the same account administrator as Alice. The generation of the instruction data comprises a combination of the payment metadata received from Alice and information related to Bob's funding account.

[0270] The payment processing management module 195 then makes an API call using the API 108 for the update to Alice's balance, which may be understood as a request to debit 5 GBP from Alice's funding account and credit the amount to 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. In 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 comprise a transaction identifier (which may be generated from a hash of the instruction data in the same step) and other information (which may be referred to as one or more tags) that may be used in the transaction. The tag is included in the event stream entry when the transaction is completed, and information about the transaction is added to the event stream. The tag may state, for example, "Debit Alice -5 GBP" and / or "Pay Bob 5 GBP". The API call also includes a cryptographic signature from Alice's and Bob's accounts, which may be generated using ECDSA (or RSA) techniques using private keys corresponding to Alice's and Bob's authorization data structures.

[0271] The transaction identifier uniquely identifies the funds transfer and may be formed using a Secure Hash Algorithm (SHA) 256 hash of the instruction data. The tag may comprise information that is also used in the event stream entry when the transaction is appended to the event stream. The tag may be formatted as an array of strings, with each string comprising an alphanumeric string of characters.

[0272] 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 wishes to participate in a transaction with Bob, i.e., that the transaction will be processed.

[0273] 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. The instructions identify (from Alice's account) the account administrator, an identification of the asset (i.e., GBP), the value being transferred (i.e., 5 GBP), an identifier for the funding account (which may be distinct from the instance identifier), an alphanumeric string containing a reference to the transaction (i.e., the payment to Bob), a time limit for the transfer of funds, and a response data structure, further described below. The instructions also identify (from Alice's account) the terms of the transaction agreed to by Alice when her funding account was created, a cryptographic signature over the terms of the transaction agreed to by Alice, and a uniform resource locator for those terms of the transaction.

[0274] The instructions also identify (from Bob's account), the account administrator, an identification of the assets (i.e., GBP), the value being received (i.e., 5 GBP), an identifier for Bob's funding account (which may be distinct from the corresponding instance identifier), an alphanumeric string containing a reference to the transaction (i.e., the payment from Alice), a nonce for the transaction, and a challenge data structure, also described further below. The instructions also identify (from Bob's account) the terms of the transaction agreed to by Bob (upon creation of Bob's funding account), and may also include a cryptographic signature over the terms of the transaction agreed to by Bob, and a uniform resource locator for those terms of the transaction.

[0275] The payment processing resource 106, as the resource orchestrating the transfer of funds between Alice and Bob, may dynamically manage the transfer of funds as described below, in that it manages the credentials provided by both Alice and Bob and interaction with authorization data structures and event streams, without the need for storage of instruction data.

[0276] Optionally, the instructions may be stored by Alice's instance of payment processing resources 106 as a pending transaction in storage for that instance, which may be identified by the transaction identifier generated in step S402. The instructions may also be stored by Bob's instance of payment processing resources 106 as a pending transaction in storage allocated for that instance.

[0277] Parsing the data received in the API call also retrieves an instance identifier for the instance of the payment processing resource associated with Alice's funding account, which is then used in step S406 to retrieve instruction data associated with Alice's funding account. These instructions form constraints on the funding account and limits on transactions that may be completed using the funding account.

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

[0279] The instruction data relating to Alice's funding account may also comprise a response data structure, the use of which is described next.

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

[0281] Processing of the parsed data then enables the payment to be processed by the payment processing resource 106 using the response data structure and the challenge data structure. The parsed data is then passed to the payment protocol module 120 for processing of the requested payment. The payment processing resource 106 may be able to determine that the payment protocol module 120 is required and a payment processing protocol is required based on parameters provided in the initial API call. Alternatively, the particular protocol may be identified in the instruction data. Alternatively, the particular protocol may be identified by parameters in the request sent over the data communications network.

[0282] The payment protocol module 120 applies a payment processing protocol to the parsed data to determine whether Alice has permission to make the payment and whether the payment can be made independent of authorization from Alice's authorization data structure, which is step S408.

[0283] The first step in the application of the payment processing protocol is to determine whether the command is properly authorized. This is accomplished by determining whether the command comes from the account holder or the account administrator. In this example, the command comes from Alice, so it is the account holder who is providing the authorization. This can be verified using the instance data structure 170, in which an instance identifier corresponding to Alice's instance of the payment processing resource 106 is stored. The payment processing protocol then determines the validity of Alice's signature. This is performed using Alice's authorization data structure. The payment protocol module 120 issues a request to the authorization data store 180 for the validity of Alice's signature to be checked. This is step S410. The request identifies the authorization using the authorization identifier provided by Alice in the command data. The authorization identifier may also be obtained from the authorization store maintained by the payment processing resource 106. The request receives the command data, a string comprising Alice's signature, a reference including the current event stream index to the event stream associated with Alice's funding account, and the name of the device used by Alice to provide the command data (which may be included in the payment metadata used to generate the command data and passed in during generation of the command data).

[0284] Upon receiving the request, the permissions data store 180 identifies the permission corresponding to the permission identifier and determines whether Alice's provided signature corresponds to a cryptographic signature associated with Alice's permissions data structure, which is step S412. This check returns a yes or no answer.

[0285] If the check returns a no answer, a message is provided to Alice that the transaction cannot proceed and the process fails, if the check returns a yes answer the payment protocol module 120 can move to the next step in the payment processing protocol.

[0286] The payment processing module 120 then issues a request from the instance data structure 170 for Bob's instance identifier, i.e., the identifier used to identify Bob's instance of the payment processing resource 106. This is step S414. This is to check that the other party (i.e., Bob) is genuine.

[0287] If the instance data structure 170 cannot provide Bob's instance identifier, it returns a denial message, which is step S416. This leads to a denial being issued to Alice that her transaction cannot proceed due to an invalid counterparty account being identified in the instruction data. The process fails and the request is not processed further.

[0288] If the instance data structure 170 is able to provide an instance identifier for Bob, the payment processing module 120 proceeds to the next step in the payment processing protocol.

[0289] Then, in step S418, a third instance of the payment processing module 120, i.e. the instance responsible for the successful processing of the transaction, verifies that the instructions provided by Alice and Bob are complementary. That is, the payment processing resource verifies that the instruction data corresponding to both sides of the transaction complement each other and that one is paying the other, or in other words, one is sending funds and the other is receiving them. This is step S420.

[0290] In response to a negative decision, i.e., no corresponding instructions from Bob's side, Bob's instance of the payment processing resource 106 provides a denial message, which is then converted by the payment processing resource 106 into a denial of the transaction and such denial is sent to Alice. The process then fails and the request is not processed further.

[0291] If Bob's instance of the payment processing resource 106 has provided complementary instructions, the payment processing module 120 proceeds to the next step in the payment processing protocol, where the transaction data is processed to determine if minimum and maximum balance thresholds have been violated. This is step S422. At this stage, a check may be made to see if both accounts are frozen.

[0292] If it is determined that any of the thresholds have been violated and / or the account is frozen, the payment processing resource 106 issues a denial to Alice that the transaction cannot be completed, which is step S424.

[0293] If it is determined that no thresholds have been violated and / or no freezing instructions are in place, the payment processing module 120 proceeds to the next step in the payment processing protocol, where it is determined whether the zero-sum requirement of the transaction is met, which is step S426.

[0294] The value elements in the instruction data for Alice and Bob are checked to determine if the zero-sum requirement is met. In this example, Alice is paying Bob 5 GBP, so the value on Alice's side should point to -5 GBP (paid by Alice) and the value on Bob's side should point to 5 GBP (paid by Alice). This is because 5 GBP is being debited from Alice's account and 5 GBP is being credited to Bob's account. This means that the zero-sum requirement is met. If the value field on Bob's side points to 4.90, there is an unaccounted 0.10, and the zero-sum requirement is not met. When the zero-sum requirement is met, then 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.

[0295] If the zero-sum requirement is met, the payment processing module 120 may then choose to determine whether a tag is provided in the instruction data that is appropriate for the particular job being performed. That is, the tag in the instruction data from Alice states "Debit 5 GBP and Credit Bob 5 GBP". This is step S428. If the instruction data was signed by the account administrator, the tag is processed to determine the presence of other tags. For example, if the account administrator is a bank and the transaction involves a currency exchange, the appropriate tags should be included. The tags are included in the instruction data, and are generally included in the data that is appended to the event stream to log the transaction. For this reason, it is important that they are accurate.

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

[0297] Proceeding through the steps applied by payment processing module 120 is to apply a payment processing protocol to the instruction data, i.e., the request provided by Alice. The remaining step in determining whether the transaction can be completed is to determine, based on the authorization data structure, whether Alice has the credentials needed to pay money to Bob from the account from which she is paying.

[0298] We now describe how the challenge and response data structures are used to validate Alice's credentials in declaring that she can make this payment from the referenced funding account, which relates to Figures 5a and 5b.

[0299] The challenge data structure is provided by Bob and is provided by an instance of Bob to request that Alice be able to indicate that she is allowed to participate in the transaction. Bob's instance of the payment processing resources 106 generates the challenge data structure upon receiving instruction data for a payment from Alice to Bob. The challenge data structure comprises an identifier for the challenge data structure. The identifier for the challenge data structure may be an alphanumeric or numeric sequence. It may be generated randomly or pseudorandomly. The challenge data structure also comprises a nonce for the data item to be validated. The nonce for the data item is combined with a nonce provided in the response data structure, which forms the basis of a cryptographic signature provided by Alice's instance of the payment processing resources 106 when the data item is validated (as described below). The challenge data structure also comprises the data item being validated. The data items may have an inverted DNS domain-like structure (i.e., com.example.user.id). The data items may be namespaced alphanumeric sequences of characters. The data items may alternatively be any alphanumeric sequence of characters. It may be a representation that can be understood by a human, or it may simply be a randomly generated collection of characters. The data item represents the assertion that Alice is making that she is able to make the payment. That is, the data item represents the credentials that Alice is declaring when instructing the payment processing resource 106 to process the payment to Bob. The data item may be a representation as described above with respect to the authorization data structure.

[0300] The response data structure is provided by Alice in an instruction from Alice associated with her instance of payment processing resources 106. The response data structure may be generated by Alice's instance of payment processing resources 106 upon receiving an instruction to pay Bob. The response data structure comprises an identifier for the response data structure, which may be an alphanumeric or numeric sequence. It may be randomly or pseudorandomly generated. The response data structure also comprises a nonce. The response data structure further comprises an identifier for a corresponding authorization data structure owned by Alice. The response data structure may further comprise an identifier that identifies the device used by Alice.

[0301] The response data structure further comprises a cryptographic signature of a SHA256 hash of the concatenation of the nonce provided in the response data structure and the nonce provided in the challenge data structure. The cryptographic signature may be generated based on a private key corresponding to a public key owned by Alice, i.e., the public key corresponding to the authorization data structure identified in the response data structure. The cryptographic signature may also be generated using a paired private key found in a digital wallet associated with Alice. The steps leading to the generation of the response data structure are now described.

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

[0303] In this example, the response data structure is the response data structure provided by Alice in step S400 as part of Alice's instruction data, satisfying that the challenge data structure proves ownership of the authorization data structure (as described next). How the payment processing resource 106 proceeds if the response data structure is not provided initially and needs to be requested will be described later. That is, the payment processing resource 106 finds the response data structure using the corresponding identifier among those already provided by Alice. This may be done if the responder (i.e., Alice) already knows which authorization data structure the challenger (i.e., Bob) will be requesting as support for the validation of Alice's authority to make a payment. That is, the responder already knows from Alice's authorization data structure which data items Bob will be requesting validation of, and can accordingly generate a nonce and a signature based on the corresponding authorization data structure in the authorization data store 180. The nonce in the response data structure will be generated in step S400 when Alice provides the instruction data. The nonce in the challenge data structure will be generated once a payment from Alice to Bob is agreed upon between the respective parties. The payment processing management module 195 may then generate a cryptographic signature of the concatenation of the nonce, which is then provided in a response data structure included in the instruction data provided by Alice. The concatenation may comprise the nonce from the response data structure followed by the nonce from the challenge data structure.

[0304] Then, in step S504, the payment processing resource 106 extracts the cryptographic signature of the concatenation of the nonce from the response data structure. This signature is verified in step S506 using known techniques for signature verification, such as PKI. The payment processing resource 106 then moves to step S508, where it verifies the cryptographic signature of the SHA256 hash of the concatenation of the first nonce and the second nonce. If the verification indicates that the signature is not valid, the payment processing resource 106 provides a failed transaction message to Alice and Bob with a message that Alice cannot participate in the transaction. This is step S510.

[0305] It may happen that the instruction data relating to Alice and Bob do not provide the respective response and challenge data structures, or, as in step S510, the respective response and challenge data structures do not enable Alice's authorization to pay Bob 5 GBP to be validated. Now, with reference to Figure 5b, it will be explained how Bob's instance of payment processing resource 106 may check that Alice can participate in the payment if the response data structure provided in the instruction data either does not provide a valid signature, or is not provided together.

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

[0307] The challenge data structure contains a data item that should be validated to process the transaction (from Alice) to pay Bob 5 GBP. The data item may be an alphanumeric sequence that states something like "uk.co.Alice-Bank-Account". Alternatively or additionally, it may be a purely numeric sequence like "31415192". The challenge data structure also contains a nonce. The nonce may be randomly generated based on the data item, or may be randomly generated independently of the data item. An identifier is also assigned to the challenge data structure.

[0308] The challenge data structure is then provided to Alice's instance of payment processing resources 106 in step S514. Alice's instance of payment processing resources 106 is then configured to determine from the pending instruction data set whether a response data structure has already been provided (which it does not have in this example) and then, if not, to issue a query to the authorization data store 180 (using the identifier of Alice's authorization data structure) for a corresponding authorization data structure (i.e., an authorization data structure owned by Alice) that contains the alphanumeric sequence "uk.co.Alice-Bank-Account" and that is valid at the time the request is made. This validation step is performed in step S516. The validation step can be summarised as determining whether the expression "uk.co.Alice-Bank-Account" is associated with a corresponding authorization data structure, i.e., whether it can be found among the permissions associated with Alice's authorization data structure.

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

[0310] The presence of a valid authorization data structure containing the alphanumeric sequence "uk.co.Alice-Bank-Account" ensures that Alice has gone through the specified KYC process (by Alice's account administrator) and is authorized by the account administrator to participate in this transaction.

[0311] The query issued in step S516 takes the alphanumeric sequence as a parameter. It may also optionally receive further parameters, in that the query may also carry a flag for which type of alphanumeric sequence is provided, an index in the event stream associated with Alice's instance of the payment processing resource (to validate 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) was made), and an extension indicating the name of the device Alice uses (or has used in the past) to provide instructions to the payment processing resource 106.

[0312] If the permission data store returns a permission data structure owned by Alice, i.e., a permission data structure that can be identified using an identifier for Alice's permission data structure, and if the permissions (i.e., permissionSet) associated with Alice's permission data structure include the alphanumeric sequence "uk.co.Alice-Bank-Account", then in step S518, the payment processing resource 106 generates a response data structure that includes a cryptographic signature of a SHA256 hash of the concatenation of the nonce provided in the challenge data structure with the identifier for the challenge data structure, the nonce provided in the challenge data structure, the identifier of the permission owned by Alice and including the alphanumeric sequence, an extension indicating the name of the device used by Alice, and another copy of the nonce provided in the challenge data structure. The cryptographic signature may be generated by Alice using Alice's private key, i.e., a private key that corresponds to the public key identified in the permission data structure. The cryptographic signature may also be generated using a private key associated with Alice that is found in a digital wallet associated with Alice. The transaction can then proceed when Alice's authorization to make the payment is validated. This is step S520. The payment processing resource 106 then proceeds with the next steps of the transaction, as described below with respect to generating a rendezvous blockchain transaction.

[0313] If the authorization data store does not return an authorization data structure owned by Alice and containing the alphanumeric sequence "uk.co.Alice-Bank-Account", the payment processing resource 106 then proceeds to reject the transaction, which is step S522.

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

[0315] 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 that the signature is proper and that the corresponding authorization is present.

[0316] That is, for each alphanumeric sequence from the challenge data structure, the payment processing resource 106 forms a concatenation of the response data structure and the respective nonce from the challenge data structure. The payment processing resource 106 then queries the authorization data store for the authorization data structure by providing the concatenation and the cryptographic signature from the response data structure provided by Alice. The payment processing resource also provides the authorization identifier from the response data structure to identify the authorization, where the corresponding signature should be found. The query may also provide parameters including an index into the event stream associated with Alice's instance of the payment processing resource 106 when the query is made. The query may also include an indicator of the device Alice is using at the time the transaction is being processed.

[0317] To validate the cryptographic signature, the public key stored in the retrieved authorization data structure is used to construct the signature to check that it returns the same signature over the provided combination of nonces. If so, the cryptographic signature provided in the response data structure is accepted as valid. If not, the response data structure is rejected as not granting authorization to participate in the transaction.

[0318] In response to determining that the cryptographic signature is valid, the payment processing resource provides a request for each alphanumeric sequence corresponding to the cryptographic signature to be validated. This comprises providing a request for each alphanumeric sequence to be validated to the authorization data store. This comprises providing the authorization identifier (of the identified authorization) to the authorization data store along with a request for the authorization data structure identified by the authorization identifier to be returned, and upon return of the authorization data structure, to make a check that the corresponding alphanumeric sequence is found in the identified authorization data structure. If it is found in the identified authorization structure, Alice's authorization to participate in the payment is accepted. If it is not found in the identified authorization structure, Alice's authorization to participate in the payment is denied. The payment processing resource 106 can then proceed with the transaction involving the generation of a rendezvous blockchain transaction, as described with reference to FIG. 6.

[0319] A rendezvous transaction is a blockchain transaction that may have multiple Dust Chain input / output pairs and outputs marked with an OP_RETURN opcode to make the outputs unspendable and to allow for the addition of data carriers. The OP_RETURN opcode causes an immediate termination of the execution of the corresponding redemption script and invalidates it, i.e. the output cannot be redeemed. This means that the output cannot be spent and the data carrier stays on the blockchain as part of the rendezvous transaction. The Dust Chain input / output pairs may have the same index within the transaction and may advance the input funds and change output, respectively. The data carrier may be the final output. The multiple Dust Chain inputs that form a rendezvous transaction may be from different respective event streams.

[0320] In step S600, the payment processing resource 106 then issues a request to the event stream management resource 110 for a rendezvous blockchain transaction to be established based on the respective event streams associated with each of Alice and Bob (and HSBC as their account custodian). This is described with reference to the exemplary schematic diagram in Figure 7. That is, with respect to Alice, the event stream management resource 110 is requested to access the current state of Alice's account (and similarly with respect to Bob's event stream). The chains of dust and their relationship to the event streams are described below with reference to Figures 8 and 9.

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

[0322] The payment processing resource 106 then generates a new rendezvous blockchain transaction 706 with dust inputs for each of Alice and Bob, which consume the respective 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 streams associated with Alice and Bob. This is also shown in FIG. 7. The chain of transactions between 702 and 704 to 706 can be described as a chain of dust transactions, one for each of Alice and Bob corresponding to their respective event streams. A dust input / output is an input / output for an amount of cryptocurrency, denoted by the cryptocurrency field as being "dust". "Dust" in the context of blockchain transactions for the purposes of this disclosure is understood to be a spendable transaction for a digital asset or cryptocurrency with an output of small or very small value, i.e., the value may be much smaller than the fee for mining the output in the blockchain. That is, the new rendezvous transaction synchronizes the event streams named Alice and Bob by creating transactions that underpin entries that are appended to both event streams.

[0323] Alternatively, the payment processing resource 106 may generate new dust transactions using a combination of dust that does not form part of a pre-existing event stream and a hierarchical deterministic (HD) key chain as described in UK Patent Application No. 2102217.3. In other words, a dust transaction is generated using the dust as input and with inputs corresponding to each of Alice and Bob, and the dust has not been used before in the event stream. The party in possession of the HD key chain may use one of the lower keys and the dust to generate the first transaction in the new event stream. In essence, a new event stream may be started based on dust that can be taken from existing transactions on the blockchain 112 and used as a base for starting a new event stream. That is, the dust may be used to generate a transaction (to start a new event stream) and then returned to the platform before being used in starting another event stream.

[0324] The relationship between chains of dust transactions and event streams will now be further clarified with reference to FIG.

[0325] FIG. 8 illustrates the basic data structure and paradigm of an ordered append-only data storage system. This may also be described as a data logging system. The particular system illustrated in FIG. 8 is an event stream system for logging events. As an example, an event stream is used throughout for illustrative purposes, but those skilled in the art will appreciate that the proposed systems and aspects described herein may be used with data records in general, as well as with ordered append-only data item logging or storage systems. The data record refers to a hash of the actual data. The hash may be a hash of instruction data for a transaction being logged in an event stream corresponding to an instance of the payment processing resource 106 associated with a party. The use of a hash instead of the data itself advantageously provides a proof of existence for the data without requiring the data (which may be large, even too large for the transaction) to be stored on the transaction. This also maintains the privacy of the data, since the data is indistinguishable from the hash even if the hash is published on the chain. The data described here is payment instruction data related to a payment being logged by the payment processing resource 106.

[0326] 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 (506) using a "chain of dust". Data related to each event is stored in a payload (described below) as part of each transaction. The data payload (i.e., a hash of the payment instruction metadata) is held in a non-consumable OP_RETURN output of the transaction, an example of such a transaction is the rendezvous transaction 706 as described above. This is a Script opcode that can be used to write arbitrary data onto the blockchain and also to mark transaction outputs as invalid. As another example, OP_RETURN is a Script language opcode to create a non-consumable output of a transaction that can store data such as metadata within the transaction, thereby immutably recording the metadata on the blockchain.

[0327] A chain of dust (or dust chain) is an uncorrupted chain of cryptocurrency inputs and outputs that is used here to enforce the consumption dependency of each blockchain transaction in a sequence on its immediate predecessor.

[0328] The use of dust outputs in transactions is advantageous and key to maintaining an immutable sequential record of all transactions as they are made to an ordered append-only data storage system such as an event stream. This is because by posting transactions to the blockchain, all blockchain transactions will be time stamped and remain in a specific order as they are confirmed on or added to the blockchain, but this does not guarantee the preservation of their sequential order. This is because transactions may be mined into blocks at different times and / or even within the same block, transactions will be in different orders. The use of dust outputs consumed by the first input of the next transaction in the sequence advantageously ensures that the order of transactions is tracked in time, as well as creating a tamper-proof record of both the events themselves and the sequential ordering of the events. This is because, when mined into a block, the payment of dust from the previous transaction to the next transaction in the sequence ensures, in alignment with the Bitcoin protocol rules, that the sequence of the embedded data carrier elements, called payloads and described below, cannot be reordered and that no insertions or deletions can be made that would change the event stream without it being immediately apparent that it is being compromised. In some embodiments, the double-spend prevention mechanism inherent in the Bitcoin protocol ensures that the movement of cryptocurrency (e.g., dust) between different transaction inputs and transaction outputs remains in order over time. The chaining of dust transactions exploits topological ordering to provide inter-block and intra-block transaction (and therefore associated events and data) order preservation. This therefore improves the integrity of the ordered append-only data item storage.

[0329] In this way, the blockchain transactions 504 form a directed graph of transactions. Note that the direction of the graph can be considered as unidirectional, from the previous transaction to the next transaction in the sequence, as indicated by the edge 506. Although the arrow on the edge 506 in FIG. 8 indicates that one transaction points to the next transaction, the consumption relationships in Bitcoin transactions are actually from one transaction to the preceding transaction. The graph is created by the consumption relationships between transactions. These consumption relationships can be considered as a type of reference. Further details on how to append events to an event stream can be found in UK Patent Application No. 2102314.8, which in detail, but not by way of limitation, refers to "Ordered Append-Only Data Storage", "Event Streams and Dust Chains", and "Backward References in Dust Chains".

[0330] A rendezvous blockchain transaction, such as transaction 706 shown in FIG. 7, is a blockchain transaction to synchronize multiple event streams, each related to a given entity / user as described above. This is accomplished by consuming multiple dust outputs as corresponding inputs. In this example, this allows the chains of dust (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 shall have corresponding input / output indexes in the transaction. In this case, the dust chain input / output pairs are used to allow the payment to be recorded in all event streams related to the transaction, as read below.

[0331] The dust input consuming the dust output for Alice is denoted as Tx1,Alice, and the dust input consuming the dust output for Bob is denoted as Tx1,Bob. In step S602, a new rendezvous blockchain 706 transaction is created.

[0332] Funds are added into the rendezvous blockchain transaction 706 by the payment processing resource 106 and the funds are paid back to the payment processing resource 106. This may be subject to any miner fees following validation of the rendezvous blockchain transaction 706 if it is sent to the blockchain 112 for validation.

[0333] The rendezvous blockchain transaction 706 comprises further dust outputs consuming Tx1, Alice and Tx1, Bob, respectively. Because it is a rendezvous transaction, the indices of the input / output pairs corresponding to Alice and Bob, respectively, are identical in that, for example, the input index of Tx1, Alice may be assigned as number 1, and the output index of the corresponding dust output is assigned as output index number 1.

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

[0335] Each of the data carriers may hold a separate dataDigest and / or a separate streamDigest, and the streamDigests may also be pooled.

[0336] The data payload held inside each data carrier (i.e. a hash of the payment instruction metadata) is held in the non-consumable OP_RETURN output of the transaction, meaning that the data payload can then be stored in the blockchain as a non-consumable output.

[0337] The data inside the data carrier 712 comprises a hash of the instruction data generated by the payment processing resource 106. This is generated in step S334. The provably non-consumable output allows the rendezvous transaction 706 to carry a hash of the payment instruction data set in a transaction, allowing the hash to be stored on the blockchain. This means that the payment instruction data set, and therefore the record of the payment, is stored on the blockchain. This means that the record of the payment benefits from the immutability of the blockchain.

[0338] The blockchain transaction 706 may then be checked to see if the user correspondence to the transaction is proper and corresponds to the users, i.e., Alice and Bob. This is step S604.

[0339] 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 the basis for appending data to the event stream, i.e., the event stream for Alice and Bob.

[0340] An event stream is a blockchain-supported append-only log. In this example, Alice and Bob each have their own event stream, but if they do not, an event stream may 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 may be denoted as ESn, where n may be a non-zero positive integer, i.e., a non-negative integer.

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

[0342] The payment processing resource 106 appends to the respective event streams only if Alice and Bob are authorized to access or append to the event stream. Authorization may be checked, for example, by comparing the cryptographic signature used to sign the instruction data with a stored signature in the payment processing resource 106. By appending the payment data to the event stream, the payment can be recorded and can benefit from being recorded on an immutable log related to the blockchain 112. In essence, the event stream is used to track the order of transactions from accounts related to Alice and Bob. That is, the entries in the event stream are an immutable log related to the blockchain 112. An event stream as described above ensures that: · Individual entries in the event stream have not been modified since they were written. No entries have been previously inserted between consecutive entries. The entry has not been removed. The entries are not sorted. · Unauthorized parties cannot append events to the stream.

[0343] 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 those event streams that includes a hash of the payment instruction metadata contained in the data carrier in the blockchain transaction 706. This is step S608. This is illustrated diagrammatically in Figure 9. An account custodian, for example HSBC, may also have an event stream E-HSBC that is also appended with a hash of the instruction data.

[0344] The payment processing resource 106 then generates an identifier for each entry added to the event stream. This is step S610. The identifier may be alphanumeric, or may be 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 may be generated by applying a further SHA256 cipher to the hash of the instruction data. That is, the identifier may be a hash of the hash of the instruction data.

[0345] The payment processing resource 106 then stores the identifier along with a copy of the instruction data in the payment data store 124. This allows for verification of the payment between Alice and Bob in the request. The payment processing resource 106 also stores the cryptographic signature used to sign the instruction data along with the identifier.

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

[0347] That is, a payment from Alice to Bob is processed according to a message sent to the payment processing resource 106, which then determines, using the authorization data structure and the payment processing protocol, whether the payment can be made and what the response should be, i.e., whether the transaction should proceed or not.

[0348] Next, with reference to FIG. 10, it will be described how the configuration of an instance of a payment processing resource 106 may be adjusted.

[0349] To modify the settings corresponding to an instance of a payment processing resource 106, the first computing device 102 makes a call to the API 108, which identifies an instance identifier for the respective instance of the payment processing resource 106 to which the setting adjustment value pertains. This is step S1000. Based on this 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 an adjusted setting protocol needs to be applied.

[0350] The request also comprises an instruction data set comprising a timestamp corresponding to the time the request is provided through the API 108, an extension identifying the particular computing device corresponding to the first computing device 102, a requested adjustment to the maximum balance (if it is being reconciled), a requested adjustment to the minimum balance (if it is being reconciled), a freeze amount to indicate the amount of currency in the funding account to be held (if it is being reconciled), an instance identifier for the account to be frozen (if it is being frozen), a field corresponding to the legal basis for the freeze order, a label for the instance of the payment processing resource 106 (if it is being reconciled), the number of decimal points the account uses to make balance updates (if it is being reconciled), a spending limit for the funding account associated with the instance of the payment processing resource 106 (if it is being reconciled), and a cryptographic signature provided by the account holder.

[0351] The settings to be adjusted provided in the request are processed in step S1002 to determine whether the setting adjustment values ​​are accurate (i.e., do not conflict with the requirements of the payment processing resources 106). For example, the setting adjustment values ​​may be incorrect if the data is invalid. One example may be, for example, a timestamp that is a negative number. Another example may be an incorrect instance identifier for the account to be frozen, i.e., an instance identifier that does not match the instance identifier for the account identified in the request. Another example may be a minimum balance that is greater than the maximum balance. If the setting adjustment values ​​are not accurate, the payment processing resources 106 issues a failed request message to the first computing device. This is step S1004. In a request that includes multiple adjustment values, the payment processing resources 106 may be configured to reject the request for all of the adjustment values ​​if one of the adjustment values ​​is known to be incorrect.

[0352] If the configuration adjustment values ​​are correct, the payment processing resource 106 proceeds to check the cryptographic signature provided in the request, which is step S1006.

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

[0354] This involves providing the data in the request, i.e., the data over which the cryptographic signature is used, and the cryptographic signature, so that the cryptographic signature can be verified using a suitable technique. If the cryptographic signature provided in the request is the same as the cryptographic signature generated by the public key, the request for the setting adjustment value can proceed in step S1008, and a response is then generated to confirm that the settings are 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, which may be included in a response to the first computing device 102 confirming the change to the setting. If the compared signatures are not the same, a rejection message is issued to the first computing device 102 in step S1010.

[0355] The process described with respect to Figure 10 may be used to change settings in an instance of a payment processing resource 106. Determining the accuracy of the setting changes and checking the signature may form an adjusted setting protocol. This may be used to change maximum and minimum balances, but also to freeze or unfreeze accounts. Upon receiving a request to make a change to the settings, the authorization data structure is checked to see that the signature is correct. If the signature is correct, the adjustment may be made. If the signature is incorrect, the adjustment may not be made.

[0356] In some cases, it may be possible for an account administrator to generate the configuration changes and provide the calls described in step S1000. In that case, the account administrator may have their authorization data structure checked to ensure that it entitles them to make the changes.

[0357] It will now be described how the cryptographic signature used to sign the instruction data can be used to prevent duplicate transactions from being processed and duplicate entries from being added to the associated event stream. This will be described with reference to Figure 11. Although this will be described with respect to a single instance of a payment processing resource 106, it will be appreciated that this can apply to any instance of a payment processing resource 106 involved in a transaction.

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

[0359] In step S1102, the payment processing resource 106 identifies a cryptographic signature that is used by the debiting party (Alice in the above example) to cryptographically sign the instruction data. Alternatively, the payment processing resource 106 may identify another party's signature on the transaction, such as a credit.

[0360] In step S1104, the payment processing resource 106 accesses the payment data store 124 to determine whether the cryptographic signature is already recorded in the payment data store 124, i.e., as a transaction that has already occurred and is on the event stream associated with the parties involved in the transaction. The payment data store 124 may sort the transactions by any suitable value, such as, for example, the date of the transaction, the cryptographic signature used to sign the instruction data, or any other suitable value.

[0361] If the cryptographic signature already exists in the payment data store 124, it is highly likely that the transaction has already been processed and a rejection message is provided in step S1106. In some embodiments, the logs in the payment data store 124 may only be checked for a predefined period of time, such as, for example, the previous 30 days, or the check may be limited to only the most recent 100 entries.

[0362] If the cryptographic signature is not already present in the payment data store 124, then it is highly likely that the transaction has not already been processed and the transaction proceeds to the steps outlined in steps S406-S428 and steps S500-S520.

[0363] That is, the payment processing resource 106 may determine that the transaction may have been processed previously. Duplicate transactions, i.e., the same instruction at the same time, are undesirable to both the account holder and the account administrator and need to be prevented.

[0364] It may happen that both Alice and Bob (to use an earlier example) submit instruction data at the same time, which results in generating a go-ahead response for Alice and a deny response for Bob. The payment processing resource 106 may then respond by reprocessing after a specified period of time, e.g., 100-300 milliseconds, to allow the corresponding event stream to be properly updated, so that a determination as to whether there is an overlap can be made again.

[0365] It should be noted that the above-mentioned aspects and embodiments illustrate rather than limit the present disclosure, and that those skilled in the art can design many alternative embodiments without departing from the scope of the present disclosure as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the scope of the claim. Words such as "comprising" and "comprises" do not exclude the presence of elements or steps other than those recited in any claim or the specification as a whole. As used herein, "comprises" means "includes or consists of" and "comprising" means "including or consisting of". A singular reference of an element does not exclude a plural reference of such element and vice versa. The present disclosure may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. [Explanation of symbols]

[0366] 100 Systems 102 First computing device, computer equipment 103 Users, Entities, Parties and Agents 104 Second Computing Device 105 Client Applications 106 Payment Processing Resources, Bitcoin Network, Blockchain Network 108 Application Programming Interface (API) 110 Event Stream Resources, Event Stream Manager, Event Stream Management Resources 110a Alice 110b Bob 110c Payment Processing Resources 112 Blockchain 120 Payment protocol module, payment processing module 122 Key Storage Module 124 Payment Data Store 126 Blockchain nodes, Bitcoin nodes 130 Packet Switching Networks 132 Blockchain network, Bitcoin network, Peer-to-Peer (P2P) network 150 Bitcoin Blockchain 151 Blocks 152 Transactions 153 Genesis Block (Gb) 154 Ordered Sets 155 Block Pointer 170 Instance Data Structure 180 Authorization Data Store 195 Payment Processing Management Module 200 Permission Hierarchy 202 Top Level Route Allowed 206 Organization Level Root Permissions 208 Organization Level Root Permissions 210 Organization Level Root Permissions 216 XYZ UK Permit 302 NBW Route Permit 304 Angler's permit, fishing permit 306 Angler's permit, fishing permit 320 Permission Structure 322 Club Permit BLFC 450 Node Software 451 Protocol Engine 452 Script Engine 453 Stack 454 Application Level Decision Engine 455 Blockchain-related functional modules 455C Consensus Module 455P Propagation Module 455S Memory Module 502 Events 504 Blockchain Transactions 702 Blockchain Transactions 704 Blockchain Transactions 706 Rendezvous Blockchain Transactions 712 Data Carrier< / uuid>

Claims

1. 1. A computer-implemented method for appending entries to at least one event stream, the at least one event stream relating to asset accounts associated with users registered on a wealth transfer platform, the method being performed on a processing resource, the method comprising: receiving a request to append an entry to the at least one event stream, the entry comprising instruction data and an identifier for the at least one event stream; extracting the identifier for the at least one event stream from the request; accessing the at least one event stream based on the identifier; and obtaining a log of previous entries associated with the identified at least one event stream; extracting the instruction data from the request; generating a unique identifier for the instruction data; determining, based on the generated unique identifier, whether data identical to the instruction data exists in the log of previous entries associated with the identified event stream; based on a result of said determining step, appending an entry to said at least one event stream, said entry comprising said unique identifier for said instruction data, or rejecting said entry to said event stream as a duplicate entry. Equipped with receiving a further request received substantially simultaneously with the request to append an entry to the at least one event stream, wherein when the further request comprises identical instruction data as the request to append an entry to the at least one event stream, the method comprises the step of rejecting both requests.

2. The method of claim 1 , wherein the unique identifier for the instruction data comprises a cryptographic signature used to cryptographically sign the instruction data.

3. The method of claim 2 , wherein the cryptographic signature is generated using ECDSA techniques.

4. The method of claim 2 , wherein the cryptographic signature is generated based on a public key and / or a private key owned by an entity associated with the transaction.

5. The method of claim 2 , wherein the cryptographic signature is retrieved from an authorization data structure associated with an entity involved in the transaction.

6. the request is to append entries to multiple event streams, and the method comprises: extracting the identifier for each of the plurality of event streams from the request; identifying each of the plurality of event streams and a corresponding log of previous entries; using the unique identifier as a search key; and determining whether data identical to the instruction data has previously been added to any of the logs; and either appending the entry to each of the event streams using the unique identifier or rejecting the entry to the plurality of event streams based on the result of the determining step. The method of claim 1.

7. determining from the instruction data a condition for the at least one event stream that must be satisfied in order for the entry to be added to the at least one event stream; determining whether the condition is met before adding the entry to the at least one event stream; The method of claim 1 further comprising:

8. The method of claim 7 , wherein the condition is that the event stream index must be less than or equal to an integer defined in the instruction data.

9. The method of claim 7 , wherein the condition is that the entry be added to the event stream within a predetermined time period.

10. The method of claim 1 , wherein the entries included in the log are maintained in the log for a predetermined minimum period of time.

11. 2. The method of claim 1, wherein the processing resource is configured to maintain the log at a maximum size by removing entries that have been in the log longer than a predetermined maximum period of time.

12. A system configured to perform the method of any one of claims 1 to 11.

Images