Computer-implemented method and system for public key infrastructure and authentication

Abstract

Embodiments provide a secure and flexible technical solution for verifying the identity of a user, creating a trusted network, and / or implementing a PKI or trusted network. Some embodiments may be particularly suited for use in conjunction with a blockchain. The present disclosure enables verification entities to apply their own rules, policies and criteria to select and / or combine identity resources, such as documents from a set of such resources provided by a user. Thus, the user can control which documents are provided to the verification entity, while the verification entity can select which, how many, and what type of resources it considers acceptable in order to successfully confirm the identity of the user. Access to the resources controlled by the verification entity is granted or denied depending on the result of its authentication attempt based on the resources provided by the user.

Description

Technical Field

[0001] The present disclosure relates to secure and flexible technical solutions for verifying and validating identities, creating or improving trust networks, and / or implementing PKI (Public Key Infrastructure). Some embodiments may be particularly suitable for use in conjunction with blockchains. Background Art

[0002] In many cases, entities (e.g., natural persons and individuals, enterprises, or computer-based systems) need to prove to another party that they are who they claim to be. Thus, proving and validating identities is a common and routine activity in today's world. For ease of reference, the term "user" will be used to denote an entity that wishes to prove its identity to another (verifying) party.

[0003] One way to confirm an identity is to use Public Key Infrastructure (PKI), which involves proving ownership of a private encryption key in a way that only a legitimate, authentic entity can demonstrate. For example, a private key can be used to encrypt a puzzle, and the verifying entity can then decrypt it using the corresponding public key, or a digital signature can be created for a resource such that the verifier can check the signature. In this way, PKI provides a "trust service" that can be used to verify whether the sender or receiver of data is who they claim to be.

[0004] However, different verifying entities may require different types of proofs. For example, one organization may require a utility bill and a driver's license as proof of personal identity, while another organization may require a passport, a university degree certificate, and a bank statement. It can be challenging for an entity attempting to prove its identity to collate and provide various combinations of proofs. Additionally, documents and other proofs may expire or become obsolete and may thus need to be revoked or no longer considered a legitimate source of identity verification. From the perspective of the verifying entity, it is necessary to specify, obtain, and examine one or more proofs that it deems sufficient to confirm an identity. Known methods of this verification process can be time-consuming and laborious. Therefore, it would be advantageous to provide a solution that enables entities to prove and verify identities in a secure, efficient, and flexible manner. A solution has now been devised that can at least address these technical challenges and at least provide these technical effects. Summary of the Invention

[0005] Embodiments of the present disclosure are at least aimed at providing a general identity scheme that enables an entity (e.g., an individual or group of natural persons, a legal entity, an organization, or one or more computer-based resources, etc.) (which will be referred to as a "user" for ease of reference) to prove their identity to another party (which will be referred to as a "validating entity" for ease of reference). In some embodiments, this can be achieved or at least facilitated by using a blockchain.

[0006] In some embodiments, the scheme combines aspects of on-chain PKI. However, importantly, according to the disclosed embodiments, the user can determine and / or create a set of rules and policies regarding identity-related resources (e.g., documents) that the user wishes to provide to one or more validating entities to prove their identity. Additionally or alternatively, the validating entity can apply its own set of rules and policies when selecting identity-related resources during an attempt to verify the identity of the user.

[0007] The validating entity can be any type of entity that wishes to confirm the identity of the user (e.g., an individual or group of natural persons, a legal entity, an organization, or one or more computer-based resources, etc.). In a preferred embodiment, at least one validating entity can select one or more identity resources from among the multiple such resources that the user has provided to them. This differentiates the present invention from prior art arrangements where the user selects which identity resources to provide to the verifying party, and prior art arrangements where the verifying party sends requests for specific types of identity resources. This enables the validating entity to apply its own rules, policies, and / or criteria to the selection of the identity resources required for verification purposes. For example, one validating entity can select a utility bill and a driver's license as sufficient proof of identity, while another validating entity can select a passport, a birth certificate, and a social security number according to the predetermined criteria of the validating entity.

[0008] In some embodiments, the verification entity may rank (i.e., weight) the identity resources and / or assign a predetermined value to a resource type. For example, the verifier may utilize a point-based method where different points or weights are assigned to different identity resources based on their perceived importance or credibility as identity evidence, and a predetermined number of points may be selected as a threshold for determining identity. The type and / or quantity of identity resources selected by the verification entity may then depend on the identity resources provided by the user and required by the verifier. For example, the verification entity may determine that at least 50 points are required to verify a user's identity, where a utility bill counts 25 points and a driver's license counts 30 points. If the user has provided their utility bill and driver's license, the verification entity will consider the selection of these two identity resources by the verification entity sufficient to determine that the user is the identity they claim to be. On the other hand, another verification entity (e.g., a potential employer) may determine that a university degree certificate and any one of a passport, birth certificate, or driver's license are the required identity resources.

[0009] Accordingly, the embodiments facilitate the implementation of on-chain PKI, rather than just a simple "I have an encryption key that can be used to sign something". The present disclosure allows a verifying third party to select from among multiple identity resources provided by the user, enabling a more refined but flexible approach to building different levels of trust and security.

[0010] In this way, the embodiments of the present disclosure enable the creation of a trust network or PKI based on the provision and use of different sources of verification.

[0011] It should be noted that, for clarity, the term "validation" is used herein in its conventional meaning and relates to determining the identity of a user, rather than the verification function performed by nodes on a blockchain network. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] To assist in understanding the embodiments of the present disclosure and to illustrate how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0013] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0014] Figure 2 schematically shows some examples of transactions that may be recorded on a blockchain;

[0015] Figure 3A shows a schematic block diagram of a client application;

[0016] Figure 3B shows what may be Figure 3AA schematic model of an exemplary user interface represented by a client application;

[0017] Figure 4 A schematic block diagram showing some node software for processing transactions;

[0018] Figure 5 A block diagram showing a summary block of functional blocks of an interaction according to a preferred embodiment;

[0019] Figure 6 A block diagram showing multiple members of a set of digital identity resources and the connections between such members;

[0020] Figure 7 A flowchart showing the steps performed according to a preferred embodiment. Detailed Description

[0021] For illustrative purposes, some examples of systems and methods that can be used to implement preferred embodiments of the present disclosure are now provided.

[0022] According to an illustrative embodiment of the present disclosure, consider a scenario where an entity (such as, by way of example only, a user) wishes to provide evidence to at least one third party such that the third party can verify the identity of the user, and the user can prove that they are who they claim to be.

[0023] In the following example, a scenario is used where a user wishes to prove their identity in order to open a bank account. It should be noted that this is for illustrative purposes only, and the identity of the user can be verified for any purpose. However, typically, identity verification will be performed before an authorization action is taken, access to a controlled resource (whether physical, electronic resources such as a vehicle, building, network account, software, etc.) is granted, or a controlled service is performed. In a simple example, the controlled service is providing a financial account, but any other controlled resource can substitute for this example.

[0024] As Figure 5 shown, the exemplary user 51 is a user who wishes to open a bank account at, for example, a bank 52. The bank 52 is the verifier, and the bank 52 requires the user 51 to prove the identity of the user 51 to the bank 52 before the bank 52 allows the user to open a bank account at the bank 52. This is because the bank 52 needs to know exactly which party it is opening a bank account for in case, for example, the user 51 is committing fraud when attempting to open a bank account and provides a name different from the user 51's true name to the bank.

[0025] In Figure 5In the example described, bank 52 requests that user 51 provide the bank with a specific set of official documents so that user 51 can fully prove user 51's identity to bank 52. User 51 provides a set of official identity resources (e.g., documents) to storage facility 53 via a network connection, which can be an Internet connection, a mobile phone connection, or other well-known network connections that allow data exchange. For example, the set of official identity-providing documents can be a driver's license in the name of user 51, a birth certificate in the name of user 51, a passport in the name of user 51, a social security card in the name of user 51, a bank statement associated with another bank account belonging to user 51, a university degree certificate (stating that user 51 has graduated from a designated university and has obtained a certain degree qualification in a designated major at that designated university). User 51 stores digital versions of such documents on storage facility 53, which may initially exist in paper form or always be in digital form.

[0026] In Figure 5 this, storage facility 53 can be a database, a cloud-based service (many such services are available), or the storage facility can be implemented as a blockchain (the details of which are provided in this document in connection with Figures 1 to 4 blockchain), and the provided identity resources can be stored on multiple nodes 104 of blockchain peer-to-peer network 106 (as Figure 1 shown).

[0027] User 51 wishes to provide certain identity resources to verification third party 52, so user 51 generates a set of at least one (but preferably multiple) identity resources, with examples as given above (driver's license, etc.). Each identity resource is a resource or item that is associated with the user in some way. In one or more embodiments, these identity resources may be selected by the user from among multiple resources over which the user has ownership and / or control.

[0028] The identity resources can take any suitable form of identity evidence. Preferably, the identity resources are electronic resources that include data in digital form. For example, the identity resources can be electronic documents, such as scans of paper documents, photos, PDFs, or other electronic captures. Or, the identity resources can be or include software-generated data, such as digitally signed resources, etc. The identity resources can be issued or provided by any suitable issuing source, such as a utility provider, a passport office, a licensing agency, a notary, or a bank, etc.

[0029] When selecting a set of identity resources that the user wishes to provide for authentication, the user provides the set of identity resources to at least one third party. This can be implemented in any way suitable for a particular implementation. Preferably, the identity resources are provided by the user for storage in the storage facility 53. As described above, this can include databases, blockchains, cloud-based resources, etc. The nature or form of the storage facility is not restricted. For example, in one implementation, the user can provide the identity resources through a website, while in another implementation, the user can upload the identity resources to a document resource such as Microsoft SharePoint. The user can share a URL or link to the location of the identity resources with at least one third party.

[0030] In a preferred embodiment, the identity resources are managed by a digital wallet on the storage facility 53. The digital wallet can be used and accessed by the user 51 via an interface or a software application (app). In some embodiments, one or more of these identity resources are stored in the user's wallet but registered on the blockchain. This has the advantage that the registration of these identity resources can be verified in an immutable and timestamped manner, and the wallet can revoke a particular identity resource, for example, if the particular identity resource has expired or become obsolete, or if the user no longer wishes to provide the particular identity resource as proof of identity. This can be achieved by implementing the storage facility 53 on multiple nodes 104 of the peer-to-peer blockchain network 106, all of which are Figure 1 illustrated illustratively. The digital wallet application can run on a software layer that implements the blockchain peer function. For example, the digital wallet application can be built as a smart contract, containing business logic code for implementing wallet functions, or the wallet can include a smart contract.

[0031] In this embodiment, a set of identity resources associated with the user 51 can be stored in the blocks Bn-1, Bn, etc. of the blockchain 150 running on the nodes 104 of the Figure 1 blockchain peer network 106. When the user 51 decides to add new identity resources to the blockchain or remove certain identity resources from the blockchain, such as in the case where such identities become obsolete or expired, these identity resources can be added to the memory pool 154, waiting to be incorporated into the blocks 152 of the blockchain. This can be achieved by generating transactions that include these identity resources (or references to them) and then submitting these transactions to the memory pool for subsequent inclusion in the ledger.

[0032] In Figure 5 this, the user 51 can be considered Figure 1 Alice (payer 103a) ofFigure 5 The verifying party 52 can be considered as Figure 1 Bob (recipient 103b) in

[0033] As is well known, the data stored in the blockchain 150 is immutable, which means that no other user can change the data unless all other users of the blockchain are immediately aware of the change. This is achieved by using cryptographic primitives such as hash functions, digital signatures, and encryption. Thus, a set of identity resources added by user 51 / 103a to the blockchain 150 is securely registered in the storage facility 53 / blockchain 150. Due to the properties of the hash function (the result is deterministic and irreversible), it is possible to easily verify whether the content of a block has been modified by hashing the block content again and comparing it with the identifier of the subsequent block, as is known in blockchain technology.

[0034] Preferably, access rights to the storage facility 53 and / or the identity resources stored in the storage facility 53 are controlled such that only authorized third parties (such as the verifying party 52) can obtain access to the identity data. User 51 can share the access control mechanism with at least one third party (e.g., the verifying party 52) via any suitable means, such that the at least one third party can access the identity resources at the storage facility. User 51 may wish to allow multiple third parties to access a set of user 51's identity resources, and user 51 will then share the access control details with each of such third parties. For example, user 51 may want to allow other third parties in addition to the bank 52 to obtain access to a set of identity resources, such as a law firm (e.g., which will conduct a money laundering check on user 51 before taking user 51 on as a new client).

[0035] In Figure 5 user 51 can convey such access control details directly to the verifying party 52 via a direct connection 54 (through the network as discussed above), or via the storage facility 53 as an intermediary, through a connection 55 between user 51 and the storage facility 53, and then through a connection 56 between the storage facility 53 and the verifying party 52.

[0036] Although Figure 5 only one user 51 and one verifying party 52 are shown in

[0037] The access control mechanism can be any suitable authorization means, such as a secret identifier, such as a password, PIN or encryption key, etc. The access control mechanism can be set to allow only temporary access. For example, the access control mechanism may expire or stop operating after meeting criteria set by the user. For example, the access control mechanism may expire after a certain period of time, or at a certain date or time, or after being used a predetermined number of times to obtain access rights.

[0038] In a preferred embodiment, each third party (e.g., the bank 52 in the above example, and any other third party, such as the law firm mentioned above) is given their own corresponding access control mechanism. The user can organize or structure the identity resources in such a way that different types of identity resources can be provided to different third parties. For example, the identity resources can be arranged in a hierarchical structure according to the level of confidentiality determined by the user to be applied to a particular resource. For example, the user may consider the confidentiality of utility bills and birth certificates to be lower than that of passport details, and the confidentiality of passport details may in turn be considered lower than that of social security numbers, bank account details or tax identification numbers. A third party that needs to verify the user's identity can obtain an access control mechanism that allows the third party to access resources in one or more levels of the data structure. Thus, access rights can be provided to allow the user to have different levels of access as necessary or appropriate. This can include the user's trust assessment of a particular third party. For example, the user may consider government departments such as the tax office or passport office to be more trustworthy than a credit provider for a car loan.

[0039] Each user 51 can apply their own set of rules or policies to the corresponding set of identity resources stored in the storage facility 53. For example, user 51 can specify a policy where only certain very trusted third parties 52 (such as government entities) can access the digital representation of user 51's birth certificate, while a wider range of third parties 52 can access other members of the set of identity resources, such as a pdf scan of user 51's passport or a scan of user 51's driver's license. As mentioned above, this policy can be specified by sharing different access control mechanisms applicable to different verifying third parties 52, or alternatively, user 51 can specify policies for sharing certain members of a set of identity resources, which can be encoded as part of a smart contract, where the storage facility 53 is implemented as a blockchain, as discussed above. Any other way of decoding the policy can also be used to specify user 51's specific circumstances and expectations regarding sharing identity resources.

[0040] Similarly, each verifier 52 may specify its own set of rules or policies that may be applied to a set of identity resources stored by at least one user 51 on a storage facility 53 and shared with each such verifier 52. For example, one verifier 52 may require reviewing utility bills (e.g., water bills, energy bills, etc.) as well as a driver's license, and if the verifier 52 accesses these two identity resources, the verifier 52 considers this sufficient to verify the identity of the user 51. On the other hand, another verifier 52 may require a scanned copy of a passport, a university degree certificate, and a bank statement. Yet another verifier 52 may need to check all of the identity resources just mentioned. Each such verifier 52 may apply its own set of rules or policies to select specific members of a set of identity resources stored by the user 51 on the storage facility 53. The set of policies / rules may be specified by encoding them as part of a smart contract, where the storage facility 53 is implemented as a blockchain as discussed above. Any other means of encoding the policies may also be used to specify the particular circumstances and expectations of the user 51 regarding the shared identity resources.

[0041] The above-described multiple sets of policies / rules set by the user 51 and the verifier 52 may be implemented in software logic by assigning connections between each member of a set of identity resources, and then weights or rankings may be assigned to each of these connections according to the importance levels assigned by the user 51 or the verification entity 52 for that pair of members in the set of identity resources.

[0042] Specifically, Figure 6 a set of identity resources 60 of a specific user 51 is shown, which the user 51 has decided to share with a verification entity (such as the verifier 52) and store in the storage facility 53. In Figure 6 the example shown, the set of identity resources 60 includes a utility bill 61, a driver's license 62, a passport 63, a university degree certificate 64, and a bank statement 65.

[0043] In a preferred embodiment, one or more of these identity resources may be protected, generated, signed, or encoded cryptographically by the issuing entity. For example, the issuing entity of a passport is typically a government passport office, and the issuing entity of a degree certificate may be a university. Using cryptography enables the verification of the identity of the issuing entity (and thus the authenticity of the identity resource). For example, the issuing entity may encode or sign the identity resource or a certificate associated therewith using a private key. The resource or certificate may be decoded, or the signature may be checked, using the public key associated with the private key. In this way, the validity of the identity resource can be confirmed by using cryptographic keys. The association of a public key with a particular issuer may be obtained from a trust network. Additionally or alternatively, the public key may be obtained directly from the issuer or a known representative. In this way, the verifying entity can check whether the identity resources provided by the user are authentic and have not been forged, counterfeited, or altered from their original issued state. This provides an improved level of security for the verifying entity.

[0044] Figure 6 A connection 612 between a utility bill 61 and a driver's license 62 is shown. Similarly, a connection 613 between the utility bill 61 and a passport 63 is shown, a connection 614 between the utility bill 61 and a university degree certificate 64 is shown, a connection 615 between the utility bill 61 and a bank statement 65 is shown, a connection 634 between the passport 63 and the university degree certificate 64 is shown, a connection 635 between the passport and the bank statement is shown, and a connection 645 between the university degree certificate 64 and the bank statement 65 is shown.

[0045] Each of these connections 612 to 645 may have a weight assigned to them (which may be referred to as a "point" or "value") such that a particular pairing of identity resources can be ranked according to the importance of the policy that the user 51 and / or the verifying party 52 has set for a particular pairing. Alternatively, rather than weighting the connections between members of a set of identity resources, a weight may be assigned to each member (61 to 65) of the set 60 itself. The rules of the verifier may specify that a combination of identity resources may need to reach a sufficient total number of "points" in order for the identity of the user to be considered successfully verified.

[0046] In the case of weighting the connections, for a particular policy that a particular verifying party 52 wishes to implement, in the case where the verifying party 52 requests access to the utility bill 61 and the driver's license 62, a very high weight, such as 95 (where it is assumed that the ranking range is from 0 to 100), may be assigned to the connection 612. Similarly, for another verifying party 52 that needs access to the passport 63, the university degree certificate 64, and the bank statement 65, very high weights, such as 90, may be assigned to the connections 635, 634, and 645.

[0047] Similarly, the user 51 can assign weights to the members of a set of identity resources 60, indicating the user 51's preferences / policies / rules regarding sharing each member of the set with the verification entity. For example, if a low weight is assigned to a specific connection between two members (i.e., their combination), such as if a weight of 20 is assigned to the connection 612 between the utility bill 61 and the driver's license 62, the user 51 considers these two members of the set of identity resources 60 to be less sensitive and more accessible to a wider range of verification parties 52.

[0048] In the case where the user 51 does not know the policies of each potential verification party 52 among the potential verification parties, the user 51 can assign very low weights to the members (or to the connections between each of these members), ensuring that each verification party 52 can apply the rules or policies of such verification parties to the greatest extent possible. That is, in the case where the verification party 52 needs to access the passport 63, the driver's license, and the university degree certificate 64, the user 51 must have assigned a low enough weight to each such member (or the connection between the members) such that the verification party 52 can access each of these three members.

[0049] In the trust network implementation, a trust relationship is established between users who wish to communicate with each other. Each user decides which other users that user trusts and to what degree of trust. The user signs the public encryption key of each other user that the user trusts and assigns a trust value (a numerical value in the range of 1 to 255) to represent the degree of trust. The calculation is performed by adding the trust values. Similarly, in Figure 6 this case, each member of a set of identity resources 60 can sign the identity key (public encryption key), and the verification party 52 can assign a trust value to that member of the set of identity resources 60, thereby allowing the calculation of points for a specific grouping of one or more members of the set of identity resources 60. For example, the bank 52 can specify its degree of trust in the driver's license as 30 points, the degree of trust in the passport as 40 points, and the bank 52 can specify a policy where if the total point value exceeds a specific threshold, the user 51 is considered trustworthy.

[0050] Therefore, compared with the prior art, the embodiments of the present disclosure provide a brand-new security and trust scheme for user verification. Compared with the traditional PKI method, it relies on a centralized (trusted) certificate authority to issue digital certificates and sign them. The CA binds the public encryption key to the corresponding identity of the entity that owns (or at least controls) these keys. However, relying on a trusted CA (whether it is a hierarchical structure of CAs or a single entity) inherently involves a single point of failure. However, contrary to traditional PKI technologies, one or more embodiments of the present disclosure do not require relying on a centralized CA in order for a user to prove their identity to a verification entity.

[0051] In an alternative approach to PKI, the traditional decentralized Web of Trust (WoT) model attempts to address this centralized dependency problem. Instead, in WoT, other users within the network determine the trust level and assign it to an entity by binding / associating a key to a specific entity. As explained at https: / / en.wikipedia.org / wiki / Web_of_trust:

[0052] "OpenPGP-compliant implementations also include a voting count scheme that can be used to determine which public key-owner associations a user will trust when using PGP. For example, if three partially trusted endorsers have vouched for a certificate (and thus the included public key-owner binding), or if one fully trusted endorser has done so, then the association between the owner and the public key in that certificate will be considered correct. These parameters are user-adjustable (e.g., there may be no partial parameters at all, or perhaps six partial parameters), and can be bypassed entirely as needed."

[0053] Thus, in the prior art WoT approach, the key is associated with the entity that owns / controls it. In contrast, embodiments of the present disclosure enable the construction of a trust network in which a verifying entity assigns a trust level (e.g., via a point value) to different specific identity resources, rather than simply to their origin. Embodiments can be used to extend the traditional WoT such that verifying entities within the network can apply not only their own parameters to determine the degree of trust in an origin, but also the type, nature, and importance of identity-related resources (e.g., documents issued by other users). Thus, compared to traditional trust models for authentication (e.g., WoT or PKI), embodiments can provide different technical solutions.

[0054] Figure 7 The flowchart shows the steps performed by the logic, which may be implemented within a storage facility 53, such as in the business logic of a smart contract running on a blockchain 106.

[0055] In Figure 7 , at step 71, user 51( Figure 5 ) selects a set of 60( Figure 6 ) identity resources 61 - 65( Figure 6) for storage in storage facility 53. At step 72, the set is stored in storage facility 53. At step 73, user 51 shares an access credential with a verifying party (or verifying parties). At step 74, the verifying party implements a policy or a set of rules (e.g., by executing logic / code to evaluate the weights of members of the set of identity resources 60 and / or the connections between such members) to select one or more members of the set of identity resources. At step 75, the verifying party accesses the selected members of the set of identity resources from storage facility 53. Once the verifying party 52 accesses the selected members of the identity resources in the set from storage, the verifying party 52 can then review them manually or through computer automation to determine whether the verifying party is convinced that user 51 is the identity that user 51 claims to be.

[0056] As an example, the above bank environment will be discussed. User 51 wishes to open a bank account at bank 52. User 51 selects a set of identity resources, including a utility bill 61, a driver's license 62, a passport 63, a university degree certificate 64, and a bank statement 65, and stores the selected set of identity resources in storage facility 53 ( Figure 7 steps 71 and 72). For example, as discussed above, this can be achieved by storing data in a blockchain.

[0057] User 51 then shares an access credential with bank 52 (step 73). Bank 52 then applies a policy or a set of rules (step 74) by, for example, evaluating the weights of the members of the set 60 (or the weights of the connections between the members of the set 60) to select members of the set for review. For example, the bank can assign a high weight (85) to the passport 63 and a high weight 90 to the bank statement 65, thus indicating to the decoding logic (e.g., a smart contract) that bank 52 is required to review these two members of the set 60. Bank 52 then accesses the selected members of the set (the passport 63 and the bank statement 65) from storage facility 53 and reviews them to determine whether bank 52 is convinced that user 51 is the identity that user 51 claims to be.

[0058] Exemplary System Overview

[0059] A blockchain refers to a distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"), and the copy is widely public. The blockchain includes a series of data blocks, where each block includes one or more transactions. Except for the so-called "coinbase transaction", each transaction points to a previous transaction in the sequence, which can span one or more blocks and go back to one or more coinbase transactions. The coinbase transaction will be further discussed below. Transactions submitted to the blockchain network are included in new blocks. The process of creating new blocks is usually called "mining", which involves each of multiple nodes competing to perform a "proof-of-work", that is, solving a cryptographic puzzle based on a representation of a set of defined, ordered, and verified valid pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the release of blocks can be achieved by only releasing block headers.

[0060] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtual ledger or registry; receiving and processing timestamp entries; and / or sorting index pointers by time. Hierarchical additional functions on the blockchain can also be realized by leveraging the blockchain. For example, the blockchain protocol can allow additional user data or data indexes to be stored in transactions. There is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, audio, or video data in the blockchain.

[0061] In an "output-based" model (sometimes called UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element specifying an amount of digital assets, which can be derived from the ongoing sequence of transactions. A spendable output is sometimes called a UTXO ("unspent transaction output"). An output can also include a locking script that specifies the future redemption conditions of the output. A locking script is a predicate that defines the conditions necessary to verify and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a previous transaction, and can also include an unlocking script for unlocking the locking script pointing to the output. Thus, consider a pair of transactions, referred to as the first transaction and the second transaction (or "target" transaction). The first transaction includes at least one output specifying an amount of digital assets and includes a locking script defining one or more conditions for unlocking the output. The second (target) transaction includes at least one input and an unlocking script, where the at least one input includes a pointer to the output of the first transaction; the unlocking script is used to unlock the output of the first transaction.

[0062] In such a model, when the second (target) transaction is sent to a blockchain network for propagation and recording in the blockchain, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but may register an invalid transaction) nor include the transaction in a new block to be recorded in the blockchain.

[0063] Another transaction model is the account-based model. In this case, each transaction does not define the amount of the transfer by referring to the UTXOs of previous transactions in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is stored separately by nodes into the blockchain and is continuously updated.

[0064] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. System 100 can include a packet-switching network 101, typically a wide-area internet such as the Internet. The packet-switching network 101 includes a plurality of blockchain nodes 104 (commonly referred to as "miners"), which can be arranged to form a peer-to-peer (P2P) network 106 within the packet-switching network 101. Although not shown, the blockchain nodes 104 can be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0066] The blockchain 150 includes a series of data blocks 151, where a corresponding copy of the blockchain 150 is maintained at each of the multiple blockchain nodes 104 in the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, as long as each blockchain node 150 stores the block headers of each block 151 (discussed below), data pruning of the blockchain 150 can be performed. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A specific transaction protocol is used throughout a given blockchain.

[0067] The blockchain node 104 can be configured to forward the transaction 152 to other blockchain nodes 104, so that the transaction 152 propagates throughout the network 106. The blockchain node 104 can be configured to create a block 151 and store a corresponding copy of the same blockchain 150 in its corresponding memory. The blockchain node 104 can also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into the block 151. The ordered pool 154 is commonly referred to as the "mempool". In this article, the term is not intended to be restricted to any specific blockchain, protocol, or model. The term refers to an ordered set of transactions that the node 104 has accepted as valid, and for which the node 104 is forced not to accept any other transaction that attempts to spend the same output.

[0068] In a given current transaction 152j, the input (or each input) includes a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring a financial asset, although this is certainly a common application. More generally, spending can be described as consuming an output or allocating it to one or more outputs in another subsequent transaction. Typically, the previous transaction can be any transaction in an ordered set 154 or any block 151. Although a previous transaction 152i will need to exist and be verified as valid in order to ensure the validity of the current transaction, the previous transaction 152i does not have to exist at the time the current transaction 152j is created or even sent to the network 106. Thus, in this document, "previous" refers to a predecessor in a logical sequence linked by a pointer and not necessarily to a creation time or a send time in a time sequence, and thus does not necessarily rule out the case of unordered creation or sending of transactions 152i, 152j (see the discussion of orphan transactions below). The previous transaction 152i can equally well be referred to as a preceding transaction or a predecessor transaction.

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

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

[0071] Any given blockchain node can be configured to perform one or more of the following operations: verify transactions, store transactions, propagate transactions to other peers, perform consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, nodes can be specialized for a particular operation. For example, a node 104 can focus on transaction verification and propagation or can focus on block mining. In some examples, a blockchain node 104 can perform more than one of these operations in parallel. Any reference to a blockchain node 104 can refer to an entity configured to perform at least one of these operations.

[0072] The computer device 102 of each party 103 in the multi - party 103 playing the role of a consumer user is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in a transaction. Other users can interact with the blockchain 150 without having to act as a sender or receiver. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

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

[0074] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 also includes a memory, namely a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which employ one or more memory media, such as 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 computer device 102 of each party 103 stores software, which includes corresponding instances of at least one client application 105 configured to run on the processing device. It should be understood that any action attributed to a given party 103 herein can be performed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smartphone, or a wearable device such as a smartwatch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through the user terminal.

[0075] The client application 105 can initially be provided to the computer device 102 of any given party 103 through, for example, a suitable computer-readable storage medium downloaded from a server, or through a removable storage device such as a removable SSD, a flash drive, a removable EEPROM, a removable disk drive, a floppy disk, or a magnetic tape, an optical disk such as a CD or DVD ROM, or a removable optical disk drive.

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

[0077] Note: Although various client functions may be described as integrated into a given client application 105, this is not necessarily restrictive. Instead, any client function described herein may be implemented in a suite of two or more different applications, such as via API interface connection or one application as a plugin of another application. More generally, client functions may be implemented at the application layer or a lower layer such as an operating system or any combination of these layers. The following will be described in terms of client application 105, but it should be understood that this is not restrictive.

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

[0079] As part of an account-based transaction model, another type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol. In the account-based case, each transaction does not define the amount of transfer by referring to the UTXO of the previous transaction in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is separately stored in the blockchain by the nodes of the network and is continuously updated. In such a system, transactions are sorted using the running transaction record of the account (also referred to as "position" or "nonce"). This value is signed by the sender as part of its cryptographic signature and is hashed as part of the transaction reference calculation. In addition, optional data fields may also be signed in the transaction. For example, if the data field contains the ID of a previous transaction, the data field can point to the previous transaction.

[0080] Some account-based transaction models have some similarities with the output-based transaction model described herein. For example, as described above, the data fields of an account-based transaction can point to the previous transaction, which is equivalent to the input of an output-based transaction that references the output point of the previous transaction. Thus, both models support chaining between transactions. As another example, an account-based transaction includes a "recipient" field (where the receiving address of the account is specified) and a "value" field (where a certain amount of digital assets can be specified). Together, the recipient and value fields are equivalent to the output of an output-based transaction that can be used to allocate a certain amount of digital assets to a blockchain address. Similarly, an account-based transaction has a "signature" field that includes the signature of the transaction. The signature is generated using the sender's private key and confirms that the sender has authorized the transaction. This is equivalent to the input / unlock script of an output-based transaction, which typically includes the signature of the transaction. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contract" refers to a transaction that contains a script configured to perform one or more actions (e.g., send or "release" digital assets to a recipient address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined by the script of the smart contract. The smart contract exists as a transaction on the blockchain and can be called (or triggered) by a subsequent transaction. Thus, in some examples, a smart contract can be considered equivalent to the locking script of an output-based transaction (which can be triggered by a subsequent transaction) and checks whether the inputs of the subsequent transaction satisfy one or more conditions defined by the locking script.

[0081] 3. UTXO - based Model

[0082] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). It will be described below by reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that although an exemplary UTXO-based protocol is described with reference to Bitcoin, it can equally be implemented on other example blockchain networks.

[0083] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 can include an unspent transaction output (UTXO), which can be used as a source for an input 202 of another new transaction (if the UTXO has not been redeemed yet). The UTXO includes a value specifying the amount of digital assets. This represents a set of tokens on the distributed ledger. The UTXO can also contain the transaction ID of its source transaction and other information. The transaction data structure can also include a header 201, which can include size indicators for the input field 202 and the output field 203. The header 201 can also include the ID of the transaction. In an embodiment, the transaction ID is the hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the node 104.

[0084] For example, Alice 103a wishes to create a transaction 152j that transfers a relevant amount of digital assets to Bob 103b. In Figure 2 , Alice's new transaction 152j is labeled "Tx1". This new transaction obtains the amount of digital assets locked to Alice in the output 203 of a previous transaction 152i in the sequence and transfers at least a portion of such amount to Bob. In Figure 2 , the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels and do not necessarily mean that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to a subsequent transaction in the pool 154. Tx1 can point to any previous (i.e., antecedent) transaction that still has an unspent output 203 locked to Alice.

[0085] The terms "previous" and "subsequent" as used in the context of the transaction sequence herein refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They can equally be replaced by "predecessor" and "successor", "antecedent" and "descendant", or "parent" and "child", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (descendant transaction or "child transaction") that points to a previous transaction (antecedent transaction or "parent transaction") is not valid unless the parent transaction is valid. A child transaction that arrives at the blockchain node 104 before its parent transaction is considered an orphan transaction. Depending on the node protocol and / or node behavior, it can be discarded or buffered for a period of time to wait for the parent transaction.

[0086] One of one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of a subsequent transaction must satisfy in order for the subsequent transaction to be valid and thus successfully redeem the UTXO.

[0087] The locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "Script" (with a capital S), which can be used by the blockchain network. The locking script specifies the information required to consume the transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to meet the locking script criteria. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0088] Thus in the example shown, UTXO0 in output 203 of Tx0 includes a locking script [Checksig P A ], the locking script requires Alice’s signature Sig P A , in order to redeem UTXO0 (strictly speaking, to make subsequent transactions that attempt to redeem UTXO0 valid). A ] contains Alice's public key P from her public-private key pair A The input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in the embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes an index identifying UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlocking script <Sig P A >, the unlocking script includes Alice's cryptographic signature, which is created by Alice by applying the private key of her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0089] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria).

[0090] It should be noted that script code is typically represented diagrammatically (i.e., using non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to specific opcodes of the script language. For example, OP_RETURN is a script language opcode that, when prefixed with OP_FALSE at the start of a locking script, creates a non-consumable output of a transaction that can store data within the transaction, thereby immutably recording the data on the blockchain 150. For example, the data can include a file to be stored on the blockchain.

[0091] Typically, the input of a transaction contains a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific data segment. In an embodiment, for a given transaction, the signature will sign part of the transaction input as well as part or all of the transaction output. Signing a specific part of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that is used to select the output to be signed (and thus fixed at the time of signing).

[0092] The locking script is sometimes referred to as "scriptPubKey", meaning that it typically includes the public key of the party to which the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig", meaning that it typically provides the corresponding signature. However, more generally, in all applications of the blockchain 150, the conditions for UTXO redemption do not necessarily include verifying the signature. More generally, the script language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" can be preferably used.

[0093] 4. Side Channel

[0094] As Figure 1As shown, the client applications on each of the computer devices 102a, 120b of Alice and Bob can include additional communication functions. This additional function enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 enables data to be exchanged outside the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this can be used to exchange a transaction 152 between Alice and Bob without registering the transaction (yet) on the blockchain network 106 or publishing it on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing a transaction in this way is sometimes referred to as sharing a "transaction template". The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 can be used to exchange any other transaction-related data, such as keys, negotiation amounts or terms, data content, etc.

[0095] The side channel 107 can be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 can be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between the devices 102a, 102b of Alice and Bob. Generally, the side channel 107 referred to anywhere in this document can include any one or more links via one or more networking technologies or communication media for "off-chain" data exchange, i.e., data exchange outside the blockchain network 106. In the case of using multiple links, the off-chain link bundle or set as a whole can be referred to as the side channel 107. Therefore, it should be noted that if it is said that Alice and Bob exchange certain information or data, etc. via the side channel 107, this does not necessarily mean that all of this data must be sent through exactly the same link or even the same type of network.

[0096] 5. Client Software

[0097] Figure 3A An exemplary implementation of the client application 105 for implementing an embodiment of the present disclosure is shown. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. According to the solution discussed above and what will be further discussed in detail later, the transaction engine 401 is configured to implement the basic transaction-related functions of the client 105, such as formulating a transaction 152, receiving and / or sending transactions and / or other data via the side channel 301, and / or sending a transaction to one or more nodes 104 for propagation through the blockchain network 106.

[0098] The UI layer 402 is configured to present a user interface via the user input / output (I / O) means of the corresponding user's computer device 102, including outputting information to the corresponding user 103 via the user output means of device 102 and receiving input from the corresponding user 103 via the user input means of device 102. For example, the user output means may include one or more displays (touch or non-touch screens) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output, etc. The user input means may include, for example, an input array of one or more touch screens (which may be the same as or different from those for the output means); one or more cursor-based devices such as a mouse, a trackpad, or a trackball; one or more microphones and speech or voice recognition algorithms for receiving speech or voice input; one or more gesture-based input devices for receiving input in the form of manual or body gestures; or one or more mechanical buttons, switches, or joysticks, etc.

[0099] Note: Although the various functions herein may be described as integrated into the same client application 105, this does not necessarily constitute a limitation. On the contrary, they may be implemented in a suite of two or more different applications, for example, one application as a plugin of another application or interfaced via an API (Application Programming Interface). For instance, the functions of the transaction engine 401 may be implemented in a separate application rather than in the UI layer 402, or the functions of a given module such as the transaction engine 401 may be split among multiple applications. Also, it is not excluded that some or all of the described functions may be implemented, for example, at the operating system layer. In any case where a single or a given application 105 or the like is referred to herein, it should be understood that this is only by way of example, and more generally, the described functions may be implemented in any form of software.

[0100] Figure 3B A model of an example of a user interface (UI) 500 is given, which can be presented by the UI layer 402 of the client application 105a on Alice's device 102a. It should be understood that a similar UI can be presented by the client 105b on Bob's device 102b or on the devices of any other party.

[0101] By way of illustration, Figure 3B The UI 500 is shown from Alice's perspective. The UI 500 may include one or more UI elements 501, 502, 503, which are presented as different UI elements via the user output means.

[0102] For example, the UI elements may include one or more user-selectable elements 501, which may be different buttons on the screen, different options in a menu, or the like. The user input means is arranged to enable the user 103 (in this case, Alice 103a) to select or otherwise operate one of the options, such as by clicking or touching the UI element on the screen, or by saying the name of the desired option (note: the term "manual" used herein is only for comparison with automation and is not necessarily limited to performing operations with the hands).

[0103] Alternatively or additionally, the UI elements may include one or more data input fields 502. These data input fields are presented by means of user output, for example on the screen, and data may be input into the fields by means of user input, such as a keyboard or a touch screen. Alternatively, the data may be received orally, based on speech recognition or the like.

[0104] Alternatively or additionally, the UI elements may include one or more information elements 503 for outputting information to the user. For example, this / these may be presented on the screen or be audible. It should be understood that the specific manner of presenting the various UI elements, selecting options, and inputting data is not important. The functions of these UI elements will be discussed in more detail later. It should also be understood that the UI 500 shown in FIG. 3 is only an illustrative model and, in practice, it may include one or more further UI elements, which are not described for the sake of brevity.

[0105] 6. Node Software

[0106] Figure 4Shows an example of node software 450 running on each blockchain node 104 of network 106 in an example of a UTXO - based or output - based model. It should be noted that another entity can run node software 450 without being classified as a node 104 on network 106, i.e., without performing the actions required of node 104. Node software 450 can 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 collection of one or more blockchain - related functional modules 455. Each node 104 can run node software that includes one or more of the following: a consensus module 455C (e.g., proof - of - work), a propagation module 455P, and a storage module 455S (e.g., a database). The consensus module 455C can include a verification module (not shown) configured to verify transactions according to the blockchain protocol. The verification module can also be separate from the consensus module 455C. One or more of these modules can operate in parallel. Node 104 can include additional modules. The protocol engine 401 is generally configured to identify different fields of a transaction 152 and process such fields according to the node protocol. When a transaction 152j (Tx m-1 ) is received with an input having an output (e.g., UTXO) pointing to another previous transaction 152i (Tx j ), the protocol engine 451 identifies the unlocking script in Tx j and passes it to the script engine 452. The protocol engine 451 also identifies and retrieves Tx j based on the pointer in the input of Tx i . Tx i can be published on the blockchain 150, in which case the protocol engine can retrieve Tx i from a copy of the block 151 of the blockchain 150 stored at the node 104. Or, Tx i can also be published on the blockchain 150. In this case, the protocol engine 451 can retrieve Tx i from the set of unpublished ordered transactions 154 maintained by the node 104. In either case, the script engine 451 identifies the locking script in the referenced output of Tx i and passes it to the script engine 452.

[0107] Thus, the script engine 452 has the locking script of Tx i and the unlocking script from the corresponding input of Tx j . For example, in Figure 2Tx0 and Tx1 of the transaction marker are shown, but the same transaction can also be applied to any pair of transactions. As previously described, the script engine 452 runs two scripts together, which will include placing data onto the stack 453 and retrieving data from the stack 453 according to the stack-based scripting language used (e.g., the script).

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

[0109] In the output-based model, the result "TRUE" from the script engine 452 is one of the conditions for transaction validity. Generally, one or more further protocol-level conditions evaluated by the protocol engine 451 must also be met; for example, the total amount of digital assets specified in the input of Tx j does not exceed the total amount pointed to in its output, and the output pointed to by Tx i has not been consumed by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 and one or more protocol-level conditions, and only when they are all TRUE does the protocol engine verify that the transaction Tx j is valid. The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. Only under the condition that Tx j is indeed valid can the decision engine 454 choose to simultaneously control the consensus module 455C and the propagation module 455P to perform its corresponding blockchain-related functions for Tx j. . This includes the consensus module 455C adding Tx j to the corresponding ordered transaction set 154 of the node for incorporation into the block 151; and the propagation module 455P forwarding Tx j to another blockchain node 104 in the network 106. Optionally, in an embodiment, the application-level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may only choose to release a transaction if the transaction is valid and sufficient transaction fees are reserved.

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

[0111] 7. Further Comments

[0112] Once the disclosure of this document is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited by the described embodiments, but only by the appended claims.

[0113] For example, some of the above embodiments have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of the blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any reference to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 above can be replaced by references to a blockchain network 106, a blockchain 150, and a blockchain node 104, respectively. The blockchain, the blockchain network, and / or the blockchain node may share some or all of the characteristics described above for the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104.

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

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

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

[0117] Some embodiments have been described in terms of a blockchain network that is used to implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general embodiments, any type of suitable consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-past-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has the opportunity to produce the next block 151. The selected node is typically referred to as a validator. A blockchain node can lock its tokens for a period of time in order to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest time is most likely to become the next validator.

[0118] Enumeration Statement

[0119] It should be understood that the above embodiments are described only by way of example. More generally, a method, apparatus, or program can be provided according to any one or more of the following statements. Any feature provided for one set of statements is not limited thereto and can be incorporated into one or more other sets of statements.

[0120] According to one form of wording, embodiments of the present disclosure can provide methods and / or systems for verifying the identity of a user, confirming the identity of a user, and controlling access rights to controlled resources (such as services and / or physical / electronic resources). Additionally or alternatively, embodiments of the present disclosure can be described as providing security methods / systems / apparatuses, preferably for protecting access rights to controlled resources (such as services or physical / electronic resources). Additionally or alternatively, embodiments can be described as facilitating an improved Web of Trust (WoT) scheme (method, system, or apparatus).

[0121] In an additional or alternative form of wording, the present disclosure may provide: A computer-implemented verification method for verifying the identity of a user, the method comprising the following steps:

[0122] A verification entity selects or attempts to select at least one identity resource from a set of identity resources provided by the user to the verification entity for verifying the identity of the user;

[0123] Wherein the selection or attempt to select at least one identity resource from the set of identity resources is performed according to at least one rule or selection criterion established by the verification entity.

[0124] In some or more embodiments, corresponding weights may be assigned to one or more identity resources in the set of identity resources by the verification entity and / or according to the at least one rule or selection criterion. In other words, a weight or value may be assigned to each identity resource in the identity resource or multiple identity resources. This may be assigned by the verification entity.

[0125] Additionally or alternatively, weights may be assigned to the connection, association, or combination of at least two identity resources in the set of identity resources.

[0126] The verification entity may use the weights to confirm the identity of the user. This may involve (including) evaluating the weights or combined weights according to a threshold predetermined by the verification entity. If the weights or combined weights of the user's identity resources meet or exceed the threshold, the identity of the user may be considered verified; or if the threshold is not met, the identity of the user may be considered not verified.

[0127] Statement Set 1

[0128] According to a possible form of wording, embodiments of the present disclosure may provide:

[0129] 1. A computer-implemented method, the method comprising the following steps:

[0130] A verification entity attempts to select at least one identity resource from a set of identity resources provided by a user to the verification entity for verifying the identity of the user.

[0131] The attempt to select at least one identity resource from the set of identity resources may preferably be performed according to at least one (software-automated / enforced) rule or selection criterion established by the verification entity.

[0132] The verifying entity can be the owner, controller, and / or provider of the controlled resource. Before allowing the user to access the controlled resource, the verifying entity may need to successfully verify the identity of the user. The verifying entity can generate or use at least one rule, policy, and / or criterion to establish a successful verification of the user's identity. The at least one rule, policy, and / or criterion can specify what, how many, and / or what type of identity resources are required for a successful verification of the identity of the user (or the user), or any other criteria related to the identity resources determined by the verifying entity to be relevant for the purpose of verification. Additionally or alternatively, the at least one rule, policy, and / or criterion can specify which identity resources can be combined to meet the requirements of the verifying entity for a successful identity verification. To facilitate this, corresponding weights or values or "points" can be assigned to different types, formats, or other parameters related to the identity resources. The at least one rule, policy, and / or criterion can specify a threshold or number of points that must be reached by selecting one identity resource or a combination of identity resources from the set of identity resources in order to ensure a successful identity verification. The at least one rule, policy, and / or criterion can specify the minimum or maximum number of identity resources that can be combined to reach the threshold. If the verifying entity is unable to select the required number, type, or other form of identity resources from the set of identity resources to reach the threshold, the attempt to verify the identity of the user will be rejected and considered a failure.

[0133] The set of identity resources can be selected and / or generated by the user. The user can provide the set of identity resources to the verifying entity by providing the set of identity resources in or on a storage facility. The storage facility can be a blockchain. The set of identity resources can be managed by a digital wallet. When the action is expressed as being "performed by the user", this can mean that the user performs the action himself, for example via an interface of a software component or system, or the action is automatically performed by a software system / component owned / controlled / operated by the user, and the action is performed on behalf of the user via the system / component.

[0134] The user and / or the verifying entity can be an actor or participant in a trust network and / or a public key infrastructure (PKI) setup / implementation / system.

[0135] The user can provide the set of identity resources to the verifying entity by sharing access credentials with the verifying entity.

[0136] The access credentials:

[0137] i) may include one or more of the following: password, PIN, passcode, or other identifier; or an encryption key; and / or

[0138] ii) may be generated by the user; and / or

[0139] iii) may be associated with the verification entity or assigned by the user to the verification entity.

[0140] The user may provide the set of identity resources to the verification entity by using a blockchain. The set of identity resources may be included on the blockchain or referenced from a transaction on the blockchain. The at least one rule or selection criterion may be implemented in a smart contract configured to execute on and / or interact with the blockchain.

[0141] The at least one rule or selection criterion may be implemented in software logic.

[0142] In some embodiments, a respective weight may be assigned to one or more of the identity resources in the set of identity resources. The weight may alternatively be referred to as a value or points. The weight of a given identity resource may be determined by the verification entity. Additionally or alternatively, the weight may be determined according to the at least one rule or selection criterion and / or implemented as part of the software logic for the at least one rule or selection criterion. A weight, value, or "points" may be assigned to a connection, association, or combination of at least two of the identity resources in the set of identity resources. The weight may be used to determine the at least one identity resource to be selected from the set of identity resources according to the at least one rule or selection criterion.

[0143] If no identity resource can be selected from the set of identity resources according to the at least one rule or selection criterion, the verification entity may reject verifying the identity of the user. The method may include the step of attempting to verify the identity of the user by using the at least one identity resource selected from the set of identity resources.

[0144] At least one identity resource in the set of identity resources can be signed, encoded, protected, or otherwise associated with an encryption key. The encryption key can be owned, controlled, or associated with the issuing entity of the at least one identity resource. The encryption key can be part of a key pair. The encryption key can be a private key. The verification entity can use the corresponding encryption key (e.g., the public key corresponding to the private encryption key) to verify / check whether the at least one identity resource has been effectively issued by the (authorized, legitimate) issuing entity. The issuing entity, the verification entity, and / or the user can be actors or participants in a trust network or PKI.

[0145] The method can include the following steps: if the verification of the user's identity is rejected, access to the controlled resource is denied; or if the verification of the user's identity is successful, access to the controlled resource is allowed.

[0146] The set of identity resources can be selected and / or generated by the user as a subset of a larger set of identity resources. This can be performed according to at least one (automated) rule, policy, or criterion of the user application or a software component controlled / owned / operated by the user. For example, the user can determine that a document including the user's social security number can only be provided to a verification entity that is a government agency; or a degree certificate can only be provided to an academic institution or a potential employer for identity verification purposes. Additionally or alternatively, the user can temporarily specify which specific verification entities can access one, part, or all of the identity resources in the user's set of identity resources. This selection of the set of identity resources can be specified by the user himself via an interface of the user's software component (e.g., a digital wallet).

[0147] The method can include the following steps: the user removes at least one identity resource from the set of identity resources. The user can remove one or more resources from the set based on various criteria (e.g., date, privacy issues, etc.). Thus, the user can revoke an identity resource.

[0148] There can also be provided: a computer device, the computer device including:

[0149] a memory, the memory including one or more memory units; and

[0150] a processing device, the processing device including one or more processing units, wherein the memory stores code configured to run on the processing device, and the code is configured to, when running on the processing device, execute the method according to any embodiment claimed or disclosed herein.

[0151] There can also be provided: a computer program, the computer program being included on a computer-readable memory and configured to, when run on one or more processors, perform the method according to any of the embodiments claimed or disclosed herein.

[0152] Statement Set 2

[0153] According to alternative wording, there can be provided:

[0154] A computer-implemented method, the computer-implemented method comprising the steps of: receiving, from a user, a set of identity resources for proving or confirming the identity of the user to a verification entity.

[0155] The terms “prove” and / or “verify” can be used instead of “establish”.

[0156] The set of identity resources can include one or more identity resources. Thus, in some embodiments, the set of identity resources can include multiple identity resources, while in other embodiments, the set of identity resources can include only one identity resource.

[0157] The method can include the step of: providing one or more of the identity resources in the set of identity resources in a storage facility. The terms “register”, “upload” and / or “store” can be used instead of “provide”.

[0158] The method can include the step of: identifying and / or selecting at least one of the identity resources in the set of identity resources according to selection criteria established by the verification party. The terms “determine”, “select” and / or “designate” can be used instead of “establish”.

[0159] The method can include the step of: providing the verification entity with access to the selected at least one of the identity resources in the set of identity resources by sharing access credentials with the verification entity.

[0160] The storage facility can include a blockchain. The set of identity resources provided in the storage facility can be managed by a software resource such as a digital wallet. The access credentials can be specific to the verification entity. In other words, the access credentials can be (by the user) associated only with the verification entity.

[0161] The method may include one or more steps, where a set of rules or policies is received from a verification entity. The set of rules may be set to allow or enable the selection of one or more identity resources from the set of identity resources. In an embodiment where the storage facility is a blockchain, the set of rules or policies may be implemented in a smart contract that is set to execute on or associated with the blockchain, or implemented using the smart contract.

[0162] The set of rules or policies may be implemented in software logic, preferably where a weight is assigned to each connection between two of the identity resources in the set of identity resources, and such weights are used to determine which of the identity resources in the set of identity resources are to be selected.

[0163] The set of rules or policies may be implemented in software logic, where a weight is assigned to each of the identity resources in the set of identity resources, and such weights are used to determine which of the identity resources in the set of identity resources are to be selected.

[0164] Statement Set 3

[0165] According to additional or alternative wording, it may be provided that:

[0166] A computer-implemented method, the method comprising the steps of:

[0167] Generating and / or selecting a set of identity resources; and / or

[0168] Providing one, part, or all of the identity resources in the set of identity resources on or in a storage facility.

[0169] In some embodiments, the storage facility may be a blockchain.

[0170] The method may further include the step of: providing access to at least a portion of the set of identity resources to a verification entity.

[0171] The set of identity resources may be generated or selected by the user.

[0172] The method may further include the following steps: determining at least one rule or criterion for verifying / validating the identity of the user. The at least one rule or criterion may relate to or (be applied by the verification entity) to one or more identity resources provided by the user. The method may include the following steps: selecting or attempting to select one or more identity resources from the set of identity resources provided by the user according to the at least one rule or criterion. At least one of the identity resources may be registered on a blockchain or other storage facility. At least one of the identity resources may be provided within a transaction on the blockchain or referenced by / from the transaction.

[0173] Statement Set 4

[0174] According to alternative wording, it may be provided that:

[0175] A computer-implemented method, the method including the following steps: providing or using a trust network.

[0176] The user and / or verification entity as described above may be a user or participant in the trust network. The method may further include one or more features described in any one or more of Statements 1 to 3.

[0177] The method may further include:

[0178] i) The verification entity attempts to select at least one identity resource from the set of identity resources provided by the user to the verification entity for verifying the identity of the user; and / or

[0179] ii) receiving from the user a set of identity resources for proving or confirming the identity of the user to the verification entity; and / or

[0180] generating and / or selecting a set of identity resources; and / or

[0181] providing one, part or all of the identity resources in the set of identity resources on or in a storage facility; preferably, the storage facility may be a blockchain; and / or

[0182] iii) providing the verification entity with access to at least a part of the set of identity resources; preferably where the set of identity resources may be generated or selected by the user; and / or

[0183] iv) determining at least one rule or criterion for verifying / validating the identity of the user; preferably, the at least one rule or criterion may relate to or (be applied by the verification entity) to one or more identity resources provided by the user; and / or

[0184] v) Select or attempt to select one or more identity resources from the set of identity resources provided by the user according to the at least one rule or criterion.

[0185] One or more of Statements 1 to 4 may include the following steps:

[0186] i) Sign, encode, or protect a given identity resource or a certificate associated with the identity resource using a (private) encryption key. This may be performed by or on behalf of the issuing entity that has issued, generated, and / or provided the identity resource. The encryption key may be a private key having a corresponding public key; the public-private key pair may be associated with, owned by, and / or controlled by or on behalf of the issuing entity.

[0187] ii) Use a (public) encryption key to check the signature used to sign a given identity resource, decode the encoded identity resource, and / or otherwise verify that the corresponding (private) key has been used to sign, encode, or otherwise protect the identity resource.

[0188] The public key may be obtained from the issuing entity associated with the identity resource and / or from a trust network.

[0189] According to another aspect disclosed herein, a computer program may be provided, the computer program being contained on a computer-readable memory and configured to, when run on one or more processors, execute the method according to any of the embodiments disclosed and / or claimed herein.

[0190] According to another aspect disclosed herein, a system may be provided, the system including a computer device having a memory including one or more memory units; and a processing device including one or more processing units, wherein the memory stores code configured to run on the processing device and configured to, when run on the processing device, execute the method according to any of the embodiments disclosed and / or claimed herein.

Claims

1. A computer-implemented verification method for verifying the identity of a user, the method comprising the following steps: selecting or attempting to select at least one identity resource from a set of identity resources provided by the user to the verification entity for verifying the identity of the user by the verification entity; wherein selecting or attempting to select at least one identity resource from the set of identity resources is performed according to at least one rule or selection criterion established by the verification entity; and i) assigning corresponding weights to one or more identity resources in the set of identity resources by the verification entity and / or according to the at least one rule or selection criterion; and / or ii) assigning weights to the connection, combination, or association of at least two identity resources in the set of identity resources.

2. The method according to claim 1, wherein: the user provides the set of identity resources to the verification entity by providing the set of identity resources in or on a storage facility.

3. The method according to any one of the preceding claims, wherein: i) the storage facility is a blockchain; and / or ii) the set of identity resources is managed by a digital wallet; and / or iii) the user and / or the verification entity is an actor or participant in a trust network or a public key infrastructure.

4. The method according to any one of the preceding claims, wherein: the user provides the set of identity resources to the verification entity by sharing an access credential with the verification entity; preferably, wherein the access credential: i) includes one or more of the following: a password, a PIN, a cryptographic key, or other identifier; or an encryption key; and / or ii) is generated by the user; and / or iii) is associated with the verification entity or assigned to the verification entity by the user.

5. The method according to any one of the preceding claims, wherein: i) the user provides the set of identity resources to the verification entity by using a blockchain, preferably wherein the set of identity resources is included in the blockchain or referenced from a transaction on the blockchain; and / or ii) the at least one rule or selection criterion is implemented in a smart contract configured to execute on and / or interact with the blockchain.

6. The method according to any one of the preceding claims, wherein: i) at least one identity resource in the set of identity resources is signed, encoded, protected, or otherwise associated with an encryption key owned, controlled, or associated with the issuing entity of the at least one identity resource; and ii) the verification entity performs the step of verifying whether the at least one identity resource has been effectively issued by the issuing entity by using the corresponding encryption key.

7. The method according to any one of the preceding claims, wherein: the at least one rule or selection criterion is implemented in software logic, and preferably wherein the weights are used to determine the at least one identity resource to be selected from the set of identity resources according to the at least one rule or selection criterion.

8. The method according to any one of the preceding claims, wherein: if an identity resource cannot be selected from the set of identity resources according to the at least one rule or selection criterion, the verification entity rejects verification of the identity of the user.

9. The method according to any one of the preceding claims, the method comprising the steps of: attempting to verify the identity of the user using the at least one identity resource selected from the set of identity resources.

10. The method according to claim 9, the method comprising the steps of: if verification of the identity of the user is rejected, access to the controlled resource is rejected; or if verification of the identity of the user is successful, access to the controlled resource is permitted.

11. The method according to any one of the preceding claims, wherein: the set of identity resources is selected and / or generated by the user.

12. The method according to any one of the preceding claims, wherein: the set of identity resources is selected and / or generated by the user as a subset of a larger set of identity resources.

13. The method according to any one of the preceding claims, the method comprising the steps of: the user removes at least one identity resource from the set of identity resources.

14. A computer device, the computer device comprising: a memory, the memory comprising one or more memory units; and a processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to run on the processing device and, when run on the processing device, to perform the method according to any one of claims 1 to 13.

15. A computer program, the computer program being embodied on a computer-readable memory and configured to, when run on one or more processors, perform the method according to any one of claims 1 to 13.

Images