NFT Enforcement Control System

A computer-based system, method, and computer program product for enforcing conditional transfer of digital assets leverage a cross-chain clearinghouse control system implemented upon one or more blockchain networks. The cross-chain clearinghouse control system is configured to approve a transfer of a digital asset if the transfer satisfies an encoded condition or rule configured in the digital asset. Likewise, the cross-chain clearinghouse control system is configured to disapprove and thereby block the transfer if the transfer does not satisfy such a condition or rule. One of a first and second entity involved in the transfer is a digital wallet implemented upon the blockchain network, and an other of the first and second entities is implemented apart from the blockchain network.

BACKGROUND

A blockchain may be implemented as a peer-to-peer (P2P), electronic ledger that is implemented as a computer-based decentralized, distributed system made up of blocks, which, in turn, are made up of transactions. Each transaction may be a data structure that encodes a transfer of control of a digital asset between participants in the blockchain system, and that includes at least one input and at least one output. Each block may contain a hash of a previous block so that blocks become chained together to create a permanent, unalterable record of all transactions that have been written to the blockchain since its inception. Transactions may contain small programs, known as scripts, embedded into their inputs and outputs; the scripts may specify how and by whom the outputs of the transactions can be accessed.

Blockchain may be used for implementation of “smart contracts” that can be associated with digital asset. These are computer programs designed to automate execution of terms of a machine-readable contract or agreement. Unlike a traditional contract, which would be written in natural language, a smart contract is a machine-executable program that may include rules for processing inputs to generate results; these results may then cause actions to be performed depending upon those results. With respect to commercial transactions, for example, these may involve a transfer of property rights and/or assets.

An area of blockchain-related interest is the use of “tokens” to represent and transfer assets via the blockchain. A token serves as an identifier that allows an asset to be referenced from the blockchain. Fungible tokens are uniform. In other words, fungible tokens of the same type are identical in specification, and each fungible token is identical to another fungible token of the same type. Fungible tokens may be divisible into smaller amounts. Similar to currency, where bills can be divided into coins of an equivalent value, fungible tokens may be divisible. Non-fungible tokens (NFTs), however, cannot be replaced with other tokens of the same type. NFTs represent non-fungible assets. Non-fungible assets have unique information or attributes. Each NFT is unique and differs from other tokens of the same class, and, unlike a fungible token, NFTs typically cannot be divided. Blockchain gaming systems may use tokens or NFTs to create different parts of the game, such as rules, characters, weapons, and skins.

Cryptocurrency wallets may be implemented to securely store and manage blockchain assets, tokens, NFTs, and cryptocurrencies. These wallets may allow users to spend, receive, and trade digital assets.

SUMMARY

While a blockchain-enabled platform for minting and transferring ownership of digital assets can be configured to effectively enforce rules governing transfers of digital assets with that blockchain platform, extending enforcement of such rules when the digital asset is transferred another blockchain system may not be viable. The application programming interface that enables a transfer of a digital asset, such as an NFT, from one blockchain platform to another, typically lacks functionality for extending enforcement of smart contracts across blockchain platforms or electronic wallets. A prevailing problem with NFTs, for example, is often that the creator's royalty is tied to the marketplace where the NFT was originally minted. A further issue is that a creator of an NFT may be unable to prevent a buyer of that NFT from listing its NFT on other, competing blockchain systems.

Further, blockchain-enabled marketplace for digital assets can be configured to effectively enforce rules (preset rules/conditions encoded in the digital assets) governing transfers of digital assets occurring within such a marketplace, but existing marketplaces lack functionality for extending enforcement of such encoded rules to transfers involving one or more entities that exist apart from the blockchain network supporting said marketplace. Such transactions may involve, for example, two or more separate blockchain networks, or may even occur in an undetectable offline manner. Motivation for conducting transactions outside the confines of a given marketplace may include avoiding payment of royalties, taxes, or a full price of an item available within the given marketplace. Alternatively, malicious actors may seek to breach security protocols of the blockchain network and conduct a backdoor transaction at little to no cost, for personal gain. In order to preserve value of digital assets and ensure that sellers and creators thereof are effectively compensated according to agreements backed by the given marketplace, it is desirable for the given marketplace to possess means of enforcing such agreements and encoded rules governing transfers of said digital assets, regardless of whether or not said transfers occur entirely within the given marketplace.

Such transactions may involve, for example, two or more separate blockchain networks, or may even occur in an undetectable offline manner. Motivation for conducting transactions outside the confines of a given marketplace may include disengaging the smart contract code associated with the digital asset, or avoiding payment of royalties, taxes, or a full price of an item available within the given marketplace. Alternatively, malicious actors may seek to breach security protocols of the blockchain network and conduct a backdoor transaction at little to no cost, for personal gain. In order to preserve value of digital assets and ensure that sellers and creators thereof are effectively compensated according to agreements backed by the given marketplace, it is desirable for the given marketplace to possess means of enforcing such agreements and encoded rules governing transfers of said digital assets, regardless of whether or not said transfers occur entirely within the given marketplace.

Embodiments include a computer-based system for enforcing conditional transfer of digital assets. In some embodiments, the system includes a first blockchain network with multiple nodes. One of the multiple nodes of the first blockchain network may have a secure cryptoprocessor implemented as a dedicated microprocessor configured to execute a cross-chain clearinghouse control system The cross-chain clearinghouse control system may be embedded on the secure cryptoprocessor and configured to approve a cross-chain transfer of a digital asset from a first entity to a second entity if the transfer satisfies a preset rule encoded in the digital asset or disapprove the transfer if the transfer does not satisfy the rule. One of the first and second entities may be a digital wallet implemented upon the first blockchain network, and an other of the first and second entities may be implemented on a second blockchain network, separate and disparate from the first blockchain network.

In some embodiments, the preset rule encoded in the digital asset may trigger a royalty requirement that automatically causes recursive asset transfer back to a creator or prior owner of the digital asset upon transfer of the digital asset. The preset rule encoded in the digital asset may trigger a fractionalized royalty model that requires enforcement of a distributed royalty arrangement. The first and second blockchain networks may be respectively configured to support first and second digital asset platforms.

The other of the first and second entities may be implemented upon the second blockchain network at a network location separate from a corresponding network location of the first blockchain network. Alternatively, the other of the first and second entities may be an offline entity.

In some embodiments, the multiple nodes may be configured to create a token representing the digital asset. In these embodiments, the preset rule encoded in the digital asset may be configured to influence a transaction value of the digital asset. Such a transaction value may be reflected in a value of the created token.

The preset rule encoded in the digital asset may include a threshold value pertaining to a transaction value of the digital asset. In some such embodiments, the preset rule encoded in the digital asset may be configured to implement a transaction value floor for the transfer of the digital asset. The clearinghouse control system may include a minimax recursive algorithm to control the transaction value floor and the threshold value. In other such embodiments, the preset rule encoded in the digital asset may be configured to require a transaction value of the digital asset to remain within a bounded percentage of a transaction value change from a prior transaction.

The first blockchain network may be decentralized. The preset rule encoded in the digital asset may include a smart contract. The digital asset may be a non-fungible token (NFT).

Embodiments further include a computer-implemented method of enforcing conditional transfer of digital assets. In some embodiments, the method includes implementing, upon a blockchain network, a cross-chain clearinghouse control system configured to approve a transfer of a digital asset from a first entity to a second entity in response to the transfer satisfying a preset rule encoded in the digital asset or disapprove the transfer in response to the transfer not satisfying the rule. The cross-chain clearinghouse control system may be embedded on a cryptoprocessor of one of multiple nodes of the blockchain network. One of the first and second entities may be a digital wallet implemented upon the blockchain network, and an other of the first and second entities may be implemented apart from the blockchain network.

Embodiments further include a non-transitory computer program product for enforcing conditional transfer of digital assets. In some embodiments, the non-transitory computer program product includes a computer-readable medium with computer code instructions stored thereon. The computer code instructions are configured, when executed by a processor, to cause the processor to implement, upon a blockchain network, a cross-chain clearinghouse control system configured to approve a transfer of a digital asset from a first entity to a second entity in response to the transfer satisfying a preset rule encoded in the digital asset or disapprove the transfer in response to the transfer not satisfying the rule. The cross-chain clearinghouse control system may be embedded on a cryptoprocessor of one of multiple nodes of the blockchain network. One of the first and second entities may be a digital wallet implemented upon the blockchain network, and an other of the first and second entities may be implemented apart from the blockchain network.

Alternative method and computer program product embodiments parallel those described above in connection with the example computer-based system embodiments.

It should be understood that example embodiments disclosed herein can be implemented in the form of a computer-implemented method, apparatus, computer-based system, or computer program product.

DETAILED DESCRIPTION

A description of example embodiments follows.

In general, blockchain is a write-once, append-many type electronic ledger. Blockchain is an architecture that allows disparate users to make transactions and creates an unchangeable record of those transactions. To move anything of value over any kind of blockchain, a network of nodes must first agree that a corresponding transaction is valid. As a peer-to-peer (P2P) network, combined with a distributed time-stamping server, blockchain ledgers can be managed autonomously to exchange information between disparate parties; there is no need for an administrator. In effect, the blockchain users are the administrator.

Blockchain's rapid development has given rise to many different kinds of chains, leading to cross-chain technology. Cross-chain, as its name suggests, allows the transmission of value and information between different blockchains. According to an example embodiment, a digital asset may be exchanged, cross-chain, securely, and despite differences between constraints or rules of operation that may be established for the different blockchains. Such a digital asset may be in the form of a token, which may be fungible, or may be a non-fungible token (NFT). Such constraints or rules may be in the form of smart contracts, or other forms. Differences between such constraints or rules may include disparate levels of rigor or leniency of such constraints or rules between or among different blockchain networks.

In some embodiments, blockchain may be a peer-to-peer (P2P), electronic ledger that is implemented as a computer-based decentralized, distributed system made up of blocks, which, in turn, are made up of transactions. Each transaction may be a data structure that encodes a transfer of control of a digital asset between participants in the blockchain system, and that includes at least one input and at least one output. Each block may contain a hash of a previous block so that blocks become chained together to create a permanent, unalterable record of all transactions that have been written to the blockchain since its inception. Transactions may contain small programs, known as scripts, embedded into their inputs and outputs; the scripts may specify how and by whom the outputs of the transactions can be accessed.

For a transaction to be written to the blockchain, it must be “validated.” Network nodes (miners) may perform work to ensure that each transaction is valid, with invalid transactions being rejected from the network. Software clients installed on the nodes may perform this validation work on an unspent transaction (UTXO) by executing its locking and unlocking scripts. If execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and is written to the blockchain. Thus, for a transaction to be written to the blockchain, it should be: (i) validated by a first node that receives the transaction—e.g., if the transaction is validated, the node relays it to other nodes in the network; (ii) added to a new block built by a miner; and (iii) mined, e.g., added to the public ledger of past transactions.

Blockchain may be used for implementation of “smart contracts” that can be associated with digital asset. These are computer programs designed to automate execution of terms of a machine-readable contract or agreement. Unlike a traditional contract, which would be written in natural language, a smart contract is a machine-executable program that may include rules for processing inputs to generate results; these results may then cause actions to be performed depending upon those results. With respect to commercial transactions, for example, these may involve a transfer of property rights and/or assets. Such assets may include real property, personal property (including both tangible and intangible property), digital assets such as software, or any other type of asset. In the digital economy, there is often an expectation that exchanges and transfers will be performed in a timely manner and across vast distances. This expectation, along with practical, technical limitations, means that traditional forms of asset transfer, such as physical delivery of hardcopy of documents representing a contract, negotiable instrument, etc., or a tangible asset itself, are not desirable. Thus, smart contracts can provide enhanced control, efficiency, and speed of transfer.

An area of blockchain-related interest is a use of “tokens” to represent and transfer assets via the blockchain. A token thus serves as an identifier that allows a real-world item to be referenced from the blockchain. Through an initial coin offering (ICO) model, startups may raise capital by issuing tokens on a blockchain, such as Ethereum, and distributing them to token buyers in exchange for making a financial contribution to a project. These tokens, which may be transferred across a network and traded on cryptocurrency exchanges, may serve a multitude of different functions, from granting holders access to a service to entitling them to company dividends. Depending on their function, tokens may be classified as security tokens or utility tokens.

Tokens may be used, for example in an initial public offering (IPO) to issue company shares, dividends, and voting rights over blockchain networks. The tokens may include security tokens and utility tokens. The security tokens may be associated with a value that is derived from a tradable asset and, thus, may be deemed a security token that may be subject to federal laws regulating traditional securities. In contrast, the utility tokens may represent future access to a company's product(s) or service(s). A defining characteristic of the utility token is that it is not designed as an investment. Because a utility token is not issued in a form of an investment asset, it may be exempt from having to comply with federal legislation regulating securities.

Further, similar to physical assets, the tokens that represent them may have many properties, one of which is fungibility or non-fungibility. In economics, fungibility refers to equivalence or interchangeability of each unit of a commodity with other units of the same commodity. Fungible tokens (FTs) are tokens that can be exchanged for any other token with the same value.

Fungible tokens are uniform, that is, FTs of the same type are identical in specification. In other words, each fungible token (FT) is identical to another FT of the same type, and FTs are divisible into smaller amounts. Similar to currency, where bills can be divided into coins of an equivalent value, FTs are divisible. As such, a fraction of an FT can be transferred between users. Nonfungible tokens (NFTs), however, cannot be replaced with other tokens of the same type. NFTs represent nonfungible assets, e.g., assets that have unique information or attributes. Each NFT is unique and differs from other tokens of the same class. For example, while plane tickets from and to a same destination may look the same, each one has a different passenger name, seat number, etc., and, therefore, is unique. In contrast to FTs, NFTs cannot be divided, an elementary unit of the NFT is the token itself.

Due to an immutable nature of transaction histories supported by blockchain networks, it is possible to extend the aforementioned validation steps of such transactions so that the transactions become subject to certain rules that reference prior transactions, or even aspects of an initial creation of a subject digital asset, e.g., NFT. An example of such rules is an arrangement wherein royalties are paid to a creator of a digital asset each time the digital asset is sold to a subsequent owner. Such royalty payment arrangements may be implemented as a function with which the blockchain network is programmed, or using a reference table loaded into a computer memory element of the blockchain network, as a smart contract as described hereinabove, or by other means.

A further use case for cryptocurrency exchanges on a blockchain network is that such exchanges can protect transactions—similar to a manner in which a surety bond would. A surety bond or surety is a promise by a surety or guarantor to pay one party a certain amount if a second party fails to meet some obligation, such as fulfilling terms of a contract. The surety bond protects an obligee against losses resulting from a principal's failure to meet the obligation. As cryptocurrencies evolve from fringe investments to mainstream instruments, surety bonds may become an increasingly common requirement for those looking to trade in virtual currencies.

Ordinary surety bonds act as a contract between three parties: (i) an entity requesting the bond (principal), (ii) the bond's beneficiary (obligee), and (iii) a company issuing the bond. What a surety bond does is guarantee that the principal will fulfill its obligations, whether it's completing a long-term project or processing a financial transaction, or else forfeit the bond. Cryptocurrency surety bonds work in the same basic manner, ensuring that the principal performs cryptocurrency transactions as expected, or else forfeits the bond. In this case, the contract is between an entity handling a virtual currency transaction, a regulatory entity requiring the surety bond, and a surety bond provider.

A composable digital asset integrates two or more individual digital assets into a new combined form, which may be referred to as an asset cluster. An asset cluster may comprise components of similar or different types. For example, an asset cluster may include an element of fungible currency such as cryptocurrency, along with a non-fungible token (NFT). Thus, combining an amount of cryptocurrency with an NFT may effectively establish a floor price for the NFT equal to the value of the fungible cryptocurrency.

Such composable assets may find applications in areas such as finance and gaming. An example embodiment of a gaming application of composable digital assets may involve a piece of armor having a socket, into which a gem may be placed, creating an asset cluster. Asset clusters may be decomposed at any time such that the NFT and the currency item again become separate entities on a digital exchange platform.

Composable digital assets may provide liquidity for any digital asset or token. For example, a player of a game incorporating composable digital asset clusters may use a currency component of a cluster to set an instantaneous price at which to sell the cluster, such as to an automated market maker (AMM) associated with the game. Composable assets may be referenced or required by contracts or rules governing transactions on a digital exchange platform, such as smart contracts.

An AMM may be configured to provide liquidity to a platform enabling exchange of digital assets as described herein. The exchange platform may be decentralized. Liquidity may be provided using underlying collateral. An AMM may take in and store different forms of digital assets, such as loans, to be used as collateral in future exchanges on the platform. Such assets may be aggregated within a collateral pool, such that liquidity is pooled in association with the exchange platform. Liquidity may thus be pooled and aggregated on a blockchain supporting the collateral pool. Assets may be withdrawn from the collateral pool upon minting a collateral token. The collateral token may thus consolidate liquidity for an exchange within one protocol or contract. In addition, the collateral token may provide liquidity for a one-to-one exchange with a user looking to sell or redeem a user-held token.

A cross-chain clearinghouse control system implemented upon a platform may be configured to force an exchange to be performed on the platform such that the exchange is managed by an AMM. A pricing function of the AMM may set a price for a collateral token, and may offer the collateral token for exchange at such a price, thus dictating a market price for that token, rather than deferring to market forces. The AMM may function with either a bounded or an unbounded token supply, providing continuous liquidity. In addition, the AMM may be configured to measure supply and demand for tokens on the platform, including the collateral tokens.

A digital asset marketplace may leverage a cross-chain clearinghouse control system to enforce a contract governing transfer of tokens between electronic wallets. The contract may specify royalties to be paid to an original creator of a token upon transactions involving that token. In addition, the contract may include a revenue share table. The cross-chain clearinghouse control system may be configured to enforce the contract regardless of network locations of two parties involved in a transaction, and regardless of whether or not the transaction is conducted within a digital asset marketplace. For example, even offline exchanges may be made transparently viewable from within the digital asset marketplace. The cross-chain clearinghouse control system may be configured to serve any token creator. The cross-chain clearinghouse control system may including a minimax recursive algorithm to facilitate a threshold value associate with the token.

In another embodiment, upon creation of a token, a threshold value of that token may be set within the digital asset marketplace. The cross-chain clearinghouse control system may implement rules in conjunction with the threshold value to prevent a value of the token from experiencing dramatic changes characteristic of backdoor or offline transactions. As such, the threshold value may act as a floor price of the token required to activate any transaction involving the token. The cross-chain clearinghouse control system may manage and approve or deny transactions accordingly. Rules such as threshold values may be based on a bounded percentage of a price change from a previous transaction. Such a cross-chain clearinghouse control system may be implemented in a decentralized manner, such as with a smart contract. A central authority is thus not required.

Certain embodiments may offer techniques for verifying or checking an identity that protect, preserve, and maintain privacy. Safeguarding privacy within blockchain networks is an important consideration for traditional institutions such as banks and other financial institutions that may desire to interact with and/or launch smart contracts, for example, as part of digital asset transactions, but may also need to keep trade secrets and/or sensitive customer information etc. confidential. As to the latter, such institutions may also be required to comply with rules and/or regulations including, but not limited to, the Europe Union's General Data Protection Regulation (GDPR) and the United States' Health Insurance Portability and Accountability Act (HIPAA), among other examples.

In an example embodiment, the cross-chain clearinghouse control system may be accomplished by use of, e.g., a “zero-knowledge proof” (ZKP). A zero-knowledge proof implementation in the cross-chain clearinghouse control system ensures enforcement of encoded rules configured in NFT assets utilizing a technique whereby a first entity (or “prover”), such as first transacting entity, a first wallet etc., may cryptographically prove to a second transacting entity (or “verifier”) that the first entity possesses knowledge regarding certain information regarding the encoded rules in configured in the NFT, without also disclosing the actual contents of the information.

Zero-knowledge proofs may be interactive or non-interactive. An interactive ZKP requires interaction between a prover entity and a verifier entity involved in an NFT encoded rule enforcement transaction processed by the cross-chain clearinghouse control system. A non-interactive ZKP may be constructed from any interactive scheme by relying on, e.g., a Fiat-Shamir heuristic, or any other suitable technique known to those of skill in the art.

According to an embodiment, a protocol implementing ZKPs may be presented as a transcript where a prover (first entity) responds to interactive inputs from a verifier (second entity). In one such embodiment, the interactive input may be in the form of one or more challenges such that responses from the prover will convince the verifier if and only if a statement is true, e.g., if the prover does possess certain claimed knowledge.

In the context of blockchain networks, according to some embodiments, by employing a ZKP, the only information divulged on-chain is that some piece of undisclosed information is (i) valid and (ii) known by the prover with a high degree of certainty. As such, in an embodiment, zero-knowledge proofs may be used by various blockchains to furnish privacy-maintaining digital asset transactions, whereby, for example, a transaction's amount, sender electronic wallet identifier, and receiver electronic wallet identifier are kept secret. Furthermore, some embodiments relate to oracle networks that provide smart contracts with access to off-chain data and/or computing infrastructure. Such oracle networks may also employ ZKPs to prove a certain fact about off-chain data, without divulging the data itself on-chain. A method used for performing non-interactive ZKPs may be as described in D. Unruh, “Non-Interactive Zero Knowledge Proofs in the Random Oracle Model,” inEUROCRYPT2015, 2015, pp. 755-84, which is herein incorporated by reference in its entirety.

A digital wallet, such as a hybrid multisignature digital wallet may enable a licensed custodian or designee to provide signatures or keys required to approve a digital transaction. The custodian may approve transfers of tokens on digital exchange platforms such as blockchain platforms. A set of custodian signatures, potentially from multiple custodians, may be required to approve a transaction. Alternatively, the hybrid multisignature wallet may be configured in a one-of-many or a one-of-one setup, requiring only a single signature of one or more valid signatures from one or more custodians to approve the transaction. If a network allows a designated party to be a custodian, that party may enter into an agreement at a protocol level on the network to become a designated custodian. The hybrid multisignature wallet may be implemented in support of compliance operations. The custodian may facilitate recovery or replacement of lost signatures or keys, or of entire lost wallets.

The hybrid multisignature wallet may enable transactions such as token swaps, and may facilitate transfer of tokens across multiple networks. Individual networks of the multiple networks may implement rigorous or lenient constraints upon transactions performed within the respective networks. Thus, a disparity may exist between two networks involved in a token transfer. The custodian may facilitate management of such a disparity. The custodian may perform functions characteristic of an automated escrow service in conjunction with a digital exchange platform.

FIG.1is a block diagram of an example embodiment of a system100for enforcing conditional transfer of digital assets. The system100comprises a blockchain network105-1, and another entity105-2. Other entity105-2may be a second blockchain network where blockchain network105-1is a first blockchain network. Alternatively, other entity105-2may be a user of a marketplace platform, or a client device of such a user, with a location upon blockchain network105-1that differs from a holder of digital asset120. In still other cases, other entity105-2may be a non-blockchain online entity, or even an offline entity such as a person acquainted with a holder of digital asset120.

Continuing with respect toFIG.1, blockchain network105-1includes multiple nodes110-1,110-2, through110-n. It is assumed inFIG.1that n, the number of nodes in blockchain network105-1, is greater than or equal to three; however, this may not always be the case, as embodiments may function with as little as two nodes110-1,110-2in the multiple nodes of blockchain network105-1, or even with a single node110-1instead of multiple nodes. At least a subset110-1,110-2of the plurality of nodes110-1,110-2, through110-nmay be configured to provide digital wallet115enabling storage of digital asset120therein. It should be noted that any number of nodes less than n may comprise such a subset, and that, alternatively, all n nodes of blockchain network105-1may be configured to provide digital wallet115.

To continue, upon blockchain network105-1is implemented cross-chain clearinghouse control system125configured to (i) approve145a transfer of digital asset120from a first entity to a second entity if the transfer satisfies140the encoded preset rule130associated with digital asset120or (ii) disapprove155the transfer if the transfer does not satisfy150rule130. InFIG.1, the first entity is shown to be blockchain network105-1and the second entity is shown to be other entity105-2. It should be noted, however, that multiple entities affiliated with blockchain network105-1may be enabled to act as the first and second entities, such that a transfer of digital asset120occurs among entities at different network locations on the same blockchain network105-1. Alternatively, it should be noted that the first entity may in fact be other entity105-2, and likewise the second entity may correspond to blockchain network105-1, such that a transfer of digital asset120occurs from other entity105-2to blockchain network105-1, in a direction opposite to that shown inFIG.1. As such, one of the first and second entities may be or include digital wallet115, which may be implemented upon blockchain network105-1, while other entity105-2may be implemented separately from blockchain network105-1.

In some embodiments of system100, rule130specifies a royalty to be paid to a creator or prior owner of digital asset120upon transfer of digital asset120. Similar to a configuration described above, blockchain network105-1may be a first blockchain network, and other entity105-2may be implemented upon a second blockchain network. In such embodiments, the first and second blockchain networks may be respectively configured to support first and second digital asset platforms. Similar to another configuration described above, other entity105-2may be implemented upon blockchain network105-1at a network location separate from a corresponding network location of an entity embodying or including digital wallet115. In some configurations, other entity105-2may be an offline entity.

In some embodiments of system100, the multiple nodes110-1,110-2, through110-nmay be configured to create a token representing digital asset120. In some such embodiments, an encoded rule or condition130configured in the digital asset120may influence a price of digital asset120. The encoded rule130configured in the digital asset120may include a threshold value pertaining to a price of digital asset120. In some such embodiments, the encoded rule130configured in the digital asset120may implement a price floor for a transfer of digital asset120. Alternatively, or in addition, rule130associated with digital asset120may require a price of digital asset120to remain within a bounded percentage of a price change from a prior transaction.

In some embodiments, blockchain network105-1may be decentralized. The rule130associated with digital asset120may include a smart contract. The digital asset120may be a non-fungible token (NFT).

FIG.2is a flow diagram of an example embodiment of a computer-implemented method200of enforcing conditional transfer of digital assets such as digital asset120. In some embodiments, method200starts202by implementing204, upon a blockchain network such as blockchain network105-1, a cross-chain clearinghouse control system125. The cross-chain clearinghouse control system125may be configured to determine206whether a transfer of digital asset120from a first entity to a second entity satisfies a preset rule130encoded in digital asset120. In response to the transfer satisfying208rule130, cross-chain clearinghouse control system125approves212the transfer. Alternatively, in response to the transfer not satisfying210rule130, cross-chain clearinghouse control system125disapproves214the transfer. The method200thereafter ends216in the example embodiment. In such embodiments, one of the first and second entities is a digital wallet115implemented upon blockchain network105-1, and an other105-2of the first and second entities is implemented apart from the blockchain network.

In some embodiments of method200ofFIG.2, rule130may be configured to specify a royalty to be paid to a creator or prior owner of digital asset120upon transfer of digital asset120. The rule130may be further configured to implement a fractionalized royalty model that requires enforcement of a distributed royalty arrangement. In addition, blockchain network may be a first blockchain network105-1, and the other entity may be implemented upon a second blockchain network105-2. According to such embodiments, method200may further include configuring the first105-1and second105-2blockchain networks to respectively support first and second digital asset platforms.

In some embodiments of method200, other entity105-2may be implemented upon blockchain network105-1at a network location separate from a corresponding network location of an entity embodying or including digital wallet115. In some configurations, other entity105-2may be an offline entity.

In some embodiments, method200may include creating a token representing digital asset120, and establishing a threshold value pertaining to a transaction value of digital asset120. A rule such as rule130may be configured to analyze such a threshold value. In some such embodiments, method200may further include implementing, via the threshold value, a transaction value floor for a transfer of digital asset120. Alternatively, or in addition, method200may further include implementing a condition whereby the transaction value of digital asset120remains within a bounded percentage of a transaction value change from a prior transaction, wherein the threshold value is based on the bounded percentage.

In some embodiments, method200may use machine learning (ML) to establish a saddle point pertaining to digital asset120. In this example, rule130may use a minimax model to compute minimum and maximum values for the token to establish a saddle point (maximin). For instance, a minimax ML engine/model may be used to determine minimum and maximum values according to an evaluation function for minimizing the possible loss for a worst case (maximum loss and maximum gain) scenario associated with the token. A blockchain system, e.g., system100, for example, may automatically and adaptively select the saddle point of digital asset120using a maximin model of previous set saddle points of digital assets and potential ones. The model may look ahead at all possible values and make a decision for the digital asset.

In some embodiments, method200may include minting a token with built-in security features setting conditions regarding minimum and maximum mint amount, royalties, conditions about permissible computing locations as to where the token can be stored (on- or off-chain), and built-in features including randomness, rarity, and voting rights. For example, the token may be configured with custody security enabling it to be stored off-chain on a hardware security module (HSM). The HSM may create and hold private keys and secret keys securely so that they may not be extracted. The HSM may also provide an ability to perform some selected cryptographic operations with the keys.

In some embodiments of method200, blockchain network105-1may be decentralized. The rule130associated with digital asset120may include a smart contract. The digital asset120may be a non-fungible token (NFT).

FIG.3is a simplified block diagram of an example embodiment of a blockchain network300, also referred to interchangeably herein as a distributed ledger network300, that may be accessed according to an example embodiment. The blockchain network300may be employed as blockchain network105-1and/or other entity105-2ofFIG.1, disclosed above. The blockchain network300is a distributed ledger peer-to-peer (P2P) network and is valuable because this network enables trustworthy processing and recording of transactions without the need to fully trust any user (e.g., person, entity, program, and the like) involved in the transactions, reducing the need for trusted intermediaries to facilitate the transaction. Existing applications use the distributed ledger network300to transfer and record, in the form of blockchain based records, movement of tokens. Such blockchain based records form a cryptographically secured backlinked list of blocks.

The distributed ledger network300includes multiple computing devices configured as nodes310,320,330,340,350,360of the distributed ledger network300. Each node310,320,330,340,350,360locally stores and maintains a respective identical copy315,325,335,345,355,365of the blockchain ledger in memory communicatively coupled to the node. The nodes exchange messages within the distributed ledger network300to update and synchronize the ledger stored and maintained by each node. The nodes may also execute decentralized applications (decentralized apps or “dApps”), such as via smart contracts, for processing the messages. An example message transmission370from node310to node340may be used to exchange a token in the distributed ledger network300as shown inFIG.3. Dotted lines between each set of nodes in the distributed ledger network300indicate similar transmissions that may be exchanged between any other set of nodes in the distributed ledger network300. The messages may include a confirmed transfer for recording data associated with a token being transferred, a blockchain public key for each of one or more parties participating in the transfer.

Referring back toFIG.1, according to an example embodiment, blockchain network105-1or other entity105-2may be an Ethereum network; however, it should be understood that blockchain network105-1and other entity105-2may be any suitable known blockchain networks. Ethereum is a decentralized network of computers with two basic functions: (i) a blockchain that can record transactions and (ii) a virtual machine (VM), that is, an Ethereum Virtual Machine (EVM), that can produce smart contracts. Because of these two functions, Ethereum is able to support decentralized applications (dApps). These dApps are built on the existing Ethereum blockchain, piggybacking off its underlying technology. In return, Ethereum charges developers for computing power in its network, which can only be paid in Ether, the only inter-platform currency. Depending on its purpose, a dApp may create ERC-20 (Ethereum Request for Comments20) tokens to function as a currency. According to an example embodiment, fungible tokens (FTs) disclosed herein may be ERC-20 tokens or any other suitable FT known to those of skill in the art.

The code of the smart contract may be uploaded on the EVM, that may be a universal runtime compiler or browser, to execute the smart contract's code. Once the code is on the EVM, the code may be the same across each Ethereum node to be run to check whether the conditions are met, such as a condition for the balance reaching the trade value prior to expiration of the expiration term.

Ethereum has a long history of developed standards. For example, ERC-20 is a standard that defines a set of six functions that other smart contracts within the Ethereum ecosystem can understand and recognize. ERC-20 is a protocol standard and to be compliant with ERC-20, the functions need to be included in a token's smart contract. ERC-20 outlines a specific list of rules that a given Ethereum-based token must deploy, simplifying a process of programming the functions of tokens on Ethereum's blockchain. These include, for instance, how to transfer a token (by an owner or on behalf of the owner), such as may be employed for transferring fungible tokens (FTs) of a buyer, and how to access data (e.g., name, symbol, supply, balance, etc.) concerning the token, such as a value of digital asset120in digital wallet115(FIG.1).

Alternatively, other entity105-2may be a non-blockchain online system or access point by which a party to a transaction involving a digital asset, e.g., digital asset120, may connect to blockchain network105-1. In still other cases, other entity105-2may be a user device other than a creator or owner of the digital asset, which transaction may thus take place in an offline manner.

FIG.4is a simplified block diagram showing exemplary blockchain layers400according to an embodiment. Blockchain layers400may include infrastructure (tier1) layer410, data (tier2) layer420, network (tier3) layer430, consensus (tier4) layer440, and application (tier5) layer450. The infrastructure layer410may be a hardware layer and may include one or more virtual machines (VMs)411and/or one or more oracles412. A virtual machine (VM)411may provide a runtime environment for transaction execution in the blockchain. In an embodiment, a VM411may be, for example, stack-based and may enable untrusted code to be executed by a global peer-to-peer (P2P) network of computers. An oracle412may provide a third-party service that connects smart contracts executing on the blockchain with off-chain data sources. For example, an oracle412may query, verify, and/or authenticate one or more external data sources. According to an embodiment, external data sources may include, e.g., one or more legacy systems414and/or one or more external databases413.

According to an embodiment, an oracle node architecture, e.g., oracle412, may be provided to serve machine learning (ML) models for smart contracts on a blockchain. Such an architecture may be referred to as a “ML oracle.” The ML oracle is useful to smart contract developers who want to incorporate ML models into their smart contracts. For example, a smart contract may distribute funds based on an algorithm, and the algorithm may include a ML model that forecasts sales of a product for a given week. The smart contract may invoke an inference call to a model on the ML oracle to obtain the forecast. As a further example, there are generative arts where the generative ML model may be an integral part of an artwork. Interaction with the model to generate new images may be part of a viewing experience. One well-known ML model type used by generative art is a generative adversarial network (GAN). Using the ML oracle, the ML model may become part of an NFT, thereby enabling an interactive viewing experience.

To summarize, in an embodiment, a smart contract may request an inference call to a ML model by identifying an ML model to call, such as by providing a hash value, and an input to the model. According to one such embodiment, a model file may be uploaded to, e.g., IPFS (InterPlanetary File System) or any other suitable known storage system, by a dApp developer and a model server may download the model file, e.g., using the hash value. For the ML model server to be generic enough to serve a wide range of models, it may also take as an input parameter a model type, e.g., PyTorch, TensorFlow, scikit-learn, or any other suitable known model type, as well as an input and output specification. The input may be data directly received from the calling smart contract, or it may be received indirectly via, e.g., an IPFS Uniform Resource Identifier (URI) or any other suitable identifier known to those of skill in the art. Similarly, the output may be sent back to the smart contract, or it may be uploaded to any suitable known storage system, including, but not limited to IPFS, and the, e.g., URI, may be sent to the smart contract. For example, a forecasting model may use the direct input/output method. An indirect input/output method employing a known storage system such as IPFS may be commonly used by computer vision/imaging models, among other examples.

In an example embodiment, system100(FIG.1) may include a virtual machine (VM), e.g., VM411(FIG.4), with a blockchain oracle, e.g., oracle412.

Continuing withFIG.4, data layer420may interface with infrastructure layer410and may include blockchain implementation421and transaction details422. A blockchain is a decentralized, massively replicated database (distributed ledger), where transactions are arranged in blocks, and placed in a P2P network. The blockchain implementation421may include a data structure represented, for example, as a linked list of blocks, where transactions are ordered. The blockchain implementation421's data structure may include two primary components—pointers and a linked list. Pointers are variables that refer to a location of another variable, and a linked list is a list of chained blocks, where each block has data and pointers to the previous block. Each block may contain a list of transactions that happened since a prior block. Transaction details422may contain information about transactions occurring on the blockchain.

The network layer430may interface with data layer420and may also be referred to as a P2P layer or propagation layer. One purpose of network layer430may be to facilitate node communication431, such that nodes can discover each other and can communicate, propagate, and synchronize with each other to maintain a valid current state of the blockchain. A distributed P2P network, e.g., network layer430, may be a computer network in which nodes are distributed and share the workload of the network to achieve a common purpose. Nodes in network layer430may carry out the blockchain's transactions.

The consensus layer440may interface with network layer430and may ensure that blocks are ordered, validated, and guaranteed to be in the correct sequence. A set of agreements between nodes in a distributed P2P network may be established by the consensus layer440. The agreements result in consensus protocols or algorithms, which correspond to rules that nodes follow in order to validate transactions and create blocks in accordance with those rules. To validate a transaction, a validator, e.g., validator441aor validator441b, may perform a consensus algorithm, such as proof of work442or any other suitable algorithm known in the art. Performing the consensus algorithm may involve expending computational resources to solve a cryptographic puzzle442. After being validated according to a consensus algorithm, a transaction may be written to the blockchain through a process of writing rights443.

The application layer450may interface with consensus layer440and may include customized applications and services, such as electronic wallets451. Further, application layer450may include (not shown): smart contracts, chaincode, and decentralized apps (dApps). The application layer450may also include applications utilized by end users to interact with the blockchain. Such applications may be, e.g., one or more user facing interfaces452. Further, such applications may include, for example (not shown): scripts, application programming interfaces (APIs), and frameworks.

An example implementation of system100(FIG.1) may be implemented in a software, firmware, or hardware environment.FIG.5illustrates one such example digital processing environment500in which embodiments of system100may be implemented. Client computer(s)/device(s)550and server computer(s)/device(s)560provide processing, storage, and input/output (I/O) devices executing application programs and the like.

Client computer(s)/device(s)550may be linked590directly or through communications network570to other computing devices, including other client computer(s)/device(s)550and server computer(s)/device(s)560. Referring toFIGS.5and6(the latter described in more detail hereinbelow), network570utilizes system100according to an embodiment of the invention, for enforcing conditional transfer of digital assets, e.g., digital asset120(FIG.1).

The communication network570may be part of a wireless or wired network, a remote access network, a global network (e.g., the Internet), a worldwide collection of computers, local area networks (LANs) or wide area networks (WANs), and gateways, routers, and switches that may use a variety of known protocols (e.g., TCP/IP, Bluetooth®, etc.) to communicate with one another. Communication network570may also be a virtual private network (VPN) or an out-of-band (00B) network or both. Further, communication network570may take a variety of forms, including, but not limited to, a blockchain network, a distributed ledger network, a data network, voice network (e.g., landline, mobile, etc.), audio network, video network, satellite network, radio network, and pager network. Other known electronic device/computer network architectures are also suitable. For example, client computer(s)/device(s)550may include nodes shown inFIG.3, which run user applications that enable a user to communicate with an application to determine whether a user meets a work requirement. A blockchain network, such as blockchain network105-1(FIG.1), may be configured on each user device310,320(FIG.3) to store tokens. Client computers350(FIG.3) of the computer-implemented system100(FIG.1) may be configured with a trusted execution environment (TEE) or trusted platform module (TPM), where the application may be run and digital assets, e.g., digital asset120, and/or tokens may be stored.

Referring again toFIG.5, server computer(s)/device(s)560of the computer-implemented system may be configured to include a server that that executes the application. For example, the application of server computer(s)/device(s)560may determine whether a user has satisfied a work requirement and produce a determination result and pair, in computer memory, e.g., memory614(FIG.6), an indication of the determination result with an identifier of the user or an identifier of a digital asset of the user, such as an address of a node of a blockchain network accessible by the user. The application of server computer(s)/device(s)560also facilitates a transfer of a collateral token by moving the collateral token to, for example, a digital wallet, e.g., digital wallet115(FIG.1), implemented upon a blockchain network. For another example, server computer(s)/device(s)560or client computer(s)/device(s)550may comprise peer computing devices (nodes)310,320,330,340,350,360of a distributed blockchain ledger300ofFIG.3, which use smart contracts to execute and record transactions implemented via tokens.

FIG.6is a block diagram of any internal structure of a computing/processing node (e.g., client computer(s)/device(s)550or server computer(s)/device(s)560) in the processing environment500ofFIG.5, which may be used to facilitate displaying audio, image, video, or data signal information. Each computer/device550,560inFIG.6may contain a system bus610, where a bus is a set of actual or virtual hardware lines used for data transfer among components of a computer or processing system. System bus610may essentially be a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, I/O ports, etc.), thereby enabling transfer of data between elements or components.

Continuing withFIG.6, attached to system bus610is an I/O device interface611for connecting various input and output devices (e.g., keyboard, mouse, touch screen interface, displays, printers, speakers, audio inputs and outputs, video inputs and outputs, microphone jacks, etc.) to a computer/device550,560. Network interface613may allow a computer/device to connect to various other devices attached to a network, for example network570ofFIG.5. Memory614may provide volatile storage for computer software instructions615and data616used in some embodiments to implement software modules/components of system100(FIG.1).

Software components615,616of system100(e.g., cross-chain clearinghouse control system704, a minimax recursive algorithm, encoder/decoder, Trusted Execution Environment (TEE), blockchain layer1virtual machine (VM), oracle, wallet interface, applets, authentication site, cybersecurity controller, service applications, and the like) described herein may be configured using any programming language known in the art, including any high-level, object-oriented programming (OOP) language, such as Python or Solidity. The computer-implemented system may include instances of processes that enable execution of transactions and recordation of transactions. It should be understood that the terms “transaction” and “exchange” are herein used interchangeably, when used within a context of digitally transferring items of value, such as digital assets (e.g., digital asset120(FIG.1)), collateral assets, and/or collateral tokens, among entities associated with a blockchain network, e.g., blockchain network105-1(FIG.1). The computer-implemented system100may also include instances of encoders/decoders, which can be implemented by, e.g., a server560or a client that communicates with the server560, using, for example, secure sockets layer (SSL), Hypertext Transfer Protocol Secure (HTTPS), or any other suitable protocol known to those of skill in the art.

In an example mobile implementation, a mobile agent implementation of embodiments may be provided. A client-server environment may be used to enable mobile services using a network server, e.g., server560. It may use, for example, the Extensible Messaging and Presence Protocol (XMPP) protocol, or any other suitable protocol known to those of skill in the art, to tether an engine/agent615on a user device550to a server560. The server560may then issue commands to the user device on request. The mobile user interface framework to access certain components of computer-implemented system100(FIG.1) may be based on, e.g., XHP, Javalin, and/or Wireless Universal Resource FiLe (WURFL), or other suitable known framework(s), interface(s), or combinations thereof. In another example mobile implementation for the iOS operating system (OS) and its corresponding application programming interface (API), the Cocoa Touch API may be used to implement the client-side components615using Objective-C or any other suitable known high-level OOP language that adds Smalltalk-style messaging to the C programming language.

Disk storage617may provide non-volatile storage for computer software instructions615(equivalently “OS program”) and data616may be used to implement embodiments of system100. The system may include disk storage accessible to a server computer560. The server computer may maintain secure access to records associated with system100. Central processing unit (CPU)612may also be attached to system bus610and provide for execution of computer instructions. In one example embodiment, the CPU612is a secure cryptoprocessor implemented as a dedicated microprocessor configured to execute the cross-chain clearinghouse control system. The cryptoprocessor may be specialized to execute cryptographic algorithms within hardware to support the cross-chain clearinghouse control system. Functions include such things as accelerating encryption algorithms that verify compliance of encoded rules related to an NFT asset, enhanced tamper, and intrusion detection, enhanced data, key protection and security enhanced memory access and I/O to facilitate transactions across multiple blockchain systems.

In some embodiments, processor routines615and data616may be computer program products. For example, aspects of system100may include both server-side and client-side components.

In other embodiments, authenticators/attesters may be contacted via, e.g., blockchain gaming systems, instant messaging applications, video conferencing systems, VoIP (voice over IP) systems, etc., all of which may be implemented, at least in part, in software615,616. Further, in yet other embodiments, client-side components interfacing with system100may be implemented as an application programming interface (API), executable software component, or integrated component of the OS configured to provide access to an electronic wallet on a Trusted Platform Module (TPM) executing on a client device550.

In one embodiment, the cross-chain clearinghouse control system is implemented as an embedded virtual machine, preferably executing on one or more cryptoprocessors configured to support efficient and scalable processing of application-to-blockchain and blockchain-to-blockchain transactions. The cryptoprocessor may be a dedicated computer-on-a-chip or microprocessor for carrying out cryptographic transaction operations, embedded in a hardware security module with security measures providing failsafe tamper resistance. The embedded cryptographic processor can be configured to output decrypted data onto a bus in a secure environment, in that embedded cryptoprocessor does not output decrypted data or decrypted program instructions in an environment where security cannot be maintained. The embedded cryptoprocessor does not reveal keys or executable instructions on a bus, except in encrypted form, and zeros keys by attempts at probing or scanning.

In an embodiment, software implementations615,616may be implemented as a computer-readable medium capable of being stored on a storage device617, which provides at least a portion of the software instructions for system100. Executing instances of respective software components of system100, such as instances of system100, may be implemented as computer program products615, and may be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the system software instructions615may be downloaded over a wired and/or wireless connection via, for example, a browser SSL session or through an app (whether executed from a mobile or other computing device). In other embodiments, system100software components615may be implemented as a computer program propagated signal product embodied on a propagated signal on a propagation medium (e.g., a radio wave, an infrared wave, a laser wave, a sound wave, or an electrical wave propagated over a global network such as the Internet, or other network(s) known in the art).

In one embodiment, the cross-chain clearinghouse control system is implemented as an embedded virtual machine, preferably executing on one or more cryptoprocessors configured to support efficient and scalable processing of application-to-blockchain and blockchain-to-blockchain transactions. The cryptoprocessor may be a dedicated computer-on-a-chip or microprocessor for carrying out cryptographic transaction operations, embedded in a hardware security module (HSM) with security measures providing failsafe tamper resistance. The embedded cryptographic processor can be configured to output decrypted data onto a bus in a secure environment, in that embedded cryptoprocessor does not output decrypted data or decrypted program instructions in an environment where security cannot be maintained. The embedded cryptoprocessor does not reveal keys or executable instructions on a bus, except in encrypted form, and zeros keys by attempts at probing or scanning.

An example embodiment includes device code executed in a TEE or TPM. A TEE or TPM is a hardware environment that runs instructions and stores data outside a main operating system (OS) of a device. This protects sensitive code and data from malware or snooping with purpose-built hardware governed by an ecosystem of endorsements, beginning with a device manufacturer. The system may perform checks on the TEE or TPM, such as executing BIOS (Basic Input/Output System) checks, to verify that folders (e.g., wallets, such as digital wallet115(FIG.1)) stored in the TEE/TPM have not been altered by malicious actors.

FIG.7Ais a simplified block diagram showing an example device authentication system700with components upon which system100(FIG.1) may operate according to an embodiment. With these system components700, network nodes may make use of hardened encryption and the cryptographic key in endpoint user devices705through an API704ato a cross-chain clearinghouse control system. The user devices705may provide processing, storage, and input/output devices executing application programs and the like. In addition, further services may be provided built on these system components700for device management, backup, attestation, etc. To support system100, the registration of identity cryptographic keys and a set of device management services for attestation, backup, and device grouping, are managed. The system components700, e.g., cryptographic key wallet714, may also interface with applet709.

It would be the intent of system700not to maintain mission critical data as in conventional approaches, but rather to provide a platform for seamless, yet secure, connections between cross-chain clearinghouse control system704and user devices705. On one end of the system is the VM oracle710that prepares an instruction for a user device705and at the other is system700which is applet707that can act on that instruction. A protocol may define how these instructions and replies are constructed.

According to an embodiment, system700may illustrate binding between the digital asset and multiple parties/devices. The system700may lock features of identity, transaction and attestation to the hardware of respective user devices705.

In an embodiment, system700, shown inFIG.7B, may use a secure socket, e.g., SSL or HTTPS, to maintain a persistent connection with devices. This channel is used for pairing and other administrative functions. VM oracle710may be provided to/utilized on blockchain networks for simplifying the encoding of a transaction. This VM oracle710, for example, could be implemented in a programming language, such as a high-level, OOP language with dynamic semantics like Python.

A TEE may be implemented in a user device hardware security chip separate execution environment that runs alongside the rich operating system, and provides security services to that rich environment. The cryptographic keys and/or digital assets, collateral assets, or collateral tokens may be stored in the TEE. The TEE offers an execution space that provides a higher level of security than a rich OS. The TEE may be implemented as a virtual machine (VM), on the user devices, or on the network nodes.

The ring manager712can be implemented as a service provided to end-users for managing rings (or clusters) of user devices705. User devices705may be grouped into a single identity and used to backup and endorse each other. Rings may be associated with other rings to create a network of devices. The rings may be a collection of individual device public keys (as opposed to a new key). If there are not many shared devices in the network, the list of devices may be short because of the potential for increased computational and bandwidth resources that may expended, and may introduce a time cost for encrypting a transaction with all cryptographic keys on a device list.

In an example embodiment, the device TEE708is a software program that executes in a hardware secured TEE. The device TEE708is specially designed to execute cryptographic functions without compromise from malware or even the device operator. OEM (Original Equipment Manufacturer)723is the entity that built the user device and/or a Trusted Application Manager (TAM) authorized to cryptographically vouch for the provenance of the device.

In an embodiment, when the electronic wallet720shown inFIG.7Cruns for the first time to process an NFT, it will ask the device TEE708to generate the cryptographic key. Each digital asset is signed by the node that deposits the asset into a locker with their signature and is thereby locked. For a node to then interact with the asset on the network on which it is locked, the node must unlock the asset with a cryptographic signature. Registration may involve confirmation from the device operator. The registrar may ask the device for a Device Measurement Record which includes one or more of the following: a composite value of the Platform Configuration Registers (PCRs) generated by the boot process, BIOS version, OS version, GPS (Global Positioning System) location, among other examples. This data may be signed by the cryptographic key. It may be further signed by the registrar. The resulting data set may become the gold reference or reference value for future integrity checks. Confirmation from the device operator may be required in collecting the gold reference or reference value. This data set may be posted into a public cryptographic ledger. The public record may establish cryptographic proof of the time of registration along with the endorsement of the registrar. The registration may further include attribute data, such as location or company name or device make/model. The registration may reference a signed document that sets out the policy terms of the registrar at the time of registration. The cryptographic key registrar721, or another trusted integrity server, may create a blockchain account key (a public/private key pair) that can be referenced as a signatory in a multi-signature transaction on the blockchain. A signatory may indicate that the value represented in the blockchain transaction cannot be spent or transferred unless co-signed by the registrar.

The blockchain(s)/sidechain(s)7061-nmay be a JSON (JavaScript Object Notation) API written in Python, which uses the third-party agent/process private key to enroll the identity cryptographic keys of devices705and system700. During enrollment, the public key of the user device705or system700is recorded by the TEE applet708. Enrollment enables the TEE applet708to pair a device705with cross-chain clearinghouse control system704. In one embodiment, the result of pairing is that a user device705has a service public key, endorsed by a third-party agent/process and can therefore respond to cross-chain clearinghouse control system704instructions.

In an embodiment, the cryptographic key wallet714ofFIG.7Bmay be composed of outward and inward-looking interfaces as shown inFIG.7D. The inward-looking interface, the TEE adapter716, handles proprietary communications with system700. The host adaptor717is provided to expose services to third-party applications. The host adaptor717may present the interface of the cryptographic key wallet714through different local contexts, such as browsers or system services. Multiple realizations for diverse contexts are anticipated. The socket adaptor715may connect the client environment blockchain(s)/sidechain(s)7061-n. The TEE adaptor716may be the glue that pipes commands into system700. The cryptographic key wallet714may prepare message buffers that are piped to system700, and then synchronously awaits notification of a response event. The host adaptor717may isolate the TEE adapter716from the host environment. The host adaptor717, in an embodiment, may operate in a potentially hostile environment. The host adaptor717's role may be to facilitate easy access to the system700. Instructions from a cross-chain clearinghouse control system704intended for system700may be signed by cross-chain clearinghouse control system704and then passed through to the TEE adapter716and system700.

The blockchain(s)/sidechain(s)7061-nmay have a special capability of being able to pair additional instances of cross-chain clearinghouse control systems with device705. Communications with the first blockchain(s)/sidechain(s)7061-nmay be handled through the web API and preferably are authenticated. In one example, this is implemented with an API key. This may be implemented using an SSL key swap. In some embodiments, all requests are signed.

The system700provides robust security. The digital locker may be used to make it more difficult for an attacker to access the digital asset in the digital asset locker, as, if the attacker does not possess a valid cryptographic key, access to the locker will not be validated. Furthermore, system700may preferably be in near constant contact with all devices705through the socket adapter715shown inFIG.7C.

In an embodiment, blockchain(s)/sidechain(s)7061-nmay comprise several sub-components. For example, each block on the blockchain(s)/sidechain(s)7061-nmay contain hashes, a height, nonce value, confirmations, and/or a Merkle Root, among other examples.

In an embodiment, a sequence of packaging and delivering an instruction is shown inFIG.8A. The cross-chain clearinghouse control system704may generate an instruction record with the help of the VM oracle710libraries. The instruction may include the type, the target device, and payload. The instruction may be encoded with one or more cryptographic keys. The cryptographic key is fetched from the blockchain(s)/sidechain(s)7061-n, by looking up the device registration record.

In an embodiment, device enrollment may be performed. An example enrollment process, shown inFIG.8B, should be hassle free, or even transparent to the user. This embodiment may ensure that system700is operating in a proper TEE.

FIG.9shows an example of a user identification system900according to an embodiment. A user915interacts via user input920with a website displayed via a web browser910running on computing device905, such as clicking an advertisement on the displayed website. The interaction is communicated to server (token server)935. For example, a transparent pixel or script may be placed on the displayed website to communicate the interaction to the server935.

An application executing on the server935determines whether the user915is a software robot or a person user by issuing a request925to web browser910to produce a token. The request925is sent over a network245. In response to request925, web browser910produces a token930on computing device905. The token930is sent to the server935over network945. The application executing on server935determines (e.g., using a computational challenge) a computational cost of producing the token930. In some embodiments, the computational cost of producing the token930is based on the time taken to produce the token930. Based on the computational cost of producing the token930, the application on server935determines (deciphers) whether the user915is a software robot or a person user. In some embodiments, proving the computational cost of producing the token930at the computing device905is performed by an independent third party, rather than the application executing on server935.

An application that determines whether the user915is software robot or a person user may also exist locally on the computing device905. In this embodiment, it would not be necessary to send request925or token930over a network945.

In some embodiments, the request925is issued in response to particular user engagement in the web browser910and based on user engagement metrics, including mouse movements by the user. The request925can also be issued in response to an elapsed period of time or issued by a web service.

In some embodiments the application on server935ofFIG.9calculates a confidence score and metrics associated with whether the user915operating computing device905is at least in part by a software robot or a person user. Once the application on server935determines whether user915is a software robot or a person user, the application on server935returns the identity of the user940and a calculated confidence score, which is associated with a likelihood of whether computing device905is being operated by a software robot or a person user. Thus, the calculated confidence score indicates a confidence value regarding the user identification. The confidence score helps the relying party determine a measure of confidence about the identity of the user940.

The confidence score can be based on many different factors. One factor is the computational cost of the produced token930. If the proven computation cost is low (below a threshold value), the confidence score may be increased. Further, if computing device905is a server, the computational cost is higher than if the computing device905is an individual machine, and thus the confidence score may be increased. The confidence score may be based on the time it took computing device905to produce the token930. For example, longer times (e.g., above a time threshold) for producing token930may be associated with a higher likelihood that the identity of the user940is a software robot and a lower likelihood that the identity of the user940is a person user. In another embodiment, the confidence score is increased if the computing device905includes a TPM (Trusted Platform Module).

According to some embodiments, produced token930is captured in a cookie. In an embodiment, the captured produced token and the computational cost of the captured produced token930are time sensitive and expire after a period of time. Captured cookies can sign cookies generated in the future thus, building up proof of whether the web browser910running on computing device905is being operated by a person user or a bot. The building up of proof results in a longer block chain, making it increasingly difficult for a web browser running on a machine that is operated by a bot to continue to produce tokens.

In some embodiments, the confidence score may be calculated to further consider the confirmed purchase activities of the user. The score may increase when determined that a user is a verified purchaser who previously completed an online purchase. The proof of a user being an online purchaser, such as a retrieved proof of purchase cookie associating the user's identity to an entry in a database of confirmed purchases may increase the confidence score. For example, a retrieved proof of purchase cookie associating the user's identity particularly to a persistent entry in a block chain database of confirmed purchases may further increase the confidence score. That is, the trusted confirmation of the user as a verified purchaser may be associated with a higher likelihood (confidence) that the identity of the user is a person (rather than a software robot).

Further example embodiments disclosed herein may be configured using a computer program product; for example, controls may be programmed in software for implementing example embodiments. Further example embodiments may include a non-transitory computer-readable medium containing instructions that may be executed by a processor which, when loaded and executed, cause the processor to complete methods described herein. It should be understood that elements of the block and flow diagrams may be implemented in software or hardware, such as via one or more arrangements of circuitry ofFIG.6, disclosed above, or equivalents thereof, firmware, a combination thereof, or other similar implementation determined in the future. In addition, the elements of the block and flow diagrams described herein may be combined or divided in any manner in software, hardware, or firmware. If implemented in software, the software may be written in any language that can support the example embodiments disclosed herein. The software may be stored in any form of computer-readable medium, such as random-access memory (RAM), read-only memory (ROM), compact disk read-only memory (CD-ROM), and so forth. In operation, a general-purpose or application-specific processor or processing core loads and executes software in a manner well understood in the art. It should be understood further that the block and flow diagrams may include more or fewer elements, be arranged or oriented differently, or be represented differently. It should be understood that implementation may dictate the block, flow, and/or network diagrams and the number of block and flow diagrams illustrating the execution of embodiments disclosed herein.

It should be understood that the term “blockchain” as used herein includes all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers and variations thereof. While Bitcoin and Ethereum may be referred to herein for the purpose of convenience and illustration, it should be noted that the disclosure is not limited to use with the Bitcoin or Ethereum blockchains and alternative blockchain implementations and protocols fall within the scope of the present disclosure.

It should also be noted that not all currently known distributed ledger systems utilize linear blockchains as such. Some known blockchain implementations utilize lattice or mesh data structure(s), and some utilize directed acyclic graphs (DAGs).