Methods and systems for providing token identity

Abstract

A method for facilitating permission-based cryptographic transactions between service providers includes: receiving an onboarding request from a first computing system, the onboarding request including permission data and an identification value, the identification value being associated with a first blockchain wallet; generating a permission token and an alias based on the permission data, the permission token including a verified identity data point; sending the generated alias to the first computing system in response to the onboarding request; receiving a token request from a second computing system, the token request including the alias; and sending the generated permission token and the identification value to the second computing system in response to the token request.

Description

Technical Field

[0001] This disclosure relates to providing token identities, specifically to the use of permission tokens, and assists in cryptographic transactions between service providers that comply with identity verification requirements without the need to transmit or exchange personally identifiable information.

[0002] Cross - Reference to Related Applications This application claims the benefit and priority of U.S. Provisional Patent Application No. 63 / 406,521, filed on September 14, 2022. The entire disclosure of the above application is incorporated herein by reference.

Background Art

[0003] Blockchains were originally created to provide a platform for trading cryptocurrencies. Two main principles when blockchains were created are that the blockchain itself is completely decentralized and stored and managed on a vast group of computing systems, and that cryptocurrency transactions are conducted with complete anonymity, such that participants are not required to provide identification information and all transactions between blockchain wallets are made independent of ownership. Due to these two principles, blockchains have been widely adopted and are used in the creation and management of a vast number and variety of cryptocurrencies.

[0004] However, the popularity of blockchain, combined with its decentralization and anonymity, has led to a massive amount of fraud in crypto transactions, with consumers losing over $1 billion in the US alone in 2021. The lack of a central authority to regulate transactions puts users at a disadvantage, anonymity means victims receive little redress, and it is difficult to crack down on and stop fraudulent activities. To combat fraudulent activity, many countries have established policies, regulations, and requirements regarding the identity verification of blockchain participants, as well as rules concerning participants in blockchain transactions.

[0005] To comply with these new policies and regulations, virtual asset service providers (VASPs) that operate cryptocurrency exchanges or blockchain wallets on behalf of participants perform identity verification processes for those participants. However, since a large portion of crypto transactions are conducted between participants using different VASPs, each VASP is required to verify the identity of other users transacting with its participants, which can be a difficult process, and also involves the disclosure of personally identifiable information (PII) of participants and other users to other VASPs. Furthermore, a significant number of crypto transactions are conducted between participants in different countries, each with its own applicable policies and regulations. Therefore, VASPs are not only compelled to verify the identity of other users in their participants' transactions, but also to verify that both their participants and other users comply with applicable regulations in other countries, and VASPs may not be familiar with this.

[0006] As a result, the current system requires all VASPs to be familiar with the regulations that may apply in all countries where participants are located in order to ensure compliance with applicable regulations, and also requires all VASPs to be able to easily exchange users' PII, which can be a considerably difficult, time-consuming, and costly task, and can significantly increase the chances of users' PII being compromised. Therefore, there is a need for a technical solution that ensures compliance with crypto transactions without involving the exchange of PII and without requiring VASPs to be familiar with the applicable regulations in all potential trading countries. [Overview of the Initiative]

[0007] This disclosure provides a description of a system and method for facilitating permission-based cryptographic transactions between service providers. A new user of the blockchain can verify their identity through their virtual asset service provider (VASP) and interact with the blockchain through the VASP. The VASP can verify the user's identity and any aspects of it that may be applicable under regulations concerning cryptographic transactions. The VASP can register a user with a token identity service by providing data points regarding verified user identity attributes. The token identity service can generate permission tokens for the user based on their verified user identity attributes and return aliases to the VASP that the user can use when participating in cryptographic transactions. When conducting a transaction, the user can provide their alias to the other party. The other party can provide their alias to their VASP if they wish to receive or send cryptocurrency from the user. The other party's VASP can provide an alias to the token identity service, in which case a permission token for the user can be returned. The permission token contains all the information necessary for the other party's VASP to ensure that the user has been properly verified to satisfy any applicable regulations known to the other party's VASP. The other party's VASP can then submit a new cryptocurrency transaction to the blockchain, demonstrating full compliance, and no PII has been exchanged for any participant; each VASP only needs to verify the identity of its own user.

[0008] A method for facilitating permission-based cryptographic transactions between service providers includes: a receiver of a processing server receiving an onboarding request from a first computing system, the onboarding request comprising at least permission data and an identification value, wherein the identification value is associated with a first blockchain wallet with respect to a blockchain associated with a blockchain network; a processor of the processing server generating a permission token and an alias based at least the permission data, wherein the permission token comprises one or more verified identity data points; a transmitter of the processing server transmitting the generated alias to the first computing system in response to the received onboarding request; a receiver of the processing server receiving a token request from a second computing system, wherein the token request comprises the alias; and a transmitter of the processing server transmitting at least the generated permission token and the identification value to the second computing system in response to the received token request.

[0009] A system for facilitating permission-based cryptographic transactions between service providers includes: a blockchain network, a first computing system, a second computing system, and a processing server, the processing server comprising: a receiver that receives an onboarding request from the first computing system including at least permission data and an identification value, wherein the identification value is associated with a first blockchain wallet relating to a blockchain associated with the blockchain network; a processor that generates a permission token and an alias based on at least the permission data, wherein the permission token includes one or more verified identity data points; and a transmitter that, in response to the received onboarding request, transmits the generated alias to the first computing system, wherein the receiver of the processing server receives a token request from the second computing system, wherein the token request includes the alias, and the transmitter of the processing server, in response to the received token request, transmits at least the generated permission token and the identification value to the second computing system. [Brief explanation of the drawing]

[0010] The scope of this disclosure, when interpreted in conjunction with the accompanying drawings, will be best understood from the following detailed description of exemplary embodiments. The drawings include the following figures:

[0011] [Figure 1] This is a block diagram illustrating a high-level system architecture for facilitating permission-based cryptographic transactions, according to an exemplary embodiment. [Figure 2] This is a block diagram showing a processing server in the system of Figure 1 that facilitates permission-based cryptographic transactions according to an exemplary embodiment. [Figure 3A]This flowchart illustrates a process for facilitating permission-based cryptographic transactions between service providers within the system shown in Figure 1, according to an exemplary embodiment. [Figure 3B] This flowchart illustrates a process for facilitating permission-based cryptographic transactions between service providers within the system shown in Figure 1, according to an exemplary embodiment. [Figure 4] This flowchart illustrates an exemplary method for facilitating permission-based cryptographic transactions between service providers, according to an exemplary embodiment. [Figure 5] This block shows a computer system architecture according to an exemplary embodiment.

[0012] Further application areas of this disclosure will be obvious from the detailed description below. The detailed description of exemplary embodiments is for illustrative purposes only and is not intended to necessarily limit the scope of this disclosure. [Modes for carrying out the invention]

[0013] A system for permission-based cryptographic transactions Figure 1 illustrates a system 100 that facilitates permission-based cryptographic transactions on a blockchain, in a manner that satisfies compliance with any applicable regulations and without the exchange of personally identifiable information (PII). System 100 may include a processing server 102, detailed below, which can operate a token identity service to facilitate permission-based transactions. System 100 may also include a blockchain network 104. The blockchain network 104 may consist of a plurality of blockchain nodes 106. Each blockchain node 106 may be a computing system, as detailed below, as shown in Figure 2 or Figure 5, configured to perform functions related to the processing and management of the blockchain, which may include, for example, generating blockchain data values, verifying proposed blockchain transactions, verifying digital signatures, generating new blocks, validating new blocks, and maintaining copies of the blockchain. In some embodiments, the processing server 102 may be a blockchain node 106 in the blockchain network 104.

[0014] A blockchain can be a distributed ledger comprising at least several blocks. Each block may contain at least a block header and one or more data values. Each block header may contain at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time the block header was generated and can be represented using any suitable method (e.g., UNIX timestamp, DateTime notation). The block reference value may be a value that references a preceding block in the blockchain (e.g., based on the timestamp). In some embodiments, the block reference value in the block header may be a reference to the block header of the most recently added block preceding each block. In an exemplary embodiment, the block reference value may be a hash value generated by hashing the block header of the most recently added block. Similarly, the data reference value may be a reference to one or more data values ​​stored within the block containing the block header. In an exemplary embodiment, the data reference value may be a hash value generated by hashing one or more data values. For example, the block reference value may be the root of a Merkle tree generated using one or more data values.

[0015] The use of block reference values ​​and data reference values ​​within each block header can give the blockchain immutability. Attempting to change a data value requires the generation of a new data reference value for that block, which in turn requires the generation of a new block reference value for the subsequent block, and further requires the generation of a new block reference value for each subsequent block. To make the change permanent, the above steps must be performed and updated for each blockchain node 106 within the blockchain network 104 before the generation of a new block and its addition to the blockchain. Due to the limitations of computing and communication capabilities, such changes can be extremely difficult or impossible, and therefore the blockchain acquires immutability.

[0016] In some embodiments, a blockchain can be used to store information about blockchain transactions made between two different blockchain wallets. A blockchain wallet may contain the private key of a cryptographic key pair, which is used to generate a digital signature, which may serve as an authorization of the payer for a blockchain transaction, and which can be verified by each blockchain network 104 using the public key of the cryptographic key pair. In some cases, the term “blockchain wallet” may specifically refer to the private key. In other cases, the term “blockchain wallet” may refer to a computing device (e.g., user device 108a, service provider 110a, etc.) that stores the private key for use in blockchain transactions. For example, each computing device may have its own private key for its respective cryptographic key pair, and each may be a blockchain wallet for use in transactions with a blockchain associated with a blockchain network. The computing device can be any type of device suitable for storing and utilizing a blockchain wallet, such as a desktop computer, laptop computer, notebook computer, tablet computer, mobile phone, smartphone, smartwatch, smart TV, wearable computing device, embedded computing device, etc.

[0017] Each blockchain data value stored within the blockchain may appropriately correspond to the storage of a blockchain transaction or other data. A blockchain transaction may comprise at least the following: a digital signature of the sender (e.g., user device 10b, service provider 110b, etc.) generated using the sender's private key, the recipient's blockchain address of the currency generated using the recipient's public key, and the amount of blockchain currency to be transferred or other data to be stored. In some blockchain transactions, the transaction may also include: one or more sender blockchain addresses where the blockchain currency is currently stored (e.g., where access to such currency is verified by a digital signature); and an address generated using the sender's public key for any changes to be held by the sender. The address to which cryptocurrency usable in a future transaction has been sent is called an "output" address because each address was previously used to capture the output of a preceding blockchain transaction, and this is also called an "unspent transaction" because there is currency to be sent to the address in a preceding transaction in which the currency is still unspent. In some cases, a blockchain transaction may also include a sender's public key for an entity to use to validate the transaction. For the traditional processing of a blockchain transaction, such data may be provided to a blockchain node 106 in the blockchain network 104 by either the sender or the recipient. The node can verify the digital signature using the public key in the sender's wallet's cryptographic key pair and can also verify access to the sender's funds (for example, if an unspent transaction has not yet been consumed and has been sent to an address associated with the sender's wallet), which is known as the "confirmation" process of the transaction and also includes the blockchain transaction in a new block.In traditional blockchain implementations, new blocks may be validated by other blockchain nodes 106 within the blockchain network 104 before being added to the blockchain and distributed to all blockchain nodes 106 within the blockchain network 104. If the blockchain data value is not related to a blockchain transaction but instead to the storage of other types of data, the blockchain data value may still include or involve digital signature validation.

[0018] System 100 may include the user devices 108 shown in Figure 1 as a first user device 108a and a second user device 108b. Each user device 108 can be a device utilized by a participant in the blockchain associated with the blockchain network 104 and can perform functions associated with the blockchain. In System 100, participants in the blockchain can interact with the blockchain via a service provider 110. The service provider 110 can directly interact with the blockchain node 106 on behalf of the participant to provide the participant with convenience, value-added services, security, etc. In some cases, the service provider 110 can store the keys of the blockchain wallet associated with the participant (similar to how a bank maintains accounts used by customers). In other cases, the user device 108 can hold the private key for its own blockchain wallet, and communication can proceed to the blockchain network 104 via the service provider 110. In the industry, the service provider 110 may also be referred to as a "virtual asset service provider" or "VASP". In some cases, each participant in a transaction may utilize a different service provider 110. In other cases, both participants in a transaction can utilize the same service provider 110.

[0019] In System 100, cryptographic transactions performed using the blockchain may be subject to one or more policies, regulations, requirements, constraints, etc., collectively referred to herein as regulations. Regulations can be set by the blockchain network 104, service providers 110, government agencies, financial institutions, standardization bodies, or other appropriate entities. Regulations can be applied to any aspect of a transaction or any aspect of the individuals involved in a transaction. For example, a state may require that any person conducting a cryptographic transaction within its territory verify the identity of that person. Another example is that for transactions involving certain types of goods (e.g., alcohol), it may be required that both parties to the transaction have reached a certain age. In some cases, regulations may be applied to one of the participants in a transaction (e.g., location-specific regulations that apply only to participants within a location). In other cases, regulations may be applied to both participants in a transaction, and rules may be applied to both parties to a transaction in order to satisfy applicable regulations, for example, if a country requires both participants in a transaction to comply even if only one participant is located within its territory.

[0020] To ensure compliance with applicable regulations, each service provider 110 traditionally identifies all applicable regulations and performs all necessary verifications for each participant to verify compliance. To accomplish this task, service provider 110 can exchange PII with respect to participants, for example, so that service provider 110b can verify the identity of a participant behind user device 108a. Each time a participant makes a transaction with another participant using a different service provider 110, that participant's PII is provided to the new service provider 110, resulting in that participant's PII being disseminated across numerous systems through numerous transfers, significantly increasing the likelihood of their data being compromised.

[0021] To address these challenges and enable service provider 110 to focus solely on its participants, processing server 102 can provide a token identity service using permission tokens to quickly and accurately provide information regarding regulatory compliance. In system 100, when a new participant in the blockchain registers with service provider 110, service provider 110 verifies the participant's identity and collects any other appropriate information that may be necessary for compliance with any potential regulations. Service provider 110 can verify identity and other data using any appropriate method. Verified data (also referred to as verified identity data points or verified identity attributes) can be acquired and stored by service provider 110 in any appropriate manner, such as complying with any regulations applicable to the storage of PII or other identity data. Identity attributes may include any attributes relating to regulations applicable to cryptographic transactions, such as the level of identity verification (e.g., identification by name, identification by photograph, identity verification by multiple types, etc.), age, geographical location, income, and compliance with regulatory authorities. For example, service provider 110 can verify a participant's identity and age through their driver's license and remember attributes indicating the participant's age and that their identity has been successfully verified by their state government. In another example, service provider 110 can verify a participant's identity and age through their central government (e.g., through their passport) and their geographical location through their state government, and remember attributes indicating that their identity and age have been verified at the central level and their location at the state level.

[0022] Once the service provider 110 verifies the participant's identity attributes, the participant can be registered with the token identity service via the processing server 102. In some cases, the communication with the processing server 102 can be performed by the service provider 110 on behalf of the participant. In other cases, the participant can communicate directly with the processing server 102 using their user device 108. In such cases, the participant can provide information identifying the service provider 110 whose identity has been verified. The registration of the participant with the processing server 102 can include not only the transmission of permission data within the verified identity attributes, but also the transmission of identification information regarding the blockchain wallet associated with the identity attributes. In some cases, the identification information can be the public key of the blockchain wallet. In other cases, the identification information can be a unique value suitable for use by the service provider 110 in identifying the participant and their stored data.

[0023] The processing server 102 can receive verified identity attributes and identification information regarding the participant. When the processing server receives registration data from the user device 108, the processing server 102 can identify the service provider 110 using the provided information to verify or request verified user identity attributes. In an exemplary embodiment, the processing server 102 can receive only the attributes without any PII regarding the participant. For example, the attributes can include that the participant's identity has been double-verified at a central level (without any information regarding that identity).

[0024] After receiving the attributes, the processing server 102 can generate a permission token for the participant. The permission token can be a digital token that includes the attributes in a standardized format and can include fields for any identity attributes necessary to ensure compliance with applicable regulations. For example, the permission token can include separate data fields for identity verification for multiple levels and each country, as well as data fields for income, age, state, city, country, education level, etc. If attribute data has not been provided to the processing server 102 for such fields, the fields can be left blank or null. In some cases, the permission token can include fields indicating compliance with identity requirements in each country where blockchain participants are included. For example, in the case of participants from 20 countries, the permission token can include fields indicating compliance or non - compliance with the regulations of each of those 20 countries. The processing server 102 can be configured to determine compliance based on the regulations of each country and the supplied identity attributes. In some cases, the processing server 102 can be configured to determine compliance with any regulations that can be imposed or presented by any appropriate entity, such as a financial institution, a standardization institution, etc. For example, the service provider 110 can verify the identity of a participant at a level suitable for US regulations but not suitable for EU regulations. In such a case, the permission token for that participant can indicate compliance for the US and non - compliance for the EU.

[0025] In addition to permission tokens, the processing server 102 can generate aliases for participants. These aliases are unique to each participant and can be directly associated with the participant's permission token, and can be used to identify participants and their permission tokens among service providers 110. The processing server 102 can return the alias to the user device 108 (for example, directly or via a service provider 110). A participant can then send their alias to another participant via their own user device 108 and the user devices 108 of other participants if a new transaction is desired. In some cases, a participant can request a specific alias during the registration process. In some embodiments, a participant can link their alias across multiple service providers 110. For example, a participant may have three different blockchain wallets managed by three different service providers 110, and can register with the processing server 102 (for example, via their own user device 108) to associate their alias with all three blockchain wallets. In such embodiments, participants can choose which blockchain wallet to use for sending and receiving currency for a particular transaction. In some cases, the alias may include a subsection or component that indicates a service provider. For example, participant Jane may request "jane" as her alias, and the service provider to be used for the transaction may be indicated in part of the full alias, for example, jane.vaspone.tokenservice for the first service provider 110, and jane.vasptwo.tokenservice for the second service provider 110. In these embodiments, participants can deactivate one or more blockchain wallets for use in future crypto transactions and / or remove blockchain wallets from their accounts entirely.

[0026] If the processing server 102 can provide a single participant with multiple blockchain wallets linked via its alias, such data can be stored in the following example format: - accountAlias:ACC55059970032193496 Status: ACTIVE crypto-addresses: - cryptoAddressId:52c3837d-cf45-4830-b1cf-60f2616bfa04 Status: ACTIVE asset:BTC blockchainAddress:mu692DY2GwYXbWdv3wUsQRr6nXsYW8QRsm - cryptoAddressId:52c3837d-cf45-4830-b1cf-60f2616bfa05 Status: ACTIVE asset: ETH blockchainAddress:'0x46Be1B5b35708e369b943CE6094c6f0484d480A7' createdDate:'2022-03-20T09:12:28-05:00' updatedDate:'2022-03-20T12:18:36-05:00'

[0027] In this example, for a participant with an alias of ACC55059970032193496 (which may be a hash of an alias issued to the participant or mapped to an issued alias), two blockchain wallets are registered in processing server 102 for use with the alias, one using BTC and the other using ETC. Both are active as shown in the profile and therefore can be used to send and receive currency using the provided addresses.

[0028] In an example transaction, Alice, the first participant located in the United States, can use her first user device 108a to have her identity verified by the first service provider 110a, register it with the token identity service, and receive the alias alias.usa.tokenservice. Bob, the second participant located in Canada, uses the second service provider 110b to interact with the blockchain and intends to purchase 10 units of cryptocurrency from an item listed by Alice via a cryptographic transaction on the blockchain. To receive payment, Alice can provide her alias to Bob by sending it from her first user device 108a to Bob's second user device 108b. Bob can then submit a request to the second service provider 110b via his second user device 108b and send 10 units of cryptocurrency to the alias alice.tokenservice. The second service provider 110b can send a request for Alice's permission token to the processing server 102 via an appropriate communication network and method by including the alias alice.usa.tokenservice.

[0029] Processing server 102 can receive the alias and identify the permission token associated with it. Processing server 102 can then electronically transmit the permission token back to service provider 110b. Service provider 110b can then view the verified identity attributes within the permission token and determine whether Alice has verified her identity in an appropriate manner with respect to any regulations applicable to the crypto transaction for the payment of 10 units of cryptocurrency from Bob. If service provider 110b is satisfied with compliance with all matters, service provider 110b can submit a request for the new crypto transaction to blockchain node 106 in the traditional manner to add it to the blockchain. The request may include a digital signature from Bob's blockchain wallet (for example, made by the second service provider 110b at the time of the transaction request or provided by Bob's second user device 108b), as well as the destination address for Alice's blockchain wallet. In some cases, the destination address may be provided by the processing server 102 along with the permission token, generated using the public key provided by the processing server 102 along with the permission token, provided by the first user device 108a when providing an alias, or requested by the first service provider 110a after compliance has been verified by the second service provider 110b.

[0030] As a result, a successful crypto transaction is achieved on the blockchain between the two participants, ensuring compliance with applicable regulations. In a traditional system, service providers 110a and 110b would need to exchange Alice's and Bob's PII and verify each identity in a manner appropriate to all applicable regulations, including those in the United States and Canada. This would require service providers 110a and 110b to be familiar with all regulations in both countries, as well as the rules regarding the receipt and storage of PII in both countries. In system 100, the first service provider 110a is responsible only for verifying the identity of its participant, Alice, and must be familiar with the identity requirements for transactions in the United States, Alice's country. The second service provider 110b is responsible only for verifying Bob's identity and must be familiar with the identity requirements for transactions in Canada, Bob's country. By leveraging permission tokens from the token identity service, the second service provider 110b can verify that Alice's identity is verified and compliant with U.S. regulations, and can also identify, based on the attributes contained therein, whether the identity verification is suitable for transactions with Canadian citizens. Transactions are successfully executed without any exchange of PII, and in some cases, when data is indicated in the permission token, the service provider 110 does not need to individually understand the regulations of all possible jurisdictions. As a result, there are significant improvements in processing speed, user security, and resource consumption for cryptographic transactions. In some embodiments, the service provider 110 does not need to communicate directly with other service providers 110, enabling a significantly increased reach and participation rate for all participants and service providers 110 compared to traditional systems.

[0031] In another exemplary transaction, service provider 110 can perform identity verification itself. In such a case, the permission token may include an attestation by service provider 110 instead of verified identity attributes. In this example, Alice can provide her alias to Bob, and this is done using their user devices 108a and 108b. As part of the process, the first service provider 110a can authenticate that Alice is authorized to participate in the transaction with Bob. Such an attestation may be a digital signature generated by the first service provider 110a, or it may be in another format suitable for the second service provider 110b to verify as authentic from the first service provider 110a and indicating Alice's authorization to participate in the transaction. Bob can submit a transaction request with Alice's alias to the second service provider 110b, which can request a permission token from the processing server 102 associated with the alias. The processing server 102 can identify a permission token, which may include an attestation from the first service provider 110a, and can also provide the permission token to the second service provider 110b. The second service provider 110b can verify the attestation and the permission for Alice to participate in the cryptographic transaction, and then proceed with the cryptographic transaction.In some cases, the second service provider 110b may provide an attestation regarding permission for Bob to participate in the transaction, which may be provided to the processing server 102 when requesting a permission token, which may be provided to the first service provider 110a, and / or may be verified by the first service provider 110a and / or the processing server 102 before providing the permission token to the second service provider 110b.

[0032] In some embodiments, one or more of the functions described herein can be performed by a smart contract stored on the blockchain. A smart contract can be stored on the blockchain and can be configured to self-execute when one or more conditions are met. In system 100, a smart contract can be configured to receive permission tokens and transaction data as input, thereby self-executing, and the smart contract verifies whether compliance with applicable regulations based on the input permission tokens has been met. If the verification is successful, the smart contract can generate a new blockchain transaction and submit it to blockchain node 106 to be added to the blockchain. As another example, a smart contract can be used to provide permission tokens or destination addresses when an alias is provided.

[0033] A smart contract can be used to enable the transfer after identity verification has been performed by service provider 110. In such an example, using the method described above, the first service provider 110a and the second service provider 110b can each verify that their respective users comply with applicable identity regulations. In some cases, the first service provider 110a and the second service provider 110b can exchange notifications indicating the success of the verification. The first service provider 110a can indicate to the smart contract stored on the blockchain that the transfer of cryptocurrency to the second user is authorized on behalf of the first user. The smart contract then performs the action of adding a new crypto transaction to the blockchain for the transfer of currency to the second user's blockchain wallet (e.g., second user device 108b). In the second example, the first service provider 110a can indicate to the smart contract stored on the blockchain that the transfer of cryptocurrency is authorized, and the smart contract can verify compliance with identity requirements for both users before executing the transfer. Using the methods described above, the smart contract can perform verification, for example, by receiving permission tokens for each participant from the processing server 102, receiving attestations, and verifying them at the processing server 102. In a third example, the first service provider 110a can indicate its approval of a transfer to the first smart contract, which can then invoke the second smart contract to perform compliance checks regarding identity verification requirements. In such an example, the first or second smart contract can be configured to add the new crypto transaction to the blockchain upon successful verification. In some embodiments, the processing server 102 generates the smart contracts described above and provides them to the blockchain node 106 for addition to the blockchain, for example, during participant registration or when a new transaction is requested.

[0034] In some cases, service provider 110 may be required to directly exchange data about participants in order to comply with certain requirements. For example, in some transactions, such as transactions to which rules of movement apply, it may be required to report on one or more identity attributes instead of simply verifying compliance with the requirements for identity attributes. In such cases, service provider 110 may communicate directly using an appropriate communication network and method, or via processing server 102, which can direct the communication directly to the appropriate service provider 110, thereby enabling any service provider 110 to conduct transactions with any other service provider 110 without the need to obtain detailed communication information about all other service providers 110. When identity attributes are exchanged, service provider 110 can ensure compliance with any regulations regarding the transmission and reception of such data.

[0035] When processing server 102 participates in the exchange, encryption, hashing, and other methods can be used for the transfer, thereby ensuring that processing server 102 does not acquire any personally identifiable information (PII). For example, the first service provider 110a can encrypt the identity attributes of the first participant using the public key of the encryption key pair of the second service provider 110b, and the second service provider 110b can encrypt the identity attributes of the second participant using the public key of the encryption key pair of the first service provider 110a. The encrypted data can be provided to processing server 102 by each service provider 110, which in turn can provide the encrypted data to other service providers 110. Each service provider 110 can then decrypt the identity attributes using its own private key, resulting in the exchange of PII among the service providers 110 without any PII being exposed to processing server 102. In some cases, the processing server 102 can exchange public keys, which enables data exchange between service providers 110 without any direct communication.

[0036] Processing server Figure 2 shows an embodiment of the processing server 102 within the system 100 of Figure 1. It will be obvious to those skilled in the art that the embodiment of the processing server 102 shown in Figure 2 is provided for illustrative purposes only and does not thoroughly represent all possible configurations of the processing server 102 suitable for performing the functions of this disclosure. For example, the computer system 500 shown in Figure 5 and described in more detail below may be a suitable configuration of the processing server 102. In some cases, other components of the system 100, such as the blockchain node 106, user device 108, and service provider 110, may include components shown in Figure 2 and described later.

[0037] The processing server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some examples, the receiving device 202 may be configured to receive data from the blockchain node 106, user device 108, service provider 110, and other systems and entities via one or more communication methods such as radio frequency, local area network, wireless area network, cellular communication network, Bluetooth, and the internet. In some embodiments, the receiving device 202 may include multiple devices (for example, different receiving devices that receive data over different networks (e.g., a first receiving device that receives data over a local area network and a second receiving device that receives data over the internet)). The receiving device 202 may receive transmitted electronic data signals. Upon reception of the data signal by the receiving device 202, data may be superimposed on the data signal and decoded, parsed, read, or acquired. In some embodiments, the receiving device 202 may include an analysis module for analyzing the received data signal and acquiring the data superimposed thereon. For example, the receiving device 202 may include an analysis program configured to receive the received data signal and convert it into available inputs for a function to be performed by the processing device to execute the method and system of the present disclosure.

[0038] The receiving device 202 may be configured to receive data signals electronically transmitted by the blockchain node 106, which may be superimposed on or encoded with blockchain data entries, requests for blockchain data, confirmation messages, cryptographic keys, smart contracts, etc. The receiving device 202 may also be configured to receive data signals electronically transmitted by the user device 108, which may be superimposed on or encoded with alias requests, verified identity attributes, identification values, service provider information, public keys, destination addresses, etc. The receiving device 202 may also be configured to receive data signals electronically transmitted by the service provider 110, which may be superimposed on or encoded with alias requests, permission token requests, identification values, verified identity attributes, updates to verified identity attributes, public keys, destination addresses, etc.

[0039] The processing server 102 may also include a communication module 204. The communication module 204 may be configured to transfer data between modules, engines, databases, memory, and other components of the processing server 102 for use when performing the functions of the disclosure. The communication module 204 may include one or more communication types and may use various communication methods for communication within the computing device. For example, the communication module 204 may include buses, connecting pin connectors, wires, etc. In some embodiments, the communication module 204 may also be configured to communicate between internal components of the processing server 102 and external components of the processing server 102 (e.g., externally connected databases, display devices, input devices, etc.). The processing server 102 may also include a processing unit. The processing unit may be configured to perform the functions of the processing server 102 of the disclosure. This will be obvious to those skilled in the art. In some embodiments, the processing unit may include a plurality of engines and / or modules (e.g., a query module 216, a generation module 218, a validation module 220, etc.) specifically configured to perform one or more functions of the processing unit. As in this disclosure, the term “module” may mean software or hardware specifically programmed to receive an input, use that input to perform one or more processes, and provide an output. The inputs, outputs, and processes performed by various modules are obvious to those skilled in the art based on this disclosure.

[0040] The processing server 102 may also include an account database 206. The account database 206 may be configured to store one or more account profiles 208 using an appropriate data storage format and schema. The account database 206 may be a relational database using SQL (Structured Query Language) that stores, identifies, modifies, updates, and accesses stored structured datasets. Each account profile 208 may be a structured dataset configured to store data related to a permissioned account. For example, an account profile 208 may include permission tokens, identification information, service provider information, aliases, verified user identity attributes, registered blockchain wallets, blockchain addresses, currency balances, wallet status, etc.

[0041] The processing server 102 may also include memory 214. Memory 214 may be configured to store data (e.g., public keys, private keys, symmetric keys, etc.) for use by the processing server 102 when performing the functions of the Disclosure. Memory 214 may be configured to store data using appropriate data formatting methods and schemas, and may be any appropriate type of memory (e.g., read-only memory, random access memory, etc.). Memory 214 may include, for example, cryptographic keys and algorithms, communication protocols and standards, data formatting standards and protocols, module program code and application programs for the processing unit, and other appropriate data used by the processing server 102 when performing the functions of the Disclosure. This will be obvious to those skilled in the art who read this Disclosure. In some embodiments, memory 214 may include a relational database using a structured query language (SQL) and may store, identify, modify, update, access, etc., stored structured datasets. Memory 214 may be configured to store, for example, regulations, location data, permission data, cryptographic keys, algorithms, etc.

[0042] The processing server 102 may also include a query module 216. The query module 216 may be configured to execute queries on a database to identify information. The query module 216 may receive one or more data values ​​or query columns and, based on these, execute the query columns on the indicated database (e.g., the memory 214 of the processing server 102) to identify the information stored therein. The query module 216 may then output the identified information to the appropriate engine or module of the processing server 102, as necessary. For example, the query module 216 can execute queries on the account database 206 to identify an account profile 208 regarding which permission tokens are being requested via aliases.

[0043] The processing server 102 may also include a generation module 218. The generation module 218 may be configured to generate data used by the processing server 102 when performing the functions of the disclosure. The generation module 218 may receive instructions as input, generate data based on instructions, and output the generated data to one or more modules of the processing server 102. For example, the generation module 218 may be configured to generate smart contracts, blockchain data entries, blocks, confirmation messages, permission tokens, aliases, destination addresses, etc.

[0044] The processing server 102 may also include a validation module 220. The validation module 220 may be configured to perform data validation and verification for the processing server 102 as part of the functions described herein. The validation module 220 may receive instructions as input, perform data validation or verification as instructed, and output the results of data validation or verification to one or more modules of the processing server 102. In some cases, the input may include data to be validated or verified and / or data used for validation or verification. In other cases, the validation module 220 may be configured to identify such data (e.g., in the account database 206 and / or in memory). The validation module 220 may be configured, for example, to verify compliance with regulations, to verify new blockchain data entries and / or blocks, to verify digital signatures, etc.

[0045] The processing server 102 may also include a transmitting device 222. The transmitting device 222 may be configured to transmit data over one or more networks via one or more network protocols. In some examples, the transmitting device 222 may be configured to transmit data to the blockchain node 106, user device 108, service provider 110, and other entities via one or more communication methods such as a local area network, wireless area network, cellular communication network, Bluetooth, radio frequency, or the internet. In some embodiments, the transmitting device 222 may include multiple devices (e.g., different transmitting devices for transmitting data over different networks, e.g., a first transmitting device for transmitting data over a local area network and a second transmitting device for transmitting data over the internet). The transmitting device 222 may electronically transmit a data signal having superimposed data that is parsed by a receiving computing device. In some embodiments, the transmitting device 222 may include one or more modules for superimposing, encoding, or formatting data into a data signal suitable for transmission.

[0046] The transmitting device 222 may also be configured to electronically transmit a data signal to the blockchain node 106, and this data signal may be superimposed on or encoded with blockchain data entries, blockchain data requests, blocks, confirmation messages, response messages, etc. The transmitting device 222 may also be configured to electronically transmit a data signal to the user device 108, and this data signal may be superimposed on or encoded with aliases, confirmation messages, destination addresses, data requests, etc. The transmitting device 222 may also be configured to electronically transmit a data signal to the service provider 110, and this data signal may be superimposed on or encoded with aliases, permission tokens, identification information, destination addresses, data requests, verified identity attribute requests, etc.

[0047] Processing for permission-based cryptographic transactions Figures 3A and 3B illustrate the processing within the system 100 of Figure 1 that facilitates permission-based cryptographic transactions on a blockchain associated with the blockchain network 104. In S302, the first service provider 110a can verify the identity of participants on the blockchain registered with the first service provider 110a using appropriate methods. As part of verifying the participant's identity, the first service provider 110a can collect verified user identity attributes, which may include the verification level and other verified user data (e.g., age, income, geographical location, etc.). In S304, the first service provider 110a can electronically transmit an onboarding request to the processing server 102 via an appropriate communication network and method. The onboarding request may include at least identification information and verified user identity attributes about the participant.

[0048] In S306, the receiving device 202 of the processing server 102 can receive an onboarding request from the first service provider 110a. In S308, the generating module 218 of the processing server 102 can generate a permission token and an alias for the participant. The permission token may include several data fields for identity attributes used for regulatory compliance, and the data values ​​for the data fields are based on the verified user identity attributes received in the onboarding request. In some cases, the alias may include a reference to the first service provider 110a and / or the verified user identity attributes. In S310, the transmitting device 222 of the processing server 102 can electronically transmit the alias to the first service provider 110a in response to the onboarding request.

[0049] In S312, the first service provider 110a can receive an alias for a participant. In S314, the first service provider 110a can issue the received alias to the participant, for example, via the first user device 108a. The participant can then send the alias to other participants registered with the second service provider 110b via the first user device 108a. The other participants can then submit a transaction request to the second service provider 110b using their own user device 108b, and the transaction request may include at least the alias, the transaction amount, unused transaction output, and any other data suitable for use in cryptographic transactions, such as a digital signature. In S316, the second service provider 110b can receive the transaction request.

[0050] In S318, the second service provider 110b can electronically send a request for a permission token to the processing server 102 using an appropriate communication network and method. The request may include at least the alias received in the transaction request. In S320, the receiving device 202 of the processing server 102 can receive the permission token request. In S322, the query module 216 of the processing server 102 can identify the permission token for the first participant in the associated account profile 208 via the received alias. In S324, the transmitting device 222 of the processing server 102 can electronically send the identified permission token for the first participant to the second service provider 110b in response to the permission token request.

[0051] In S326, the second service provider 110b can receive a permission token. In S328, the second service provider 110b can verify that the identity of the first participant complies with any applicable regulations based on the data values ​​in the data fields within the permission token. As part of the verification, the second service provider 110b can verify, or has already verified, the compliance of the second participant from an identity verification standpoint through the registration process. Once the second service provider 110b has verified that the transaction complies with all applicable regulations, in S330, the second service provider 110b can generate a new blockchain transaction. The new blockchain transaction may include at least the transaction amount, destination address, unspent transaction output, digital signature, and any other data necessary for the blockchain transaction.

[0052] In S332, the second service provider 110b can submit a new blockchain transaction to the blockchain node 106 in the blockchain network 104 using an appropriate communication method, and can also notify the first service provider 110a when the transaction is added to the blockchain. The blockchain node 106 can then confirm the transaction, and it can be included in a new block that is generated, confirmed, and added to the blockchain. In S334, the first service provider 110a can notify the first participant that the transaction in which the first participant is involved has been successfully added to the blockchain. As a result of this process, the first and second participants, each using different service providers, can participate in cryptographic transactions on the blockchain in compliance with all applicable regulations without the need for PII exchange and individual verification of both participants by each service provider 110.

[0053] Exemplary methods for permission-based cryptographic transactions Figure 4 illustrates a method 400 for facilitating permission-based cryptographic transactions through the use of permission tokens.

[0054] In S402, an onboarding request including at least permission data and an identification value is received from a first computing system (e.g., a first service provider 110a) by a receiver (e.g., a receiving device 202) of a processing server (e.g., a processing server 102), wherein the identification value is associated with a first blockchain wallet with respect to a blockchain associated with a blockchain network (e.g., a blockchain network 104). In S404, a permission token and alias, based at least on the permission data, are generated by a processor (e.g., a generation module 218) of the processing server, wherein the permission token includes one or more verified identity data points.

[0055] In S406, the generated alias is transmitted to the first computing system by the processing server's transmitter (e.g., transmitter 222) in response to the received onboarding request. In S408, a token request is received from the second computing system (e.g., the second service provider 110b), which includes the alias. In S410, at least the generated permission token and identification value can be transmitted to the second computing system by the processing server's transmitter in response to the received token request.

[0056] In one embodiment, the identifier may be a public key associated with a first blockchain wallet. In some embodiments, one or more verified identity data points may include at least one of the following: geographical location, age, income, identity verification status, compliance status, etc. In one embodiment, the generated permission token does not contain any personally identifiable information. In some embodiments, the onboarding request does not contain any personally identifiable information. In one embodiment, method 400 may further include the following steps: generating a new blockchain transaction by the second computing system, which includes at least a transaction amount, one or more unconsumed transaction outputs, and one of the identifier or a destination address generated using the identifier; and sending the generated new blockchain transaction to a blockchain node in the blockchain network (e.g., blockchain node 106) for addition to the blockchain. In further embodiments, method 400 may further include: before generating the new blockchain transaction, the second computing system verifying compliance of the first blockchain wallet with respect to one or more applicable regulations based on the one or more verified identity data points contained in the received permission token.

[0057] Computer System Architecture Figure 5 shows a computer system 500, in which embodiments or parts thereof of the present disclosure may be implemented as computer-readable code. For example, the processing server 102, the blockchain node 106, the user device 108, and the service provider 110 may be implemented in the computer system 500 using hardware, a non-temporary computer-readable medium having stored instructions, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The hardware can embody modules and components used to implement the methods of Figures 3A, 3B, and 4.

[0058] Where programmable logic is used, such logic runs on a commercially available processing platform consisting of executable software code and may be an application-specific or special-purpose device (e.g., a programmable logic array, an application-specific integrated circuit (ASIC), etc.). Those skilled in the art will understand that embodiments of the disclosed subject matter are executable in a variety of computer system configurations. Such configurations include multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, and general-purpose or miniature computers that can be implemented in substantially any device. For example, at least one processor device and memory may be used to implement the above embodiments.

[0059] The processor units or devices of this disclosure may be a single processor, multiple processors, or a combination thereof. The processor device may have one or more processor “cores.” The terms “computer program medium,” “non-temporary computer-readable medium,” and “computer-usable medium” in this disclosure are generally used to refer to tangible media (e.g., hard disks installed in removable storage unit 518, removable storage unit 522, and hard disk drive 512).

[0060] Various embodiments of this disclosure are described in relation to this exemplary computer system 500. After reading this disclosure, it will be obvious to those skilled in the art how to implement this disclosure using other computer systems and / or computer architectures. While operations are disclosed as sequential processes, some operations may actually be executed concurrently, simultaneously, and / or in a distributed environment. In this case, the program code is stored locally or remotely for access by single-processor or multi-processor machines. Furthermore, in some embodiments, the order of operations can be rearranged without departing from the spirit of the disclosure.

[0061] The processor device 504 may be a purpose-specific or general-purpose processor device specifically configured to perform the functions of the Disclosure. The processor device 504 may be connected to a communication infrastructure 506 (e.g., a bus, message queue, network, multicore message path scheme, etc.). The network may be any network suitable for performing the functions of the Disclosure and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., Wi-Fi), a mobile communication network, a satellite network, the Internet, optical fiber, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be obvious to those skilled in the art. The computer system 500 may also include main memory 508 (e.g., random access memory, read-only memory, etc.) and auxiliary memory 510. The auxiliary memory 510 may include a hard disk drive 512 and a removable storage drive 514 (e.g., a floppy disk drive, magnetic tape drive, optical disk drive, flash memory, etc.).

[0062] The removable storage drive 514 may read from and / or write to the removable storage unit 518 in a well-known manner. The removable storage unit 518 may include a removable storage medium that can be read from and written to by the removable storage drive 514. For example, if the removable storage drive 514 is a floppy disk drive or a USB port, the removable storage unit 518 may be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage unit 518 may be a non-temporary readable recording medium.

[0063] In some embodiments, the auxiliary memory 510 may include alternative means that enable computer programs or other instructions to be loaded into the computer system 500 (e.g., a removable storage unit 522 and interface 520). Examples of such means may include program cartridges and cartridge interfaces (e.g., found in video game systems), removable memory chips (e.g., EEPROM, PROM, etc.) and associated sockets, and other removable storage units 522 and interface 520. This will be obvious to those skilled in the art.

[0064] Data stored in the computer system 500 (for example, in main memory 508 and / or auxiliary memory 510) may be stored on any type of suitable computer-readable medium (e.g., optical storage (compact discs, digital multipurpose discs, Blu-ray discs, etc.) or magnetic tape storage (e.g., hard disk drives)). The data may be configured in any type of suitable database configuration (e.g., relational databases, structured query language (SQL) databases, distributed databases, object databases, etc.). Suitable configurations and storage types are obvious to those skilled in the art.

[0065] The computer system 500 may also include a communication interface 524. The communication interface 524 may enable software and data to be sent and received between the computer system 500 and external devices. An exemplary communication interface 524 may include a modem, a network interface (e.g., an Ethernet card), a communication port, a PCMCIA slot and card, etc. The software and data transferred via the communication interface 524 may be in signal form. The signal form may be electronic, electromagnetic, optical, or other signals obvious to those skilled in the art. The signals propagate through a communication path 526. The path is configured to carry signals and may be implemented using wires, cables, optical fibers, telephone lines, mobile phone links, radio frequency links, etc.

[0066] The computer system 500 may further include a display interface 502. The display interface 502 may be configured to allow data to be transferred between the computer system 500 and an external display 530. An exemplary display interface 502 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics array (VGA), etc. The display 530 may be any suitable type of display that displays the data transferred via the display interface 502 of the computer system 500, and includes cathode ray tube (CRT) displays, liquid crystal displays (LCDs), light-emitting diode (LED) displays, capacitive touch displays, thin-film transistor (TFT) displays, etc.

[0067] The computer program medium and computer-usable medium may refer to memory (e.g., main memory 508 and auxiliary memory 510) and may be semiconductor memory (DRAM, etc.). These computer program products may be means for providing software to the computer system 500. The computer program (e.g., computer control logic) may be stored in the main memory 508 and / or auxiliary memory 510. The computer program may also be received via the communication interface 524. When executed, such a computer program may enable the computer system 500 to perform the methods of the present disclosure. In particular, when executed, the computer program may enable the processor unit 504 to perform the methods shown in Figures 3A, 3B, and 4 as described herein. Thus, such a computer program represents a controller of the computer system 500. The present disclosure is implemented using software. The software may be stored in the computer program product and loaded into the computer system 500 using a removable storage drive 514, interface 520, and hard disk drive 512 or communication interface 524.

[0068] The processor device 504 may include one or more modules or engines configured to perform the functions of the computer system 500. Each module or engine may be implemented using hardware, and in some embodiments, it may use software (for example, this corresponds to program code or programs stored in main memory 508 or auxiliary memory 510). In such embodiments, the program code may be compiled by the processor device 504 (for example, by a compilation module or engine) before execution by the hardware of the computer system 500. For example, the program code may be source code (e.g., assembly language or machine code) written in a programming language that is translated into a low-level language. This is for execution by the processor device 504 and / or any additional hardware components of the computer system 500. The compilation process may include lexical analysis, preprocessing, syntactic analysis, semantic analysis, syntactic-driven translation, code generation, code optimization, and the use of any other techniques suitable for translating the program code into a low-level language for control of the computer system 500 and performing the functions of the disclosure. It will be obvious to those skilled in the art that such processing will result in a specially configured computer system 500 that is uniquely programmed to perform the above-mentioned functions.

[0069] The technology consistent with this disclosure provides a system and method for facilitating permission-based cryptographic transactions between service providers, although it also has other features. Various exemplary embodiments of the system and method of this disclosure are described above, but it should be understood that they are provided for illustrative purposes only and not for limitation. They are not exhaustive, and this disclosure is not limited to the disclosed form itself. Modifications and variations are possible in light of the above teachings. Modifications and variations may be derived from implementations of this disclosure without departing from the scope or scope.

Claims

1. A method for facilitating permission-based cryptographic transactions between service providers, A processing server receiver receives an onboarding request from a first computing system, the onboarding request comprising at least permission data and an identification value, wherein the identification value is associated with a first blockchain wallet with respect to a blockchain associated with a blockchain network. A step of generating a permission token and alias based on at least the permission data using the processor of the processing server, wherein the permission token includes one or more verified identity data points. The steps include: transmitting the generated alias to the first computing system in response to the onboarding request received by the transmitter of the processing server; The process involves the receiver of the processing server receiving a token request from a second computing system, wherein the token request includes the alias. A method comprising the step of transmitting, by the transmitter of the processing server, at least the generated permission token and the identification value to the second computing system in response to the received token request.

2. The method according to claim 1, wherein the identification value is a public key associated with the first blockchain wallet.

3. The method according to claim 1, wherein the one or more verified identity data points include at least one of: geographical location, age, income, identity verification status, compliance status, etc.

4. A method according to claim 1, wherein the generated permission token does not contain any personally identifiable information.

5. A method according to claim 1, wherein the onboarding request does not contain any personally identifiable information.

6. The method according to claim 1, further, The second computing system generates a new blockchain transaction which includes at least a transaction amount, one or more unspent transaction outputs, and one of the identification value or a destination address generated using the identification value. A method comprising the step of sending the generated new blockchain transaction to a blockchain node in the blockchain network for addition to the blockchain, using the second computing system.

7. In the method according to claim 6, further, A method comprising the step of verifying compliance of the first blockchain wallet with respect to one or more applicable regulations, based on one or more verified identity data points contained in the received permission token, by the second computing system before the generation of the new blockchain transaction.

8. In the method according to claim 1, The first computing system is associated with a first virtual asset service provider, The method wherein the second computing system is associated with a second virtual asset service provider.

9. A system that facilitates permission-based cryptographic transactions between service providers, Blockchain network and The first computing system and A second computing system, A system comprising a processing server, wherein the processing server is A receiver that receives an onboarding request from the first computing system, the onboarding request comprising at least permission data and an identification value, wherein the identification value is associated with a first blockchain wallet with respect to a blockchain associated with a blockchain network, A processor that generates permission tokens and aliases based on at least the permission data, wherein the permission tokens include one or more verified identity data points, The system includes a transmitter that, in response to the received onboarding request, transmits the generated alias to the first computing system, The receiver of the processing server receives a token request from the second computing system, and the token request includes the alias. The system wherein the transmitter of the processing server transmits, in response to the received token request, at least the generated permission token and the identification value to the second computing system.

10. The system according to claim 9, wherein the identification value is a public key associated with the first blockchain wallet.

11. The system according to claim 9, wherein the one or more verified identity data points include at least one of: geographical location, age, income, identity verification status, compliance status, etc.

12. The system according to claim 9, wherein the generated permission token does not contain any personally identifiable information.

13. The system according to claim 9, wherein the onboarding request does not contain any personally identifiable information.

14. In the system according to claim 9, the second computing system is: A new blockchain transaction is generated that includes at least the transaction amount, one or more unspent transaction outputs, and one of the identification value or a destination address generated using the identification value. A system that sends the generated new blockchain transaction to a blockchain node in the blockchain network for addition to the blockchain.

15. A system according to claim 14, wherein the second computing system verifies compliance of the first blockchain wallet with respect to one or more applicable regulations based on the one or more verified identity data points contained in the received permission token before the generation of the new blockchain transaction.

16. In the system described in claim 9, The first computing system is associated with a first virtual asset service provider, The second computing system is associated with a second virtual asset service provider.

Images