Method and system for providing token identity

Abstract

A method for facilitating license-based encrypted transactions across service providers includes receiving, from a first computing system, a join request including license data and an identification value associated with a first blockchain wallet for a blockchain associated with a blockchain network; generating a license token and an alias based on the license data, the license token comprising a verified identity data point; transmitting the generated alias to the first computing system in response to a join request; receiving a token request from a second computing system, the token request including the alias; and transmitting the generated permission token identification value to the second computing system in response to the token request.

Description

[0001] Cross - Reference to Related Applications

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

[0003] This disclosure relates to providing token identities, and more particularly to using permission tokens to facilitate encrypted transactions across service providers that meet identity verification requirements without transmitting or exchanging personally identifiable information. Background Art

[0004] Blockchains were originally created to provide a platform through which cryptocurrency could be transacted. Two main principles in the creation of blockchains were that the blockchain itself would be completely decentralized, stored on and managed via a widely distributed computing system, and that cryptocurrency transactions could be conducted completely anonymously, where no identifying information needed to be provided to participants and all transactions occurred between blockchain wallets regardless of their ownership. These two principles led to the widespread adoption of blockchains and their use in creating and managing a large variety of cryptocurrencies.

[0005] However, the popularity of blockchains combined with decentralization and anonymization has led to a large number of fraudulent activities in encrypted transactions. In the United States alone, consumers lost over a billion dollars in 2021. The lack of a central authority to regulate transactions puts users at a disadvantage, and anonymity provides little recourse for those who are exploited and makes it difficult to catch and stop fraudsters. To combat fraud, many countries have established policies, regulations, and requirements for identity verification of blockchain participants, as well as rules regarding participants in blockchain transactions.

[0006] 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 their participants. However, a large number of encrypted transactions occur between participants using different VASPs, which means that each VASP still has to verify the identities of other users with whom its participants transact. This can be a difficult process and also exposes the personally identifiable information (PII) of participants and other users to other VASPs. Additionally, a large number of encrypted transactions occur between participants in different countries, each with its own applicable policies and regulations. This requires VASPs to not only verify the identities of other users with whom their participants transact, but also to verify that both their participants and other users comply with the applicable regulations of other countries, which VASPs may not be familiar with.

[0007] Accordingly, current systems require all VASPs to be familiar with the applicable regulations of each country / region where blockchain participants are located and require all VASPs to easily exchange user PII to ensure compliance with applicable regulations, which can be a very difficult, time-consuming, and costly task and will greatly increase the chance of user PII being leaked. Therefore, a technical solution is needed to ensure compliance with encrypted transactions without exchanging PII or requiring VASPs to keep abreast of the applicable regulations of each potential transaction country at all times. Summary of the Invention

[0008] The present disclosure provides a description of systems and methods for facilitating permission-based encrypted transactions across service providers. New users of a blockchain can verify their identities through their virtual asset service providers (VASPs) that interact with the blockchain. A VASP can verify the identity of a user and any aspects of regulations that may apply to encrypted transactions. The VASP can register the user with a token identity service by providing data points about the verified user identity attributes. The token identity service can generate a permission token for the user based on its verified user identity attributes and return an alias to the VASP, which the user can use when participating in encrypted transactions. At the time of a transaction, the user can provide their alias to another party. The other party can provide the alias to their VASP when requesting to send or receive cryptocurrency from the user. The VASP of the other party can provide the alias to the token identity service, which can return the permission token for the user, and the permission token includes all the information required for the VASP of the other party to ensure that the user has been fully and properly verified against any applicable regulations known to the VASP of the other party. Then, the VASP of the other party can submit a new cryptocurrency transaction to the blockchain, which is fully compliant, and in which PII is not exchanged for any participant and in which each VASP only needs to verify the identity of its own users.

[0009] A method for facilitating permission-based encrypted transactions across service providers, comprising: receiving, by a receiver of a processing server, an onboarding request from a first computing system that includes at least permission data and an identification value, wherein the identification value is associated with a first blockchain wallet of a blockchain associated with a blockchain network; generating, by a processor of the processing server, a permission token and an alias based at least on the permission data, wherein the permission token includes one or more verified identity data points; transmitting, by a transmitter of the processing server, the generated alias to the first computing system in response to the received onboarding request; receiving, by the receiver of the processing server, a token request from a second computing system, wherein the token request includes the alias; and 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.

[0010] A system for facilitating permission - based cryptographic transactions across service providers, comprising: a blockchain network; a first computing system; a second computing system; and a processing server, the processing server including a receiver that receives an enrollment request from the first computing system, the enrollment request including at least permission data and an identification value, where the identification value is associated with a first blockchain wallet for a blockchain associated with the blockchain network, a processor that generates a permission token and an alias based at least on the permission data, where the permission token includes one or more verified identity data points, and a transmitter that transmits the generated alias to the first computing system in response to the received enrollment request, where the receiver of the processing server receives a token request from the second computing system, the token request including the alias, and the transmitter of the processing server transmits at least the generated permission token and the identification value to the second computing system in response to the received token request. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The scope of the present disclosure can be best understood from the following detailed description of the exemplary embodiments when read in conjunction with the accompanying drawings. The accompanying drawings include the following figures:

[0012] Figure 1 is a block diagram illustrating a high - level system architecture for facilitating permission - based cryptographic transactions according to an exemplary embodiment.

[0013] Figure 2 is illustrative of Figure 1 a block diagram of a processing server for facilitating permission - based cryptographic transactions in a system according to an exemplary embodiment.

[0014] Figure 3A and Figure 3B are flowcharts illustrating Figure 1 the process for facilitating permission - based cryptographic transactions across service providers in a system according to an exemplary embodiment.

[0015] Figure 4 is a flowchart illustrating an exemplary method for facilitating permission - based cryptographic transactions across service providers according to an exemplary embodiment.

[0016] Figure 5 is a block diagram illustrating a computer system architecture according to an exemplary embodiment.

[0017] Based on the detailed description provided below, other application areas of the present disclosure will become apparent. It should be understood that the detailed description of the exemplary embodiments is for illustrative purposes only and, therefore, is not necessarily intended to limit the scope of the present disclosure. DETAILED DESCRIPTION

[0018] System for Permissioned Cryptographic Transactions

[0019] Figure 1 FIG. illustrates a system 100 for facilitating permissioned cryptographic transactions for a blockchain that meets compliance with any applicable regulations without exchanging personally identifiable information (PII). The system 100 may include a processing server 102 discussed in more detail below, which may operate a token identity service to facilitate permissioned transactions. The system 100 may also include a blockchain network 104. The blockchain network 104 may include a plurality of blockchain nodes 106. Each blockchain node 106 may be a computing system (such as shown in Figure 2 or Figure 5 ), which is configured to perform functions related to the processing and management of the blockchain, including generation of blockchain data values, verification of proposed blockchain transactions, verification of digital signatures, generation of new blocks, validation of new blocks, and maintenance of a copy of the blockchain. In some embodiments, the processing server 102 may be a blockchain node 106 in the blockchain network 104.

[0020] A blockchain may be a distributed ledger consisting of at least a plurality of blocks. Each block may include at least a block header and one or more data values. Each block header may include at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time when the block header is generated and may be represented using any suitable method (e.g., UNIX timestamp, DateTime, etc.). The block reference value may be a value that references an earlier 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 before the corresponding 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. The data reference value may similarly be a reference to one or more data values stored in the block including 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.

[0021] The use of the block reference value and the data reference value in each block header may result in the immutability of the blockchain. Any attempt to modify the data values requires generating a new data reference value for the block, which in turn requires generating a new block reference value for the subsequent block, and further requires generating a new block reference value in each subsequent block. This must be performed and updated in each individual blockchain node 106 in the blockchain network 104 before generating and adding a new block to the blockchain to make the change permanent. Computational and communication limitations may make such modification extremely difficult if not impossible, thus making the blockchain immutable.

[0022] In some embodiments, a blockchain can be used to store information about blockchain transactions that occur between two different blockchain wallets. A blockchain wallet can include a private key of a cryptographic key pair that is used to generate a digital signature that serves as the payer's authorization for the blockchain transaction, where the digital signature can be verified by the corresponding blockchain network 104 using the public key of the cryptographic key pair. In some cases, the term "blockchain wallet" can specifically refer to the private key. In other cases, the term "blockchain wallet" can refer to a computing device (e.g., user device 108a, service provider 110a, etc.) that stores the private key for its blockchain transactions. For example, each computing device can have its own private key for a corresponding cryptographic key pair, and each computing device can be a blockchain wallet for conducting transactions using a blockchain associated with the blockchain network. The computing device can be any type of device suitable for storing and using a blockchain wallet, such as a desktop computer, laptop computer, notebook computer, tablet computer, cellular phone, smartphone, smartwatch, smart TV, wearable computing device, implantable computing device, etc.

[0023] Each blockchain data value stored in the blockchain can correspond to a blockchain transaction or other storage of data (if applicable). A blockchain transaction can consist of at least the following: a digital signature of the sender generated using the private key of the sender (e.g., user device 10b, service provider 110b, etc.), the blockchain address of the currency recipient generated using the public key of the recipient, and the amount of blockchain currency transferred or other data stored. In some blockchain transactions, the transaction can also include one or more blockchain addresses of the sender in which blockchain currency is currently stored (e.g., where the digital signature certifies their right to access such currency), and an address generated using the public key of the sender (for any change the sender wishes to retain). An address to which cryptocurrency has been sent and can be used in future transactions is called an "output" address because each address has previously been used to capture the output of a previous blockchain transaction, also known as an "unspent transaction" because currency was sent to that address in a previous transaction but the currency has not yet been spent. In some cases, a blockchain transaction can also include the public key of the sender for entities to verify the transaction. For traditional processing of blockchain transactions, such data can be provided to the blockchain nodes 106 in the blockchain network 104 either by the sender or by the recipient. The node can use the public key in the cryptographic key pair of the sender's wallet to verify the digital signature and also verify the sender's access to the funds (e.g., the unspent transaction has not been spent and sent to an address associated with the sender's wallet), a process called "confirmation" of the transaction, and then include the blockchain transaction in a new block. In a traditional blockchain implementation, the new block can be verified by other blockchain nodes 106 in the blockchain network 104 and then added to the blockchain and distributed to all blockchain nodes 106 in the blockchain network 104. In cases where the blockchain data value is not related to a blockchain transaction but rather to the storage of other types of data, the blockchain data value can still include or otherwise involve the verification of a digital signature.

[0024] System 100 can include a user device 108, in Figure 1Shown as the first user device 108a and the second user device 108b. Each user device 108 can be a device used by a participant in a blockchain associated with the blockchain network 104 to perform functions associated with the blockchain. In system 100, participants in the blockchain can interact with the blockchain through service provider 110. Service provider 110 can directly interact with blockchain nodes 106 on behalf of the participants to provide convenience, value-added services, security, etc. to the participants. In some cases, service provider 110 can store the keys of the blockchain wallets associated with the participants (e.g., similar to a bank maintaining an account used by a customer). In other cases, user device 108 can retain the private keys for its blockchain wallet, where the communication is routed to blockchain network 104 via service provider 110. In the industry, service provider 110 is sometimes referred to as a "virtual asset service provider" or "VASP". In some cases, each participant in a transaction can utilize a different service provider 110. In other cases, both participants in a transaction can use the same service provider 110.

[0025] In system 100, encrypted transactions using the blockchain can be subject to one or more policies, regulations, requirements, restrictions, etc., collectively referred to herein as regulations. The regulations can be formulated by blockchain network 104, service provider 110, government agencies, financial institutions, standardization bodies, or other suitable entities. The regulations can apply to any aspect of the transaction or the individuals involved in the transaction. In an example, a country can require any individual participating in an encrypted transaction in that country to verify their identity. In another example, a transaction involving a certain class of goods (e.g., alcohol) can require both participants in the transaction to reach a certain age. In some cases, the regulations can apply to a single participant in the transaction (e.g., location-specific regulations only apply to participants in that location). In other cases, the regulations can apply to both participants in the transaction, such as a country can require both participants in a transaction (even if only one participant is located in that country) to comply with its applicable regulations.

[0026] To ensure compliance with applicable regulations, traditionally, each service provider 110 identifies all applicable regulations, performs all verifications required for each participant, and verifies compliance. For example, to complete such tasks, service provider 110 can exchange PII for the participants so that service provider 110b can verify the identity of the participant behind user device 108a. Each time the same participant conducts a transaction with another participant using a different service provider 110, the participant's PII is provided to the new service provider 110, resulting in the participant's PII being spread across multiple systems and undergoing many transfers, thus greatly increasing the likelihood of its data leakage.

[0027] To address such issues and enable service provider 110 to focus on its own participants, processing server 102 can provide a token identity service using permission tokens to quickly and accurately provide information about regulatory compliance. In system 100, when a new participant in the blockchain registers with service provider 110, service provider 110 verifies the identity of the participant and collects any other appropriate information required to comply with any potential regulations. Service provider 110 can use any appropriate method to verify identity and other data. Service provider 110 can obtain and store the verified data (referred to herein as verified identity data points or verified identity attributes) in any appropriate manner, such as complying with any regulations applicable to the storage of PII or other identity data. Identity attributes can include any attribute to which regulations can be applied to encrypted transactions, such as the level of identity verification (e.g., identification via name, identification via photo, multiple types of identity verification, etc.), age, geographical location, income, compliance with regulatory authorities, etc. For example, service provider 110 can verify the identity and age of a participant via a driver's license and store an attribute indicating the participant's age and that the identity has been successfully verified by their state government. In another example, service provider 110 can verify the identity and age of a participant through their national government (e.g., via a passport), as well as verify their geographical location through their state government, and store an attribute indicating that the identity and age have been verified at the national level and the location has been verified at the state level.

[0028] Once service provider 110 has verified the identity attributes of a participant, the participant can register with the token identity service via processing server 102. In some cases, the communication with processing server 102 can be performed by service provider 110 on behalf of the participant. In other cases, the participant can communicate directly with processing server 102 using their user device 108. In such cases, the participant can provide information identifying service provider 110 through which the participant's identity has been verified. The registration of the participant with processing server 102 can include the transmission of permission data in the verified identity attributes and identification information about the blockchain wallet to which the identity attributes belong. 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 service provider 110 to identify the participant and the data stored by them.

[0029] The processing server 102 may receive verified identity attributes and identification information for the participants. In the case where the processing server 102 receives registration data from the user device 108, the processing server 102 may use the provided information to identify the service provider 110 to verify or request verified user identity attributes. In an exemplary embodiment, the processing server 102 may receive only the attributes without any participant's PII. For example, the attributes may include that the identity of the participant has been double-verified at the national level, but without any information about the identity.

[0030] After receiving the attributes, the processing server 102 may generate a permission token for the participant. The permission token may be a digital token that includes attributes in a standardized format, and the digital token includes fields for all identity attributes required to ensure compliance with applicable regulations. For example, the permission token may include separate data fields for identity verification at multiple levels and for each country, as well as data fields for income, age, state, city, country, education level, etc. In the case where the processing server 102 has not provided attribute data for such fields, the fields may remain blank or null. In some cases, the permission token may include fields indicating compliance with the identity requirements of each country where the blockchain participants are located. For example, if there are participants from twenty different countries, then the permission token may include fields indicating compliance or non-compliance with the regulations of each of these twenty countries. The processing server 102 may be configured to determine compliance based on the regulations of each country and the supplied identity attributes. In some cases, the processing server 102 may be configured to determine compliance with any regulations, such as regulations that may be imposed or proposed by any suitable entity (such as a financial institution, a standardization body, etc.). For example, the service provider 110 may verify the identity of the participant at a level suitable for US regulations rather than at a level suitable for EU regulations. In this case, the participant's permission token may indicate US compliance and EU non-compliance.

[0031] In addition to the permission token, the processing server 102 can also generate an alias for a participant. The alias can be a value unique to the participant and is directly associated with the participant's permission token. This alias can be used to identify the participant and their permission token across service providers 110. The processing server 102 can return the alias to the user device 108 (e.g., directly or via the service provider 110). Then, when a new transaction is desired, the participant can send their alias to another participant via their user device 108 and the user device 108 of another participant. In some cases, the participant can request a specific alias during the registration process. In some embodiments, the participant can link their alias across multiple service providers 110. For example, a participant can have three different blockchain wallets managed by three different service providers 110 and can register with the processing server 102 (e.g., via their user device 108) to associate the alias with all three blockchain wallets. In such embodiments, the participant can choose which blockchain wallet to use to send or receive currency for a specific transaction. In some cases, the alias can have a sub - part or component that indicates the service provider. For example, participant Jane can request the alias "jane", where the service provider used for the transaction can be indicated in a part of the full alias, such as jane.vaspone.tokenservice for the first service provider 110 and jane.vasptwo.tokenservice for the second service provider 110. In these embodiments, the participant can deactivate one or more blockchain wallets and / or completely remove the blockchain wallet from their account for future use in cryptocurrency transactions.

[0032] In cases where the processing server 102 can provide multiple blockchain wallets linked to a single participant via their alias, such data can be stored in the following example format:

[0033] - accountAlias: ACC55059970032193496

[0034] status: ACTIVE

[0035] crypto - addresses:

[0036] - cryptoAddressId: 52c3837d - cf45 - 4830 - b1cf - 60f2616bfa04

[0037] status: ACTIVE

[0038] asset: BTC

[0039] blockchainAddress: mu692DY2GwYXbWdv3wUsQRr6nXsYW8QRsm

[0040] -cryptoAddressId: 52c3837d-cf45-4830-b1cf-60f2616bfa05

[0041] status: ACTIVE

[0042] asset: ETH

[0043] blockchainAddress: '0x46Be1B5b35708e369b943CE6094c6f0484d480A7'

[0044] createdDate: '2022-03-20T09:12:28-05:00'

[0045] updatedDate: '2022-03-20T12:18:36-05:00'

[0046] In this example, a participant with the alias ACC55059970032193496 (e.g., this could be a hash of the alias issued to the participant, or otherwise mapped to the issued alias) registered two blockchain wallets with the processing server 102 to use with that alias, one using BTC and the other using ETC. As indicated in the profile, both are active and can thus be used to send or receive currency using the provided addresses.

[0047] In an example transaction, a first participant, Alice, using the first user device 108a located in the United States, may have had her identity verified by the first service provider 110a and may have registered with and been issued an alias, alias.usa.tokenservice, by the token identity service. A second participant, Bob, located in Canada, interacts with the blockchain using the second service provider 110b and is interested in purchasing a product sold by Alice for ten units of cryptocurrency via a cryptographic transaction on the blockchain. To receive payment, Alice can provide her alias to Bob by transmitting the alias from her first user device 108a to Bob's second user device 108b. Bob can then submit a request via the second user device 108b to the second service provider 110b to send ten units of cryptocurrency to the alice.tokenservice alias. The second service provider 110b can send a request for Alice's permission token to the processing server 102 via a suitable communication network and method, including the alice.usa.tokenservice alias.

[0048] The processing server 102 can receive the alias and identify the associated permission token. The processing server 102 can then transmit the permission token electronically back to the service provider 110b. The service provider 110b can then view the verified identity attributes in the permission token to determine whether Alice has had her identity verified in a manner suitable for any regulations applicable to the cryptographic transaction for the payment of ten units of cryptocurrency from Bob. If the service provider 110b is satisfied that everything is in order, then the service provider 110b can use traditional methods to submit a request for a new cryptographic transaction to the blockchain node 106 to be added to the blockchain. The request can include a digital signature from Bob's blockchain wallet (e.g., performed by the second service provider 110b or supplied by Bob's second user device 108b when requesting the transaction) and the destination address of Alice's blockchain wallet. In some cases, the destination address can be provided by the processing server 102 with the permission token, generated using a public key provided by the processing server 102 with the permission token, provided by the first user device 108a when providing the alias, or requested from the first service provider 110a after the second service provider 110b verifies compliance.

[0049] The result is a successful encrypted transaction between two participants on the blockchain while ensuring compliance with all applicable regulations. In a traditional system, service providers 110a and 110b would have to exchange the PII of Alice and Bob in order to verify each identity in a manner suitable for all applicable regulations, including those of the United States and Canada, which would require each service provider 110a and 110b to be familiar with all regulations of 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 only responsible for verifying the identity of its participant, Alice, and understanding the identity requirements for transactions in the country where Alice is located (the United States). The second service provider 110b is only responsible for verifying the identity of Bob and the identity requirements for transactions in the country where Bob is located (Canada). By leveraging a permissioned token from the token identity service, the second service provider 110b can verify that Alice's identity has been verified and complies with United States regulations, and can also determine whether the identity verification is suitable for transacting with a Canadian based on the attributes included therein. The transaction is successfully conducted without exchanging any PII, and in some cases the service providers 110 do not need to separately understand the regulations of all possible jurisdictions if this data is indicated in the permissioned token. The result is a significant improvement in the processing speed, user security, and resource expenditure for encrypted transactions. Additionally, in some embodiments, the service providers 110 do not have to communicate directly with other service providers 110, allowing for significantly greater coverage and participation of all participants and service providers 110 compared to traditional systems.

[0050] In another example transaction, service provider 110 may perform identity verification itself. In this case, the permission token may include a proof of service provider 110 rather than the verified identity attributes. In the example, Alice may provide her alias to Bob using their user devices 108a and 108b. As part of this process, the first service provider 110a may prove that Alice is permitted to participate in the transaction with Bob. Such proof may be a digital signature generated by the first service provider 110a or may be in another format suitable for being verified by the second service provider 110b as being authentic from the first service provider 110a and indicating that Alice has permission to participate in the transaction. Bob may submit a transaction request with Alice's alias to the second service provider 110b, and the second service provider 110b may request a permission token from the processing server 102 associated with the alias. The processing server 102 may identify the permission token, which may include the proof from the first service provider 110a and provide the permission token to the second service provider 110b. The second service provider 110b may verify the proof and Alice's permission to participate in the encrypted transaction and then proceed with the encrypted transaction. In some cases, the second service provider 110b may provide proof of Bob's permission to participate in the transaction, which may be provided to the processing server 102 when requesting the permission token, and the permission token may be provided to the first service provider 110a and / or verified by the first service provider 110a and / or the processing server 102 before providing the permission token to the second service provider 110b.

[0051] In some embodiments, one or more of the functions discussed herein may be performed by a smart contract stored on a blockchain. The smart contract may be stored on the blockchain and configured to execute itself when one or more conditions are met. In system 100, the smart contract may be configured to receive a permission token and transaction data as input, which may cause self-execution, where the smart contract verifies compliance with applicable regulations based on the input permission token. If the verification is successful, then the smart contract may generate a new blockchain transaction and submit it to the blockchain node 106 for addition to the blockchain. In another example, the smart contract may be used to provide a permission token or a destination address when supplied with an alias.

[0052] In one example, a smart contract can be used to effect a transfer in the case where identity verification is performed by service provider 110. In such an example, first service provider 110a and second service provider 110b can each use the methods discussed above to verify that their respective users comply with applicable identity regulations. In some cases, first service provider 110a and second service provider 110b can exchange notifications indicating successful verification. First service provider 110a can instruct a smart contract stored on a blockchain that cryptocurrency is authorized to be transferred to a second user on behalf of a first user. The smart contract can then be executed to add a new cryptocurrency transaction to the blockchain to transfer the currency to the second user's blockchain wallet (e.g., second user device 108b). In a second example, first service provider 110a can instruct a smart contract stored on a blockchain that cryptocurrency is authorized to be transferred, and the smart contract can verify whether both users meet identity requirements before performing the transfer. The smart contract can perform the verification using the methods discussed above, such as by receiving a permission token for each participant from processing server 102, receiving proofs and confirming them with processing server 102. In a third example, first service provider 110a can instruct a first smart contract to transfer authorization, and then the first smart contract can call a second smart contract to perform a compliance check of identity verification requirements. In such an example, the first smart contract or the second smart contract can be configured to add a new cryptocurrency transaction to the blockchain after successful verification. In some embodiments, processing server 102 can be configured to generate the smart contracts discussed above and provide the smart contracts to blockchain node 106 to add to the blockchain, such as during participant registration or when a new transaction is requested.

[0053] In some cases, service provider 110 may be required to directly exchange data about participants to comply with requirements. For example, some transactions may require reporting one or more identity attributes rather than simply verifying that identity attributes comply with requirements, such as transactions to which travel rules apply. In such cases, service provider 110 can communicate directly using a suitable communication network and method, or can communicate via processing server 102, where processing server 102 can direct the communication to the appropriate service provider 110, which can enable any service provider 110 to transact with any other service provider 110 without obtaining detailed communication information for all other service providers 110. In the case of exchanging identity attributes, service provider 110 can ensure compliance with any regulations regarding the transmission and receipt of such data.

[0054] In the case where the processing server 102 participates in the exchange, the transfer can use encryption, hashing, and other techniques to ensure that the processing server 102 does not obtain any readable personally identifiable information. In the example, the first service provider 110a can use the public key of the encryption key pair of the second service provider 110b to encrypt the identity attributes of the first participant, while the second service provider 110b can use the public key of the encryption key pair of the first service provider 110a to encrypt the identity attributes of the second participant. The encrypted data can be provided to the processing server 102 by each service provider 110, and the processing server 102 can provide the encrypted data to another service provider 110. Then, each service provider 110 can decrypt the identity attributes using its own private key, resulting in the exchange of PII between the service providers 110 without exposing any PII to the processing server 102. In some cases, the processing server 102 can exchange public keys, which can enable the data exchange to occur without any direct communication between the service providers 110.

[0055] Processing Server

[0056] Figure 2 illustrates Figure 1 an embodiment of the processing server 102 in the system 100. It will be clear to those skilled in the relevant art that Figure 2 the embodiment of the processing server 102 shown in Figure 5 is provided only as an illustration and does not exhaustively illustrate all possible configurations of the processing server 102 suitable for performing the functions discussed herein. For example, Figure 2 the computer system 500 shown in

[0057] The processing server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data via one or more network protocols over one or more networks. In some cases, the receiving device 202 may be configured to receive data from the blockchain node 106, the user device 108, the 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, the Internet, etc. In some embodiments, the receiving device 202 may consist of multiple devices, such as different receiving devices for receiving data over different networks, such as a first receiving device for receiving data over a local area network and a second receiving device for receiving data via the Internet. The receiving device 202 may receive data signals transmitted electronically, where the data may be superimposed or otherwise encoded on the data signals, and the data signals are received via the receiving device 202 to be decoded, parsed, read, or otherwise obtained. In some cases, the receiving device 202 may include a parsing module for parsing the received data signals to obtain the data superimposed thereon. For example, the receiving device 202 may include a parser program configured to receive the data signals and transform the received data signals into available inputs for functions to be executed by a processing device to perform the methods and systems described herein.

[0058] The receiving device 202 may be configured to receive data signals transmitted electronically by the blockchain node 106, which are superimposed or otherwise encoded with blockchain data entries, requests for blockchain data, confirmation messages, encryption keys, smart contracts, etc. The receiving device 202 may also be configured to receive data signals transmitted electronically by the user device 108, which may be superimposed or otherwise 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 transmitted electronically by the service provider 110, which are superimposed or otherwise encoded with alias requests, permission token requests, identification values, verified identity attributes, updates to the verified identity attributes, public keys, destination addresses, etc.

[0059] The processing server 102 may further include a communication module 204. The communication module 204 may be configured to transfer data between the modules, engines, databases, memories, and other components of the processing server 102 for performing the functions discussed herein. The communication module 204 may include one or more types of communication and utilize various communication methods for communication within a computing device. For example, the communication module 204 may include a bus, a pin connector, a cable, etc. In some embodiments, the communication module 204 may also be configured to communicate between the internal components of the processing server 102 and the external components of the processing server 102 (such as an externally connected database, a display device, an input device, etc.). The processing server 102 may further include a processing device. The processing device may be configured to perform the functions of the processing server 102 discussed herein, as will be apparent to those skilled in the relevant art. In some embodiments, the processing device may include and / or consist of multiple engines and / or modules specifically configured to perform one or more functions of the processing device, such as a query module 216, a generation module 218, a verification module 220, etc. As used herein, the term "module" may be software or hardware that is specifically programmed to receive an input, perform one or more processes using the input, and provide an output. Based on the present disclosure, those skilled in the art will be clear about the input, output, and processes performed by the various modules.

[0060] The processing server 102 may further include an account database 206. The account database 206 may be configured to store one or more account profiles 208 using a suitable data storage format and schema. The account database 206 may be a relational database that utilizes structured query language to store, identify, modify, update, access, etc., the structured data sets stored therein. Each account profile 208 may be a structured data set configured to store data related to a licensed account. For example, the account profile 208 may include a license token, identification information, service provider information, an alias, verified user identity attributes, a registered blockchain wallet, a blockchain address, a currency balance, a wallet status, etc.

[0061] The processing server 102 may also include a memory 214. The memory 214 may be configured to store data for use by the processing server 102 when performing the functions discussed herein, such as public and private keys, symmetric keys, etc. The memory 214 may be configured to store data using suitable data formatting methods and patterns, and may be any suitable type of memory, such as read-only memory, random access memory, etc. The memory 214 may include, for example, encryption keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and applications for the processing device, and other data that may be suitable for use by the processing server 102 when performing the functions disclosed herein, as will be apparent to those skilled in the relevant art. In some embodiments, the memory 214 may consist of or otherwise include a relational database that uses structured query language to store, identify, modify, update, access, etc., structured data sets stored therein. The memory 214 may be configured to store, for example, regulations, location data, permission data, encryption keys, algorithms, etc.

[0062] The processing server 102 may 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 strings, and may execute the query string based on the indicated database, such as the memory 214 of the processing server 102, to identify 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 needed. For example, the query module 216 may execute a query on the account database 206 to identify the account profile 208 for which a permission token is requested via an alias.

[0063] The processing server 102 may also include a generation module 218. The generation module 218 may be configured to generate data for use by the processing server 102 when performing the functions discussed herein. The generation module 218 may receive instructions as input, may generate data based on the instructions, and may 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.

[0064] The processing server 102 may further include a verification module 220. The verification module 220 may be configured to perform data verification and validation for the processing server 102 as part of the functions discussed herein. The verification module 220 may receive instructions as input, perform data verification or validation as indicated, and output the results of the data verification or validation to one or more modules of the processing server 102. In some cases, the input may include data to be verified or validated and / or data to be used in the verification or validation. In other cases, the verification module 220 may be configured to identify such data, such as in the account database 206 and / or the memory 214. The verification module 220 may be configured to, for example, verify regulatory compliance, validate new blockchain data entries and / or blocks, verify digital signatures, etc.

[0065] The processing server 102 may further include a transmission device 222. The transmission device 222 may be configured to transmit data over one or more networks via one or more network protocols. In some cases, the transmission device 222 may be configured to transmit data to the blockchain nodes 106, user devices 108, service providers 110, and other entities via one or more communication methods, local area networks, wireless area networks, cellular communications, Bluetooth, radio frequency, the Internet, etc. In some embodiments, the transmission device 222 may consist of multiple devices, such as different transmission devices for transmitting data over different networks, such as a first transmission device for transmitting data via a local area network and a second transmission device for transmitting data via the Internet. The transmission device 222 may transmit a data signal electronically that is superimposed with data that can be parsed by the receiving computing device. In some cases, the transmission device 222 may include one or more modules for superimposing, encoding, or otherwise formatting the data into a data signal suitable for transmission.

[0066] The transmission device 222 may be configured to electronically transmit a data signal to the blockchain node 106 that is superimposed with or otherwise encoded with a blockchain data entry, blockchain data request, block, confirmation message, response message, etc. The transmission device 222 may also be configured to electronically transmit a data signal to the user device 108 that is superimposed with or otherwise encoded with an alias, confirmation message, destination address, data request, etc. The transmission device 222 may also be configured to electronically transmit a data signal to the service provider 110 that may be superimposed with or otherwise encoded with an alias, permission token, identification information, destination address, data request, verified identity attribute request, etc.

[0067] Process for Permissioned Cryptographic Transactions

[0068] Figure 3A and Figure 3Billustrates Figure 1 a process for facilitating permissioned cryptographic transactions on a blockchain associated with blockchain network 104 in system 100. In step 302, first service provider 110a may verify the identity of a participant registered with the first service provider 110a in the blockchain using a suitable method. As part of the verification of the participant's identity, first service provider 110a may collect verified user identity attributes, which may include a level of verification and other verified user data, such as age, income, geographical location, etc. In step 304, first service provider 110a may electronically transmit a join request to processing server 102 via a suitable communication network and method. The join request may include at least the identification information of the participant and the verified user identity attributes.

[0069] In step 306, receiving device 202 of processing server 102 may receive the join request from first service provider 110a. In step 308, generation module 218 of processing server 102 may generate a permission token and an alias for the participant. The permission token may include a plurality of data fields for identity attributes for regulatory compliance, wherein the data values of the data fields are based on the verified user identity attributes received in the join request. In some cases, the alias may include a reference to first service provider 110a and / or any verified user identity attributes. In step 310, transmitting device 222 of processing server 102 may electronically transmit the alias to first service provider 110a in response to the join request.

[0070] In step 312, first service provider 110a may receive the alias of the participant. In step 314, first service provider 110a may issue the received alias to the participant, such as via first user device 108a. Then, the participant may transmit the alias to another participant registered with second service provider 110b via first user device 108a. Then, the other participant may submit a transaction request to second service provider 110b using its user device 108b, where the transaction request includes at least the alias, the transaction amount, and any other data suitable for a cryptographic transaction, such as unspent transaction outputs, digital signatures, etc. In step 316, second service provider 110b may receive the requested transaction.

[0071] In step 318, the second service provider 110b may electronically transmit a request for a permission token to the processing server 102 using a suitable communication network and method. The request may include at least the alias received in the transaction request. In step 320, the receiving device 202 of the processing server 102 may receive the permission token request. In step 322, the query module 216 of the processing server 102 may identify the permission token of the first participant in the associated account profile 208 identified via the received alias. In step 324, the transmission device 222 of the processing server 102 may electronically transmit the identified permission token of the first participant to the second service provider 110b in response to the permission token request.

[0072] In step 326, the second service provider 110b may receive the permission token. In step 328, the second service provider 110b may verify that the identity of the first participant complies with any applicable regulations based on the data values in the data fields of the permission token. As part of the verification, the second service provider 110b may verify or may already have verified the compliance of the second participant with respect to identity verification via the registration process. Once the second service provider 110b has verified that the transaction complies with all applicable regulations, then, in step 330, the second service provider 110b may generate a new blockchain transaction. The new blockchain transaction may include at least the transaction amount, the destination address, the unspent transaction output, the digital signature, and any other data required for the blockchain transaction.

[0073] In step 332, the second service provider 110b may submit the new blockchain transaction to the blockchain nodes 106 in the blockchain network 104 using a suitable communication method and notify the first service provider 110a when the transaction has been added to the blockchain. Then, the blockchain nodes 106 may confirm the transaction, which may be included in a new block that is generated, confirmed, and added to the blockchain. In step 334, the first service provider 110a may notify the first participant that the transaction involving the first participant has been successfully added to the blockchain. As a result of this process, the first and second participants (each using a different service provider 110) participate in a permissioned cryptographic transaction on the blockchain that complies with all applicable regulations without the need for each service provider 110 to exchange PII and perform separate verifications of the two participants.

[0074] Exemplary Method for Permissioned Cryptographic Transactions

[0075] Figure 4 Method 400 for facilitating permissioned cryptographic transactions on a blockchain via the use of permission tokens is illustrated.

[0076] In step 402, a receiver (e.g., receiving device 202) of a processing server (e.g., processing server 102) receives a join request from a first computing system (e.g., first service provider 110a) that includes at least permission data and an identification value, where the identification value is associated with a first blockchain wallet for a blockchain associated with a blockchain network (e.g., blockchain network 104). In step 404, a processor of the processing server (e.g., generation module 218) generates a permission token and an alias based at least on the permission data, where the permission token includes one or more verified identity data points.

[0077] In step 406, a transmitter of the processing server (e.g., transmission device 222) transmits the generated alias to the first computing system in response to the received join request. In step 408, a token request is received from a second computing system (e.g., second service provider 110b), where the token request includes the alias. In step 410, the generated permission token and the identification value can be transmitted by the transmitter of the processing server to the second computing system in response to the received token request.

[0078] In one embodiment, the identification value can be a public key associated with the first blockchain wallet. In some embodiments, one or more verified identity data points can 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 include any personally identifiable information. In some embodiments, the join request does not include any personally identifiable information. In one embodiment, method 400 can further include: generating, by the second computing system, a new blockchain transaction that 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; and transmitting, by the second computing system, the generated new blockchain transaction to a blockchain node (e.g., blockchain node 106) in the blockchain network for addition to the blockchain. In a further embodiment, method 400 can even further include verifying, by the second computing system, the compliance of the first blockchain wallet with one or more applicable regulations based on one or more verified identity data points included in the received permission token before generating the new blockchain transaction.

[0079] Computer System Architecture

[0080] Figure 5FIG. illustrates a computer system 500 in which embodiments of the present disclosure, or portions thereof, 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-transitory computer-readable medium storing instructions thereon, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The hardware may implement modules and components for implementing Figure 3A , 3B and Figure 4 methods.

[0081] If programmable logic is used, such logic may be executed on a commercially available processing platform configured by executable software code to become a special-purpose computer or a special-purpose device (e.g., a programmable logic array, an application-specific integrated circuit, etc.). Those of ordinary skill in the art will recognize that embodiments of the disclosed subject matter may be practiced with a variety of computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, and pervasive or microcomputers that may be embedded in almost any device. For example, the above embodiments may be implemented using at least one processor device and a memory.

[0082] The processor unit or device discussed herein may be a single processor, multiple processors, or a combination thereof. The processor device may have one or more processor "cores". As used herein, the terms "computer program medium", "non-transitory computer-readable medium", and "computer-usable medium" generally refer to tangible media, such as removable storage unit 518, removable storage unit 522, and a hard disk installed in hard disk drive 512.

[0083] Various embodiments of the present disclosure are described with reference to this example computer system 500. After reading this description, those skilled in the relevant art will recognize how to implement the present disclosure using other computer systems and / or computer architectures. Although operations may be described as sequential processing, some operations may actually be performed in parallel, concurrently, and / or in a distributed environment, and the program code may be stored locally or remotely for access by a single processor or multiple processor machines. Additionally, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

[0084] The processor device 504 can be a dedicated or general-purpose processor device specifically configured to perform the functions discussed herein. The processor device 504 can be connected to a communication infrastructure 506, such as a bus, message queue, network, multi-core messaging scheme, etc. The network can be any network suitable for performing the functions disclosed herein and can include a local area network (LAN), wide area network (WAN), wireless network (e.g., WiFi), mobile communication network, satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the relevant art. The computer system 500 can also include a main memory 508 (e.g., random access memory, read-only memory, etc.) and can also include an auxiliary memory 510. The auxiliary memory 510 can include a hard disk drive 512 and a removable storage drive 514, such as a floppy disk drive, tape drive, optical disk drive, flash memory, etc.

[0085] The removable storage drive 514 can read from and / or write to a removable storage unit 518 in a well-known manner. The removable storage unit 518 can 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 universal serial bus port, then the removable storage unit 518 can be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage unit 518 can be a non-transitory computer-readable recording medium.

[0086] In some embodiments, the auxiliary memory 510 can include alternative components for allowing computer programs or other instructions to be loaded into the computer system 500, e.g., a removable storage unit 522 and an interface 520. Examples of such components can include a program cartridge and cartridge interface (e.g., as found in a video game system), a removable memory chip (e.g., EEPROM, PROM, etc.) and associated socket, and other removable storage units 522 and interfaces 520, as will be apparent to those skilled in the relevant art.

[0087] Data stored in the computer system 500 (e.g., in the main memory 508 and / or the auxiliary memory 510) can be stored on any type of suitable computer-readable medium, such as an optical storage device (e.g., optical disk, digital versatile disk, Blu-ray disk, etc.) or a tape storage device (e.g., hard disk drive). The data can be configured in any type of suitable database configuration, such as a relational database, structured query language (SQL) database, distributed database, object database, etc. Suitable configurations and storage types will be apparent to those skilled in the relevant art.

[0088] The computer system 500 may also include a communication interface 524. The communication interface 524 may be configured to permit software and data to be transferred between the computer system 500 and external devices. Exemplary communication interfaces 524 may include a modem, a network interface (e.g., an Ethernet card), a communication port, a PCMCIA slot and card, and the like. The software and data transferred via the communication interface 524 may be in the form of signals, which may be electrical, electromagnetic, optical, or other signals, as will be apparent to those skilled in the relevant art. The signals may travel via a communication path 526, which may be configured to carry signals and may be implemented using wires, cables, optical fibers, telephone lines, cellular phone links, radio frequency links, and the like.

[0089] The computer system 500 may also include a display interface 502. The display interface 502 may be configured to permit data to be transferred between the computer system 500 and an external display 530. Exemplary display interfaces 502 may include a High-Definition Multimedia Interface (HDMI), a Digital Visual Interface (DVI), a Video Graphics Array (VGA), and the like. The display 530 may be any suitable type of display for displaying data transmitted via the display interface 502 of the computer system 500, including a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light-emitting diode (LED) display, a capacitive touch display, a thin film transistor (TFT) display, and the like.

[0090] The computer program medium and computer-usable medium may refer to memories such as the main memory 508 and the secondary memory 510, which may be memory semiconductors (e.g., DRAM, etc.). These computer program products may be components 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 the secondary memory 510. The computer program may also be received via the communication interface 524. When such a computer program is executed, it may enable the computer system 500 to implement the methods discussed herein. In particular, when the computer program is executed, it may enable the processor device 504 to implement the methods shown by Figure 3A , Figure 3B and Figure 4 as discussed herein. Thus, such a computer program may represent the controller of the computer system 500. In the case of implementing the present disclosure using software, the software may be stored in a computer program product and loaded into the computer system 500 using a removable storage drive 514, an interface 520, and a hard disk drive 512 or a communication interface 524.

[0091] 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 cases, may also utilize software such as program code and / or programs stored in the main memory 508 or the secondary memory 510. In such cases, the program code may be compiled by the processor device 504 (e.g., by a compilation module or engine) before being executed by the hardware of the computer system 500. For example, the program code may be source code written in a programming language that is translated into a lower-level language (such as assembly language or machine code) for execution by the processor device 504 and / or any additional hardware components of the computer system 500. The compilation process may include using lexical analysis, preprocessing, parsing, semantic analysis, syntax-directed transformation, code generation, code optimization, and any other techniques that may be suitable for converting the program code into a lower-level language suitable for controlling the computer system 500 to perform the functions disclosed herein. It will be apparent to those skilled in the relevant art that such processing results in the computer system 500 being a specially configured computer system that is specifically programmed to perform the functions discussed above.

[0092] The techniques consistent with this disclosure provide, among other features, systems and methods for facilitating licensed cryptographic transactions across service providers. While various exemplary embodiments of the disclosed systems and methods have been described above, it should be understood that they are presented for purposes of illustration only and not limitation. This is not an exhaustive list and does not limit the disclosure to the exact forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the disclosure without departing from the breadth or scope.

Claims

1. A method for facilitating permission - based encrypted transactions across service providers, comprising: receiving, by a receiver of a processing server, a join request from a first computing system that includes at least permission data and an identification value, wherein the identification value is associated with a first blockchain wallet for a blockchain associated with a blockchain network; generating, by a processor of the processing server, a permission token and an alias based at least on the permission data, wherein the permission token includes one or more verified identity data points; transmitting, by a transmitter of the processing server, the generated alias to the first computing system in response to the received join request; receiving, by a receiver of the processing server, a token request from a second computing system, wherein the token request includes the alias; and transmitting, by a 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 the following: geographical location, age, income, identity verification status, compliance status, etc.

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

5. The method according to claim 1, wherein the join request does not include any personally identifiable information.

6. The method according to claim 1, further comprising: generating, by the second computing system, a new blockchain transaction that 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; and transmitting, by the second computing system, the generated new blockchain transaction to a blockchain node in the blockchain network for addition to the blockchain.

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

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

9. A system for facilitating permission - based encrypted transactions across service providers, comprising: a blockchain network; a first computing system; a second computing system; and a processing server, the processing server including a receiver that receives, from the first computing system, a join request that includes at least permission data and an identification value, wherein the identification value is associated with a first blockchain wallet for a blockchain associated with the blockchain network, a processor that generates a permission token and an alias based at least on the permission data, wherein the permission token includes one or more verified identity data points, and a transmitter that transmits the generated alias to the first computing system in response to the received join request, wherein The receiver of the processing server receives a token request from the second computing system, where the token request includes the alias, and the transmitter of the processing server transmits at least the generated permission token and the identification value to the second computing system in response to the received token request.

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 the following: geographical location, age, income, identity verification status, compliance status, etc.

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

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

14. The system according to claim 9, wherein the second computing system generates a new blockchain transaction, the blockchain transaction including at least a transaction amount, one or more unspent transaction outputs, and one of the identification values or a destination address generated using the identification value, and transmits the generated new blockchain transaction to a blockchain node in the blockchain network for addition to the blockchain.

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

16. The system according to claim 9, wherein the first computing system is associated with a first virtual asset service provider, and the second computing system is associated with a second virtual asset service provider.

Images