Patent Description:
The present disclosure generally relates to networks, data structures, distributed ledger technologies, blockchain, and smart contracts and, in particular, to systems and methods for building blockchains for verifying assets for smart contracts.

Blockchain technology is a ledger that is distributed to members of a computer network. The ledger records accounting and other information about electronic transactions. When the blockchain is public, anyone can read it. The blockchain is immutable, meaning that no one can change the record of what happened in the past. Blockchain technology includes a consensus process to ensure that all the copies of the ledger on the network are the same. Conventional implementations of the consensus process may be expensive and wasteful in terms of computing resources such as power, time, and storage. In addition, conventional implementations may not achieve speeds or accessibility to be widely adopted.

Blockchain technology is not widely trusted for electronic transactions. Blockchain relies on trust in members of a computer network, who may be unknown. When people know each other in a community, trustworthy behavior is promoted by reputations. The lack of reputation information undermines trust. Blockchain transactions sometimes remove middlemen such as financial institutions. Regulators of financial institutions can promote trustworthy behavior through the threat of imposing sanctions or legal action. Without this threat, there is a greater risk of theft and fraud.

Blockchain technology relies on trusting the security of cryptography, protocols, software, and computer networks. Failures in computer and internet security systems erodes trust.

Blockchain technology does not provide a way to represent details about real world items and verify the authenticity of real world items that may be the subject of transactions or smart contracts. The inability to determine whether an item is real or fake erodes trust.

<CIT> describes systems and techniques for blockchain-based reputation tracking in an online marketplace.

<CIT> describes a transaction and consensus combined intelligent service transaction blockchain reputation management method and system.

<CIT> describes a blockchain consensus method based on reputation proof.

<CIT> describes a method of executing a digital smart contract which includes receiving a stake of predetermined value from an oracle.

Accordingly, there are significant, and competing, needs in the fields of networks, data structures, distributed ledger technologies, blockchain, and smart contracts. There is a need for less expensive and less wasteful consensus processes. There is a need for generally promoting trustworthy behavior and preventing theft, fraud, and counterfeiting.

The disclosed subject matter is directed to systems and methods for building blockchains for verifying assets for smart contracts that satisfy these needs.

According to a first aspect of the present disclosure there is provided a system including a memory, a blockchain, a set of nodes, a set of verifiers, a set of miners, and a consensus protocol. The memory having a block data structure representing a transaction for an asset having an identifier and at least one verifiable characteristic. The blockchain in the memory links one or more blocks having the block data structure. The set of nodes are in data communication in a peer-to-peer network. Each node is capable of receiving a distributed copy of the blockchain. At least one of the nodes includes the memory. The set of verifiers are members of the set of nodes. Each verifier holds a stake at risk. Each verifier receives a reputational score. Each verifier has a private key. Each verifier is capable of verifying the verifiable characteristic of the asset and signing a new block with the private key. A set of miners can be members of the set of nodes. Each miner is capable of cryptographically verifying the new block using a public key in return for a reward and adding the new block to the blockchain. The consensus protocol is in memory and include rules for: receiving the stake at risk from the verifiers, providing the reputational score to the verifiers, verifying the verifiable characteristic of the asset by the verifiers, cryptographic verification by the miners, adding the new block to the blockchain by the miners, providing the reward to the miners, and distributing the copy of the blockchain to each node.

The system can further include a smart contract for the asset in the blockchain, where the blockchain includes the new block that verifies the at least one verifiable characteristic of the asset. The smart contract can be for the digital sale of the asset. The stake at risk can be in cryptocurrency. The reward can be in cryptocurrency. The verifiers can pay a verification fee. The verifiers can receive a verification reward. The stake at risk can vary for different verifiers and the verification reward can vary depending on the stake at risk by the verifier. The consensus protocol can further include rules for refreshing the at least one verifiable characteristic of the asset after an event. The consensus protocol can further include rules for refreshing the at least one verifiable characteristic of the asset after a period of time. The system can further include a smart contract for receiving the stake at risk from the verifiers and providing the reward to the miners. The system can further include a secure key issuer for issuing the public keys and the private keys.

According to a second aspect of the present disclosure there is provided a method. A private key and a public key are issued to each of a set of nodes in a network. A stake at risk from a node that is a verifier is received. A node that is a miner distributes a blockchain to the network. The blockchain has a new block representing a transaction for an asset having an identifier and a verifiable characteristic. The verifiable characteristic is verified and signed with the private key by the verifier and the new block is cryptographically verified by the miner using the public key. A reward is provided to the miner. A reputational score is provided to the verifier. A verification fee can be received from the verifier. A verification reward can be provided to the verifier.

A smart contract can be provided for sale of the asset. The asset can be provided for sale. Upon an event, verification of the asset can be requested. Upon expiration of a time period, verification of the asset can be requested.

According to a third aspect of the present disclosure there is provided a non-transitory computer-accessible medium having stored thereon computer-executable instructions for building blockchains for verifying assets for smart contracts, wherein upon execution by a computer arrangement comprising a processor, the instructions cause the computer arrangement to perform procedures. A block interface is provided that provides a block data structure representing a transaction for an asset having an identifier and at least one verifiable characteristic. A host interface is provided that can be configured to host a set of nodes in data communication in a peer-to-peer network. A key issuer interface that is configured to issue private and public keys to each of the nodes. An ante up interface is configured to receive a stake at risk in cryptocurrency from one of the nodes. A reputational score interface is configured to assign a reputational score to one of the nodes. A verifier interface is configured to verify the verifiable characteristic of the asset and sign a new block with the private key and receive a verification reward in cryptocurrency. A miner interface is configured to cryptographically verify the new block using a public key in return for a reward in cryptocurrency and add the new block to a blockchain. An update blockchain interface is configured to link one or more blocks having the block data structure into the blockchain. A distribute blockchain interface is configured to distribute the blockchain to each node. A smart contract interface is configured to manage a digital sale of the asset.

These and other features, aspects and advantages of the disclosed subject matter are explained in greater detail with reference to specific example embodiments that are illustrated in the following description, appended claims, and accompanying drawings.

The following description of embodiments provides non-limiting representative examples referencing numerals to particularly describe features and teachings of different aspects of the invention. The embodiments described should be recognized as capable of implementation separately, or in combination, with other embodiments from the description of the embodiments. A person of ordinary skill in the art reviewing the description of embodiments should be able to learn and understand the different described aspects of the invention. The description of embodiments should facilitate understanding of the invention to such an extent that other implementations, not specifically covered but within the knowledge of a person of skill in the art having read the description of embodiments, would be understood to be consistent with an application of the invention.

<FIG> is a diagram of a system <NUM> according to an example embodiment of the disclosure. System <NUM> can include a network-enabled computer having a memory <NUM> that holds a blockchain <NUM>. The memory can have a block <NUM> data structure representing a transaction <NUM> for an asset having an identifier <NUM> and one or more verifiable asset characteristics <NUM>. Blockchain <NUM> can be in memory <NUM> and link one or more blocks <NUM> having the block data structure. As shown in <FIG>, the block data structure may comprise one or more transactions <NUM>, each of which may include an asset identifier <NUM>, one or more asset characteristics <NUM>, and other data.

Blockchain <NUM> can manage transactions <NUM> involving digital or real world assets without the need for an intermediary such as a bank or credit card processor. A digital asset may be any image, multimedia, textual or other content that can be stored electronically and includes the right to use it. A cryptocurrency may be a digit asset that works as a medium of exchange to secure financial transactions, control the creation of additional units and verify the transfer of assets such as Bitcoin® or Ethereum®. A real world asset may be any item of value, such as real estate, real property, or personal property. Assets may include tangible items such as appliances, jewelry, sneakers, art, and cars. Assets may include intangible items such as bank accounts, stocks, bonds, right to a benefit, options, and shares. Blockchain <NUM> may include tokenized assets. A tokenized asset is any tangible or intangible property such as real or chattel property or a legal interest in an asset that is represented by a token on blockchain <NUM>.

Transaction <NUM> may reflect the state of the asset associated with blockchain <NUM>, an event associated with the asset, or any other data related to the asset. For example, transaction <NUM> may be a request for a home mortgage verification from a banker, a description of a designer purse for sale in an auction, or a notice that a car needs an emissions inspection by a certain date. Transaction <NUM> may be an ownership record such as a stock certificate, an operating agreement for a business, or a recorded lien on real estate. Transaction <NUM> may be a data store for property, digital content distribution, a stop in a supply chain, votes for a candidate, patient medical records, chain of title deed recording records, or some part of data related to applications of blockchain technology. Transaction <NUM> may be a payment exchanged for a good and/or service such as the purchased item, price, merchant name, and customer payment information. Transaction <NUM> may be a placeholder, pre-approval, or evaluation of an asset before a transaction occurs. For example, transaction <NUM> may be an itemized list of verifications of data associated with the sale of a residential home and an indication of whether everything has been verified or further verifications are needed. For example, transaction <NUM> may be an entry from a smart contract related to the asset or the processing of the asset on the blockchain according to consensus processes.

Blockchain <NUM> can be used to manage transactions <NUM>. To do so, blockchain <NUM> may employ methods to store and access transactions, consensus methods to approve and record transactions, cryptographic methods to authenticate parties to the transactions, methods to store and pay with currency, and methods to enforce a condition or automate a process with smart contracts. Blockchain <NUM> can be a data structure in a linked list of blocks <NUM> connected back to one another by hashed links. Each block <NUM> can contain hashes of transactions <NUM>. Any method may be used for hashing transactions <NUM>, including without limitation the Merkle Tree method. Blockchain <NUM> can be publicly accessible or private (viewable only to known entities or members of a group or network).

Each block <NUM> can include a number of transactions <NUM>. Each transaction <NUM> may be validated before being added to block <NUM> and blocks <NUM> may not be altered or deleted from blockchain <NUM>. Each transaction <NUM> is visible to members of the network because blockchain <NUM> is distributed to each member of the network.

Each transaction <NUM> can include an asset identifier <NUM> and one or more asset characteristics <NUM>. Asset identifier <NUM> may be any kind of identifier suitable for the asset, such as a serial number, an RFID tag, an inventory tracking number, an identification code, a real estate plot number, or a vehicle identification number. Asset characteristics <NUM> may be any kind of verifiable characteristic suitable for the asset or transactions involving the asset. Before each block <NUM> is added to blockchain <NUM>, the asset characteristics <NUM> can be verified by a verifier suitable to the asset.

For example, if the asset is a residential home, asset characteristics <NUM> can include the address, date the home was built, square feet, address, liens, additions, mortgage information and the like. For the residential home, verifiers can include realtors, mortgage brokers, home owners, and so on. For example, if the asset is a diamond ring, asset characteristics <NUM> can include weight, color, clarity, shape, carat, setting, style and the like. For the diamond ring, verifiers can include an expert jeweler, registered jeweler, certified gemologist, certified appraiser, and so on. For example, if the asset is sneakers, asset characteristics <NUM> can include color, size, brand, style, and the like. For the sneakers, verifiers can include streetwear experts, retail organization investigators, retailers, and so on. For example, if the asset is art, asset characteristics <NUM> can include artist, date, category, medium, origin, provenance, stylistic period, subject matter or theme, price, and the like. For art, verifiers can include forensic art investigators, conservation scientists, conservators, dealers, museums, auction houses, collectors, art experts, authentication boards, art historians, and so on. If the asset is a handbag, asset characteristics <NUM> can include brand, condition, description, cost, location, features, fabric, stitching, labels, designer logo, styling, and the like. For handbags, verifiers can include retailers, designers, authenticators, certifiers, brand experts, and so on. If the asset is a used car, asset characteristics <NUM> can include mileage, drive type, engine, transmission, fuel type, miles per gallon (mpg), exterior, interior, stock number, vehicle identification number (VIN), price, location, repair history, and the like. For cars, verifiers can include inspectors, dealers, repair shops, certified mechanics, and so on.

As referred to herein, a network-enabled computer may include, but is not limited to a computer device, or communications device including, e.g., a server, a network appliance, a personal computer, a workstation, a phone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, a mobile device, or other device. For example, a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and/or any other smartphone, tablet, or like wearable mobile device.

A network-enabled computer can include a processor and a memory, and it is understood that the processing circuitry may contain additional components, including processors, memories, error and parity/CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives and tamper-proofing hardware, as necessary to perform the functions described herein.

A network-enabled computer can include a display and input devices. The display can be any type of device for presenting visual information such as a computer monitor, a flat panel display, and a mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. The input devices can include any device for entering information into the user's device that is available and supported by the user's device, such as a touch-screen, keyboard, mouse, cursor-control device, touch-screen, microphone, digital camera, video recorder or camcorder. These devices can be used to enter information and interact with the software and other devices described herein. In some examples, the network-enabled computer can execute one or more applications, such as software applications, that enable, for example, network communications with one or more components of the system and transmit and/or receive data.

A network-enabled computer can be a client device in communication with one or more servers via one or more networks, and can operate as a respective front-end to back-end pair with the server. A client device can transmit, for example from a mobile device application executing on the client device, one or more requests to the server. The one or more requests can be associated with retrieving data from the server. The server can receive the one or more requests from the client device. Based on the one or more requests from the client device, the server can be configured to retrieve the requested data from one or more databases. Based on receipt of the requested data from the one or more databases, the server can be configured to transmit the received data to the client device. For example, the received data can be responsive to one or more requests.

The network can be one or more of a wireless network, a wired network or any combination of wireless network and wired network, and can be configured to connect the client device to the server. For example, the network can include one or more of a fiber optics network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a Global System for Mobile Communication, a Personal Communication Service, a Personal Area Network, Wireless Application Protocol, Multimedia Messaging Service, Enhanced Messaging Service, Short Message Service, Time Division Multiplexing based systems, Code Division Multiple Access based systems, D-AMPS, Wi-Fi, Fixed Wireless Data, IEEE <NUM>. 11b, <NUM>. <NUM>, <NUM>. 11n and <NUM>, Bluetooth, NFC, Radio Frequency Identification (RFID), Wi-Fi, and/or the like.

The network can include, without limitation, telephone lines, fiber optics, IEEE Ethernet <NUM>, a wide area network, a wireless personal area network, a LAN, or a global network such as the Internet. The network can support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. The network can further include one network, or any number of the exemplary types of networks mentioned above, operating as a stand-alone network or in cooperation with each other. The network can utilize one or more protocols of one or more network elements to which they are communicatively coupled. The network can translate to or from other protocols to one or more protocols of network devices. Although the network is depicted as a single network, it should be appreciated that according to one or more examples, the network can comprise any number of interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, corporate networks, such as credit card association networks, and home networks.

<FIG> is a diagram of a system <NUM> for building blockchains <NUM> for verifying assets for smart contracts, according to an example embodiment of the disclosure. System <NUM> includes a set of nodes <NUM>, such as node <NUM>, node <NUM>. Nodes <NUM> can be in data communication in a peer-to-peer network or other kind of network. The peer-to-peer network may be any number of network-enabled computers or nodes that are connected and share resources without a central server computer so that each computer may act as both a client and server. Each node <NUM> is capable of receiving a distributed copy of blockchain <NUM> and storing it in memory <NUM>. Nodes <NUM> may be anonymous or identify participants.

System <NUM> may be part of a blockchain technology stack having layers or components such as shared data, protocols, platforms, products, applications, and smart contracts. Shared data may be the decentralized database or distributed ledger technology that stores all the transactions in hashed format. Protocols may include TCP/IP, SMTP, HTTP, HTTPS, Bitcoin, Ethereum, ERC-<NUM>, and others. Protocols may implement rules for consensus, validation, incentives, and participation in system <NUM>. Platforms may be any kind of middleware that allows developers to build applications on top of the protocol layer such as Ethereum, NEO, and EOS. Products may provide an interface to protocols and platforms and allow users to interact with shared data. Developers may use platforms to build products such as decentralized applications and smart contracts. Smart contracts may be capable of self-executing conditions and terms of an agreement between parties including writing the resulting transactions into the blockchain. Applications may include trade finance, payments, mortgages, letters of credit, asset registration, citizen identity, medical records, medicine supply chain, retail supply chain, loyalty programs, insurance claims processing, risk provenance, asset usage history, claims files, manufacturing supply chain, product parts, maintenance tracking, and others.

A consensus process may be used to update, maintain and distribute blockchain <NUM> to nodes <NUM>. Because peer-to-peer networks have no central server or administrator, the members of the network, nodes <NUM>, need to reach consensus on the state of the distributed ledger, blockchain <NUM>. The state of blockchain <NUM> includes validation of the uniqueness and order of accounting records. Nodes <NUM> can reach consensus on the state of blockchain <NUM> through consensus methods. Some consensus methods are: Proof of Work, Proof of Stake, Proof of Burn, Proof of Activity, Proof of Elapsed Time, and Simplified Byzantine Fault Tolerance.

Blockchain <NUM> can include ledgers, transactions, and contracts. Ledgers can log transactions and describe the inputs and outputs of a business. Transactions can be an asset transfer between nodes <NUM>. Contracts can describe the conditions for a transaction to occur. Blockchain <NUM> can provide cryptographic proof that transactions occurred. Blockchain <NUM> can involve assets and/or cryptocurrency. The nodes <NUM> in system <NUM> share a replicated blockchain <NUM>.

System <NUM> can be part of networks such as customers, suppliers, banks, businesses, regulators, industry groups, and other organizations and members. System <NUM> can include the flow of goods and services in transactions and contracts across networks in various regions and countries and include public and private markets. System <NUM> can add or remove nodes <NUM> and some nodes <NUM> can be verifiers (<FIG>) and/or miners (<FIG>) according to consensus processes and protocols for blockchain <NUM>.

<FIG> is a diagram of a system <NUM> for building blockchains <NUM> for verifying assets for smart contracts, according to an example embodiment of the disclosure. System <NUM> includes a set of one or more verifiers <NUM>, such as verifier <NUM>, verifier <NUM>. verifier n, which are computers connected in a network. Verifiers <NUM> can be members of the set of nodes in <FIG>. Each verifier <NUM> with the set of one or more verifiers can hold a stake at risk <NUM> in memory <NUM>. Each verifier <NUM> can receive a reputational score <NUM>. Each verifier <NUM> has a private key <NUM>. Each verifier <NUM> is capable of verifying the verifiable characteristic <NUM> of the asset in a transaction <NUM> in an old block <NUM> and signing a new block <NUM> with the private key <NUM> for the blockchain <NUM>. For example, old block <NUM> may be information about the original owner of a used car and transaction <NUM> may include the title to the car, asset ID <NUM> may be the VIN number, and asset characteristics <NUM> may include information about maintenance records and car loans. Verifiers <NUM> may include the original owner of the used car, an agent at a car dealership, an auto repair shop mechanic, an official from the department of motor vehicles, and a loan officer at a bank.

One or more verifiers <NUM> can verify one or more asset characteristics <NUM> in transaction <NUM>. For example, if the asset is a residential home, a realtor can verify the square footage and address. For example, if the asset is a diamond ring, an appraiser can verify the color, clarity, and carat. For example, if the asset is sneakers, a retailer can verify the brand, style, and size. For example, if the asset is art, a conservator can verify the artist and provenance. As another example, if the asset is a handbag, a brand expert can verify the brand and designer logo. As another example, the asset is a used car, a certified mechanic can verify the mileage and condition.

Once asset characteristics <NUM> is verified, verifier <NUM> can encrypt and add new block <NUM> to blockchain <NUM>. Verifier <NUM> can sign new block <NUM> with their private key <NUM>. In this way, verifier <NUM> can attest to the authenticity of asset characteristics <NUM>. Other members of the network can use a public key to verify the identity of the signer on new block <NUM>. Public key or asymmetric cryptography can be used to secure the identity of the sender of transactions <NUM> and to prevent tampering with past records in blockchain <NUM>. Public key cryptography uses a combination of a sender's private key and a recipient's public key to encrypt a message. Public key cryptography uses a recipient's private key and sender's public key to decrypt the message. Public key cryptography can also produce a digital signature as a combination of a user's identity and the data in the message. Any kind of hash function can be used to represent the current state of blockchain <NUM>. New block <NUM> includes a new hash of the current state and includes the previous state of old block <NUM> so that changing any previous record would require all the hashes to be changed. This would be noticeable to other members of the network and not pass the consensus process for adding new block <NUM> to blockchain <NUM>. Blockchain <NUM> may be a linked list of blocks <NUM>, <NUM> connected back to one another by hashed links.

Each verifier <NUM> can hold a stake at risk <NUM> in memory <NUM>. Proof of stake may be a kind of consensus process where a member of the network can mine or approve transaction <NUM> based on the stake they hold. A stake may be an amount of cryptocurrency or anything of value held by a member of the network in a wallet or put up as collateral. For example, a member of the network who holds <NUM>% of the total amount held by all the members of the network can mine or approve <NUM>% of transactions <NUM>. Mining and approving may be a process of validating and recording transactions <NUM> on blockchain <NUM> using consensus processes and network protocols.

Blockchain <NUM> can be a distributed ledger that records transactions <NUM> across a nodes in a network of system <NUM>, where the nodes include some nodes that are verifiers <NUM> or miners. The nodes agree on the distributed ledger's contents using consensus processes. The proof of stake (PoS) concept is a more efficient alternative to the more wasteful proof of work (PoW) concept, which sometimes used in consensus processes. PoS offers nodes a monetary reward to update the blockchain <NUM> without imposing a cost upon nodes to gain the authority to update the blockchain. Blockchain <NUM> may possess a native token or coin that facilitates exchange on blockchain <NUM>. A stake-holder of blockchain <NUM> can be a node holding some coins of blockchain <NUM> in, for example, a digital wallet stored on the node. Under PoS, consensus processes grant authority to update blockchain <NUM> to stake-holders and may impose a cost upon stakeholders that update blockchain <NUM> in a manner that creates persistent disagreement. Generally, PoS can reach consensus for updating blockchain <NUM> in an efficient manner. The consensus processes may restrict access to updating blockchain <NUM> to sufficiently large stake-holders to induce an equilibrium quickly, because the cost of updating blockchain <NUM> in a manner with persistent disagreement increases with the stake at risk. For sufficiently large stake-holders, the cost of persistent disagreement outweighs the benefit from the monetary reward for updating blockchain <NUM>.

Consensus processes or protocols can be designed so that disagreement resolves eventually within any equilibrium, because indefinite disagreement nullifies the exchange value of the coins and thus renders those coins worthless. A stake-holder eventually recognizes that their stake value will erode to zero, so they ensure act in a way to reach consensus. There are various PoS mechanisms that can be used such as a Byzantine Fault Tolerant (BFT) PoS mechanism, a chain-based PoS mechanism like Ethereum, and so on. PoS can randomly select stake-holders to append new block <NUM> to blockchain <NUM>, according to consensus processes or protocols. The stake-holder can receive the option to append new block <NUM> to blockchain <NUM>, exercise that option, and collect a reward, according to consensus processes or protocols. If there is more than one branch of blockchain <NUM> competing for legitimacy, a consensus will be reached under the processes or protocol when an equilibrium is achieved and one branch wins under, for example, a longest chain rule where a stake-holder can append only to the longest branch whenever feasible. As blockchain <NUM> achieves consensus at the earliest possible time when stake-holders follow the longest chain rule, coin prices achieve a maximum in this case. Having a stake at risk and potential costs impel stake-holders to behave well and achieve consensus. Having an eligibility threshold for stake also encourages well-ordered behavior by stake-holders. A stake-holder with negligible stake may delay consensus by seeking block rewards. A stake-holder with a large stake may undermine their own wealth when postponing consensus even if such behavior yields block rewards. The stake-holders can be restricted to those with an ability to append new block <NUM> to blockchain <NUM> in line with the reward schedule. As the reward schedule becomes more modest, the restriction can become more lax.

Each verifier <NUM> can receive a reputational score <NUM>, which may reflect the trustworthiness of the verifier. All the members of the network can contribute to the reputational scores <NUM> of the other members of the network. For example, if verifier <NUM> verifies many asset characteristics <NUM> over time, then verifier <NUM> will tend to gain a good reputation. On the other hand, if verifier <NUM> makes mistakes or does questionable verifications of asset characteristics <NUM> over time, then verifier <NUM> may gain a bad reputation. Reputational scores <NUM> can be any indication of reputation such as one to five stars, a score on a numerical scale, a qualitative description (e.g., poor, fair, average, above average, superior), or any other way to compare reputations among members of the network.

Verifiers <NUM> can include regulators, governmental agencies, centralized authorities, corporations, small businesses, nongovernmental organizations, nonprofits, accountants, business people, banks, financial institutions, individuals, decentralized organizations, decentralized autonomous organizations, law enforcement, internet service providers, social media platform operators, search engines, and other participants in system <NUM>. It is understood that the verifiers <NUM> are not limited to a particular entity or type of entity.

<FIG> is a diagram of a system <NUM> for building blockchains <NUM> for verifying assets for smart contracts, according to an example embodiment of the disclosure. System <NUM> includes a set of one or more miners <NUM>, such as miner <NUM>, miner <NUM>. miner n, each of which are computers connected in a network. Miners <NUM> can be members of the set of nodes (<FIG>). Each miner <NUM> is capable of cryptographically verifying the new block <NUM> using a public key <NUM> in return for a reward and adding new block <NUM> to the blockchain <NUM> in memory <NUM>.

Miners <NUM> provide a service called mining that includes verifying and adding new blocks <NUM> to blockchain <NUM> in a decentralized fashion using consensus processes and network protocols. Before becoming a new block <NUM>, pending blocks can be stored in memory <NUM> and added to blockchain <NUM>, once they are verified by miner <NUM>. Miners <NUM> may validate new block <NUM> by, for example checking digital signatures and verifying information in new block <NUM> such as characteristics of assets. Mining can be rewarded with something of value such as cryptocurrency and miner <NUM> can store the reward in a digital wallet in memory <NUM>. The reward can be delivered by one node to the digital wallet of its own or another node, according to consensus processes and protocols and may involve a smart contract that automatically delivers a reward upon the fulfillment of certain conditions, such as reaching consensus on appending new block <NUM> to blockchain <NUM>.

System <NUM> may be a digital peer-to-peer ledger system designed to securely record transactions in and/or ownership of assets like a decentralized chain of title system. The assets may be, for example, cash or cash equivalents, financial instruments, inventory, cryptoassets, tangible property, intangible property or other assets. System <NUM> can avoid a double spend problem for assets by ensuring that the seller does not retain a copy of the asset or sell a counterfeit. Blockchain <NUM> can contain an unbroken audit trail for every transaction that has taken place on system <NUM>. Blockchain <NUM> can be public or private.

Miners <NUM> can maintain blockchain <NUM>. Each miner <NUM> or other participant in system <NUM> can maintain its own separate and complete copy of the entire blockchain <NUM> so that it is a distributed ledger. Miners <NUM> can validate new block <NUM> and update blockchain <NUM> to record new block <NUM>. The mining process creates trust and transparency within system <NUM>. Pending blocks on system <NUM> can be aggregated in memory <NUM>. Once validated by miner <NUM>, a pending block can be encrypted and added to blockchain <NUM> as new block <NUM>. A hash value can be assigned to new block <NUM> and reference the preceding block in blockchain <NUM>. If a block in blockchain <NUM> is altered, the hash number changes, which protects against fraud and enhances transparency. A copy of blockchain <NUM> is stored on each participant in system <NUM> and periodically synchronized so that each participant has the same blockchain <NUM> in memory <NUM>. To ensure that only legitimate new blocks <NUM> are recorded into blockchain <NUM>, miners <NUM> confirm that new block <NUM> is valid and do not invalidate former blocks. New block <NUM> is appended to the end of blockchain <NUM> only after system <NUM> reaches consensus as to the validity of new block <NUM>. Consensus may be achieved through various different mechanisms such as proof of work or proof of stake. After new block <NUM> is added to blockchain <NUM>, it can no longer be deleted and new block can be accessed and verified by everyone in system <NUM>. New block becomes a permanent record that system <NUM> can use to coordinate an action or verify an event. Blockchain <NUM> can be used to create a digital currency, a smart contract, communications and file sharing systems, decentralized domain name management systems, fraud-resistant digital voting platforms, internet-of-things communications, global payments, and other applications.

Each miner <NUM> can have public key <NUM> that is shared and private key that is secret. Miners <NUM> can share public key <NUM> in order to participate in system <NUM>. The private key can be used by miner <NUM> to access a virtual wallet, which can contain the digital assets held by miner <NUM> in system <NUM>. Miners <NUM> can act on their own behalf or on behalf of owners of the digital assets of system <NUM>. Any type of asset, tangible or intangible can be digitized and represented on blockchain <NUM>.

Miners <NUM> can include regulators, governmental agencies, centralized authorities, corporations, small businesses, nongovernmental organizations, nonprofits, accountants, business people, banks, financial institutions, everyday citizens, decentralized organizations, decentralized autonomous organizations, law enforcement, internet service providers, social media platform operators, search engines, and other participants in system <NUM>.

<FIG> is a diagram of a system <NUM> for building blockchains for verifying assets for smart contracts, according to an example embodiment of the disclosure. System <NUM> includes a consensus protocol <NUM>. Consensus protocol <NUM> can be in memory <NUM> and include rules for: receiving the stake at risk from the verifiers <NUM>, providing the reputational score to the verifiers <NUM>, verifying the verifiable characteristic of the asset by the verifiers <NUM>, cryptographic verification by the miners <NUM>, adding the new block to the blockchain by the miners <NUM>, providing the reward to the miners <NUM>, and distributing the copy of the blockchain to each node <NUM>. System <NUM> can further include a smart contract <NUM> for the asset in the blockchain, where the blockchain includes the new block that verifies the at least one verifiable characteristic of the asset.

System <NUM> can be a blockchain peer-to-peer network where nodes propagate information for blockchain replica synchronization. Nodes may have functionality for data communication, peer discovery, identity management, and topology maintenance. Nodes may have varying functionality as verifiers, miners or secure key issuers for issuing public and private keys. Nodes may be lightweight nodes, full nodes, or consensus nodes. Lightweight nodes such as wallets may issue transactions and have limited local storage and refer to other memory <NUM>. Full nodes may store a complete replica of the blockchain in memory <NUM>. Consensus nodes may enable the functionality of consensus participation with consensus protocol <NUM> and smart contract <NUM> in memory <NUM> and may publish new blocks on behalf of other nodes.

Consensus protocol <NUM> can be any set of rules for system <NUM> that organize how blockchains are built, assets are verified, and smart contracts <NUM> are used. Rules can impose threats to maintain order, offer rewards to incentivize good behavior, reward good actors, and punish bad actors, among other things. Rules can capture human input and reflect community values and norms. Rules can be automatically enforced through self-executing smart contracts <NUM>. Rules can add flexibility in a decentralized network for system <NUM>. Rules can be added, changed, or deleted according to rules in consensus protocol <NUM>. One or more nodes in a network for system <NUM> can include memory <NUM> containing consensus protocol <NUM> and consensus protocol <NUM> may be provided to other nodes in the network. Consensus protocol <NUM> may include any type of consensus algorithms such as Proof-of-Work, Proof-of-Stake, Delegated Proof-of-Stake, Leased Proof-Of-Stake, Proof of Elapsed Time, Practical Byzantine Fault Tolerance, Simplified Byzantine Fault Tolerance, Delegated Byzantine Fault Tolerance, Directed Acyclic Graphs, Proof-of-Activity, Proof-of-Importance, Proof-of-Capacity, Proof-of-Burn, Proof-of-Weight or others.

Consensus protocol <NUM> can include rules for receiving the stake at risk from the verifiers <NUM>. For example, a specific amount of coins stored in a wallet may be required for a node to be a verifier. For example, each verifier may need to submit collateral to a common pot such that some or all of the collateral may be lost under various conditions. For example, the portion of cryptocurrency in a verifier's wallet that are at stake may be locked. For example, a service or staking pool may stake coins on behalf of the verifier. For example, the amount of the stake at risk may depend on the role of the verifier in verifying the verifiable characteristic of the asset or the value of the asset, such as a gem expert who verifies the number of carats in a diamond ring or a retail brand expert who verifies the authenticity of a Louis Vuitton® bag. For example, a verifier may need to meet requirements for staking frequency or staking maturity.

Consensus protocol <NUM> can include rules for providing the reputational score to the verifiers <NUM>. For example, decentralized reputation tracking can provide transparency into the origin and history of transactions that created the reputation. For example, participants in system <NUM> can evaluate the services of verifiers depending on the role of the verifier in verifying the verifiable characteristic of the asset such as a builder, a realtor, an inspector, a plumber, and a home owner each verifying the condition of plumbing in a residential home. For example, incentives in smart contract <NUM> may reward or punish a verifier based on verifying data or events in the real world or on the blockchain. For example, a verifier's real world credentials can be verified and contribute to a reputational score and added to the blockchain. For example, the reputational score can be a token and can be staked. For example, the reputational score can be part of the blockchain for certain types of transactions or participants.

Consensus protocol <NUM> can include rules for verifying the verifiable characteristic of the asset by the verifiers <NUM>. For example, the rules can depend on the type of asset and the role of the verifier. For example, the lender of a mortgage may be required to verify the existence and terms of the mortgage for a commercial property. For example, a city inspector may be required to certify compliance with building permits and codes. For example, a property appraiser may be required to use three approaches for valuation: a sales comparison approach to value, a cost approach to value, and an income approach to value.

Consensus protocol <NUM> can include rules for cryptographic verification by the miners <NUM>, for adding the new block to the blockchain by the miners <NUM>, for providing the reward to the miners <NUM>, and for distributing the copy of the blockchain to each node <NUM>. Consensus protocol <NUM> can include incentive mechanisms, asymmetric encryption, homomorphic encryption, hash functions, Merkle Trees, cryptographic transport protocols, Proof of Stake, Byzantine Fault-Tolerant Replication Protocols, encrypted data transmission over peer-to-peer networks, data organization, consensus formation, and so on. The rules can create a process for miners to verify digital signatures in transactions in encrypted blocks, link new blocks with hash pointers into the blockchain, and replicate the blockchain to the nodes on the peer-to-peer network.

Smart contract <NUM> can include autonomously executable procedures so that system <NUM> can work as an autonomous organization system for managing data or transactions among the decentralized entities in the network. Smart contract <NUM> can enforce rules in consensus protocol <NUM>. Smart contract <NUM> can receive the stake at risk from the verifiers and provide the reward to the miners. The stake at risk can be in cryptocurrency. The reward can be in cryptocurrency. The verifiers can pay a verification fee. The verifiers can receive a verification reward. The stake at risk can vary for different verifiers and the verification reward can vary depending on the stake at risk by the verifier.

Consensus protocol <NUM> can include rules for refreshing the at least one verifiable characteristic of the asset after an event or period of time.

<FIG> is a flow chart of a method <NUM> for building blockchains for verifying assets for smart contracts, according to an example embodiment of the disclosure. Method <NUM> begins at block <NUM>.

At block <NUM>, a private key and a public key can be issued to each of a set of nodes in a network. For example, when a node is added to a peer-to-peer network, one of the existing nodes can identify the new node and issue private and public keys to the new node, which the new node can store in memory. The private and public keys can be used to digitally sign blocks on the blockchain. For example, a verifier node can digitally sign a block with a private key and a miner node can verify the identity of digital signature as the verifier node using a public key.

At block <NUM>, a stake at risk from a node that is a verifier can be received. For example, a consensus node can execute a smart contract to collect a collateral from the wallets of all the verifier nodes to be held in a common pot and used to pay out rewards for verifying a characteristic of an asset in a transaction on the blockchain.

At block <NUM>, a node that is a miner can distribute a blockchain to the network. For example, a miner node can validate the transaction or data record that verifies the characteristic of the asset and add the transaction or data record to a new block on the blockchain using consensus and replication processes. For example, the asset can be a residential home with characteristics such as date built, square feet, address, liens, additions, mortgage, and provenance. These characteristics can be verified by multiple verifier nodes such as banks, government entities, local county lien authorities, neighbors and other stakeholders. Verifier nodes can encrypt and write information about the characteristics and their verification or confirmation to the new block. A miner node can add the new block to the blockchain and distribute it over the network using consensus processes. Method <NUM> ends at block <NUM>.

In method <NUM>, the blockchain can have a new block representing a transaction for an asset having an identifier and a verifiable characteristic. The verifiable characteristic can be verified and signed with a private key by the verifier and the new block can be cryptographically verified by the miner using a public key. A reward can be provided to the miner and a reputational score and/or verification fee or reward can be provided to the verifier. For example, a consensus rule and/or smart contract can set up incentives so that verifiers with greater knowledge of a particular kind of asset has a greater chance of validating a block and thus being rewarded with cryptocurrency. Using a proof of stake model, miners can be rewarded for verifying the cryptographic authenticity of the block. For example, when the asset on the blockchain is a house, a large bank or loan originator can be most likely to cryptographically verify the blocks written to the blockchain but other entities that participate can also earn the right to earn cryptocurrency. Once the blocks verifying the loan by the bank and other verifications are on the blockchain and immutable, the blockchain for the house can be used to enter into an Ethereum contract, for example, and be bought and sold. In this way, various characteristics of an asset can be cryptographically secured, proved and vouched for so that the digital representation on the blockchain is trustworthy.

In method <NUM>, after the asset is verified and added to the blockchain, a smart contract can be provided for sale of the asset and/or the asset can be provided for sale in the real world. For example, once a retail brand expert verifies a Louis Vuitton® handbag in the blockchain, the handbag may be sold in an auction. Verified assets on the blockchain can create a trusted environment for digital sale without a buyer needing to examine the asset in person. Upon an event or expiration of a time period, verification of the asset on the blockchain can be requested, which may be a condition in the smart contract. For example, if the asset is a car, proof of title may be required before registration is issued or an emissions test may be required before a license plate is issued. For example, if an addition is added to a home, a basement is finished, or a kitchen remodeled, a building inspector may need to verify the home is still u0p to code. A later verification can influence reputational scores, for example, if an asset that was thought to be real was determined later to be fake.

<FIG> is a flow chart of a method <NUM> for building blockchains for verifying assets for smart contracts, according to an example embodiment of the disclosure. A non-transitory computer-accessible medium having stored thereon computer-executable instructions for building blockchains for verifying assets for smart contracts, wherein upon execution by a computer arrangement comprising a processor, the instructions cause the computer arrangement to perform method <NUM>. For example, the non-transitory computer-accessible medium may be a memory or other storage device accessible by one or more nodes in a peer-to-peer network.

Method <NUM> beings at block <NUM>. At block <NUM>, a block interface can be provided that provides a block data structure representing a transaction for an asset having an identifier and at least one verifiable characteristic. The block interface and block data structure can be in memory on a node and readable by the other nodes. The transaction can be any kind of event related to verifying the asset, like adding a digital representation of the asset. For example a photo and description of a home can be added in a transaction, which is verifiable by a realtor. The home can be identified by the address or some other identifier. Blocks in the blockchain can be related to the same home by referencing the identifier in the block data structure and the history of transactions related to this home in the blockchain can be reviewed by nodes. The block data structure can be a structured template or sort of schema that is specific to the category of the asset. For example, a diamond ring may include cut, clarity, color, how it is mounted, and the like while a home may include square footage, lot size, previous ownership, address and the like. Various different block data structures can be available in memory on a node that are specific to different categories of assets. Various consensus processes can require certain kinds of verification for different kinds of assets, depending on industry customs or norms, regulation, marketplace participants, and the like.

At block <NUM>, a host interface can be provided that can be configured to host a set of nodes in data communication in a peer-to-peer network. The host interface can be in memory on a node and readable by the other nodes. The host interface can include processes for consensus, node identity management, data communications, cryptography, and other processes. The host interface can be used by nodes to host a blockchain for verifying assets and smart contracts.

At block <NUM>, a key issuer interface can be provided that can be configured to issue private and public keys to each of the nodes. The key issuer interface can be in memory on a node and readable by the other nodes. The key issuer interface can include processes for issuing private and public keys to nodes being added to the network and managing the keys over time.

At block <NUM>, an ante up interface can be provided that can be configured to receive a stake at risk in cryptocurrency from one of the nodes. The ante up interface can be in memory on a node and readable by the other nodes. The ante up interface can collect stakes at risk by verifier nodes using Proof of Stake consensus protocols. The stakes at risk can be pooled into a common pot and used to pay out fees or rewards for verification. A node can provide cryptocurrency for the stake at risk from their wallet on the blockchain.

At block <NUM>, a reputational score interface can be provided that can be configured to assign a reputational score to one of the nodes. The reputational score interface can be in memory on a node and readable by the other nodes. The reputational score can be assigned in various ways such as by other nodes based on verification, mining and following consensus processes. Verifiers who deviate from consensus can lose their stake. Consensus processes can be devised to provide incentives to cooperate and punishment for bad behavior such as financial rewards and costs. Consensus processes can pair verifiers having low and high reputations. For example, a seasoned verifier can be paired with a novice verifier so that both make the same verification and it is more trustworthy than the novice verifier alone.

At block <NUM>, a verifier interface can be provided that can be configured to verify the verifiable characteristic of the asset and sign a new block with the private key and receive a verification reward in cryptocurrency. The verifier interface can be in memory on a node and readable by the other nodes. The number and kind of characteristics can depend on the type of asset. Many different verifiers can contribute to verifying different characteristics or aspects of the asset. For example, a verifier who is a builder can contribute the date a home was built and the square feet of the home. Another verifier who is a county inspector may verify that additions to the home are built to code. A verifier who is a photographer may verify the address of the home and the date of the photo. A verifier who is loan officer at a bank may verify the mortgage information. A verifier who is a neighbor may verify information about the neighborhood. Each verifier can post or contribute to the verification of the home in a transaction or block on the blockchain and encrypt the verification information using the private key. The verification information on the blockchain can be decrypted using a public key by other nodes. All of the verifiers can contribute to the overall representation of the home on the blockchain. Verifiers can engage in a proof of ownership model because they each have a vested interest in the accurate representation of the home and can check each other's information to verify that it came from an authoritative source, that it is accurate, etc. The verification reward can be paid out in cryptocurrency to verifier nodes using their wallets on the blockchain, according to consensus processes. Some verifiers can be paid verification fees according to smart contracts for special expertise or work, such as mortgage lenders, title recorders, or appraisers. The blockchain can be trusted for premium assets because of the verified characteristics and the reputations of the verifiers.

At block <NUM>, a miner interface can be provided that can be configured to cryptographically verify the new block using a public key in return for a reward in cryptocurrency and add the new block to a blockchain. The miner interface can be in memory on a node and readable by the other nodes. Miners can verify the digital signatures of new blocks and add them to the blockchain according to proof of stake consensus processes.

At block <NUM>, an update blockchain interface can be provided that can be configured to link one or more blocks having the block data structure into the blockchain. The update blockchain interface can be in memory on a node and readable by the other nodes. A miner node can link a new block to the blockchain, according to consensus processes.

At block <NUM>, a distribute blockchain interface can be provided that can be configured to distribute the blockchain to each node. The distribute blockchain interface can be in memory on a node and readable by the other nodes. A consensus node can distribute the updated blockchain to all the nodes, according to consensus processes.

At block <NUM>, a smart contract interface can be provided that can be configured to manage a digital sale of the asset. The smart contract interface can be in memory on a node and readable by the other nodes. Method <NUM> ends at block <NUM>. For example, a blockchain for a Louis Vuitton® handbag that verifies that the handbag is real and not fake can be used in the smart contract for a digital sale of the handbag. For example, a blockchain for a home with many trust-building, property-related verifications can be used by a real estate agent in the smart contract for a digital sale of the home. For example, third party resellers on Amazon® can use a blockchain to prove goods are not counterfeit by having a chain of ownership and/or various verifications.

In this description, numerous specific details have been set forth. It is to be understood, however, that implementations of the disclosed technology can be practiced without these specific details. References to "some examples," "other examples," "one example," "an example," "various examples," "one embodiment," "an embodiment," "some embodiments," "example embodiment," "various embodiments," "one implementation," "an implementation," "example implementation," "various implementations," "some implementations," etc., indicate that the implementation(s) of the disclosed technology so described can include a particular feature, structure, or characteristic, but not every implementation necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrases "in one example," "in one embodiment," or "in one implementation" does not necessarily refer to the same example, embodiment, or implementation, although it could.

As used herein, unless otherwise specified the use of the ordinal adjectives "first," "second," "third," etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

While certain implementations of the disclosed technology have been described in connection with what is presently considered to be the most practical and various implementations, it is to be understood that the disclosed technology is not to be limited to the disclosed implementations, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claim 1:
A system, comprising:
a memory (<NUM>, <NUM>, <NUM>) having a block data structure (<NUM>) representing a transaction (<NUM>) for an asset having an identifier (<NUM>, <NUM>) and at least one verifiable characteristic (<NUM>, <NUM>);
a blockchain (<NUM>, <NUM>, <NUM>, <NUM>) in the memory linking one or more blocks (<NUM>, <NUM>, <NUM>) having the block data structure;
a verifier node (<NUM>) that is a node (<NUM>) among a set of nodes in data communication in a peer-to-peer network, each node in the set of nodes being capable of receiving a distributed copy of the blockchain (<NUM>, <NUM>, <NUM>, <NUM>), at least one of the nodes including the memory,
wherein each verifier node (<NUM>) holds a stake at risk (<NUM>),
wherein each verifier node (<NUM>) receives a reputational score (<NUM>),
wherein each verifier node (<NUM>) has a private key (<NUM>),
wherein each verifier node (<NUM>) is capable of verifying the verifiable
characteristic of the asset and signing a new block (<NUM>) with the private key (<NUM>); and
a consensus protocol (<NUM>) in memory (<NUM>) including rules (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) for: receiving the stake at risk from the verifiers, providing the reputational score (<NUM>) to the verifiers (<NUM>), verifying the verifiable characteristic (<NUM>) of the asset by the verifiers, cryptographic verification by miners (<NUM>), adding the new block (<NUM>, <NUM>) to the blockchain (<NUM>, <NUM>, <NUM>, <NUM>) by the miners (<NUM>), providing the reward to the miners, and distributing the copy of the blockchain (<NUM>, <NUM>, <NUM>, <NUM>) to each node (<NUM>, <NUM>, <NUM>).