ASSET CARDS FOR TRACKING DIVISIBLE ASSETS IN A DISTRIBUTED LEDGER

Abstract

A system is provided for tracking units that are divisions of an asset via a distributed ledger. For each asset, the system records an asset card transaction that has an asset card smart contract and an asset card state. The asset card smart contract controls the transfer of ownership of units of an asset. The asset card state identifies the asset, an owner, and a divisibility factor. To transfer units, the asset card smart contract receives a transfer message to transfer a transfer number of units of the asset from a current owner to a new owner. Upon verifying the signature of the transfer message, the asset card smart contract updates the asset card state to reflect the transfer of the transfer number of units from the current owner to the new owner. Each asset card transaction is used to track ownership of units of a single asset.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. Non-Provisional patent application Ser. No. 15/976,798, filed on May 10, 2018, which claims the benefit of U.S. Provisional Patent Application No. 62/504,386, filed on May 10, 2017, which are hereby incorporated by reference in their entirety.

BACKGROUND

The bitcoin system was developed to allow electronic cash to be transferred directly from one party to another without going through a financial institution, as described in the white paper entitled “Bitcoin: A Peer-to-Peer Electronic Cash System” by Satoshi Nakamoto. A bitcoin is represented by a chain of transactions that transfers ownership from one party (the “sender”) to another party (the “recipient”). Each transaction has an output, and each transaction (except for the initial creating of a bitcoin) has an input that is an output of a prior transaction. To transfer ownership of a bitcoin that is output by a prior transaction, a new transaction is generated and added to a stack of transactions in a block. The new transaction, which includes the public key of the new owner, is digitally signed by the current owner to transfer ownership to the new owner as represented by the new owner's public key. The current owner signs the new transaction by signing with the current owner's private key a hash of the prior transaction and the new owner's public key. The new transaction is considered to have “consumed” the output of the prior transaction. Once the block is considered to be complete, the block is “capped” with a block header that is a hash digest of all the transaction identifiers within the block. The block header is recorded as the first transaction in the next block in the chain, creating a chain of transaction blocks in which each block links back to the prior block, called a “blockchain.” To verify that a proposed transaction is valid, the public key of the owner can be used to verify the signature, and the blockchain of transactions can be followed to verify that the prior transaction has not been consumed by another transaction. To prove ownership of the bitcoin of the new transaction, the new owner need only have the private key that matches the public key of the new transaction that transferred the bitcoin. The blockchain creates a mathematical proof of ownership in an entity represented by a security identity (e.g., a public key), which in the case of the bitcoin system is pseudo-anonymous.

The blockchain of the bitcoin system is stored as a distributed ledger. With the distributed ledger, a copy of the blockchain of all the transactions is stored redundantly at multiple nodes (i.e., computers) of a blockchain network. In a blockchain, the transactions are stored in the order that the transactions are received by the nodes. Each node in the blockchain network has a complete replica of the entire blockchain. The bitcoin system also implements techniques to ensure that each node will store the identical blockchain, even though nodes may receive transactions in different orderings. To verify that the transactions in a ledger stored at a node are correct, the blocks in the blockchain can be accessed from oldest to newest, generating a new hash of the block and comparing the new hash to the hash generated when the block was created. If the hashes are the same, then the transactions in the block are verified. The bitcoin system also implements techniques to ensure that it would be infeasible to change a transaction and regenerate the blockchain by employing a computationally expensive technique, referred to as mining, to generate a nonce that is added to the block when it is created. A bitcoin ledger is sometimes referred to as an Unspent Transaction Output (“UTXO”) set because it tracks the output of all transactions that have not yet been spent. To facilitate determining whether the input to a transaction has been spent, a node may maintain an index into the blockchain that points to the unspent transactions.

Although the bitcoin system has been very successful, it is limited to transactions in bitcoins or other cryptocurrencies. Efforts are currently underway to use distributed ledgers to support transactions of any type, such as those relating to the sale of vehicles, sale of financial derivatives, sale of stock, payments on contracts, and so on. Such transactions use identity tokens to uniquely identify something that can be owned or can own other things. An identity token for a physical or digital asset is generated using a cryptographic one-way hash of information that uniquely identifies the asset. Tokens also have an owner that uses an additional public/private key pair. The owner public key is set as the token owner identity, and when performing actions against tokens, ownership proof is established by providing a signature generated by the owner private key and validated against the public key listed as the owner of the token. A person can be uniquely identified, for example, using a combination of a user name, social security number, and biometric (e.g., fingerprint). A product (e.g., refrigerator) can be uniquely identified, for example, using the name of its manufacturer and its serial number. The identity tokens for each would be a cryptographic one-way hash of such combinations. The identity token for an entity (e.g., person or company) may be the public key of a public/private key pair, where the private key is held by the entity. Identity tokens can be used to identify people, institutions, commodities, contracts, computer code, equities, derivatives, bonds, insurance, loans, documents, and so on. Identity tokens can also be used to identify collections of assets. An identity token for a collection may be a cryptographic one-way hash of the digital tokens of the assets in the collection. The creation of an identity token for an asset in a distributed ledger establishes provenance of the asset, and the identity token can be used in transactions (e.g., buying, selling, insuring) of the asset stored in a distributed ledger, creating a full audit trail of the transactions.

To record a simple transaction in a distributed ledger, each party and asset involved with the transaction needs an account that is identified by a digital token in the network. For example, when one person wants to transfer a car to another person via a transaction, the current owner and next owner or recipient create accounts, and the current owner also creates an account that is uniquely identified by the car's vehicle identification number. The account for the car identifies the current owner. The current owner creates a transaction against the account for the car that indicates that the transaction is a transfer of ownership transfer, indicates the public keys (i.e., identity tokens) of the current owner and the next owner, and indicates the identity token of the car. The transaction is signed by the private key of the current owner, and the transaction is evidence that the next owner is now the current owner.

To enable more complex transactions than bitcoin can support, some systems use “smart contracts.” A smart contract is computer code that programmatically executes transactions that may be defined by a written contract or other predefined conditions. The Ethereum Request for Comment 20 (“ERC20”) is a technical standard defining the functions and event of an Ethereum smart contract. The computer code may be executed in a secure platform (e.g., an Ethereum platform, which provides a virtual machine) that supports recording transactions in a distributed ledger. In addition, the smart contract itself may be recorded as a transaction in the distributed ledger using an identity token that is a hash (i.e., identity token) of the computer code so that the computer code that is executed can be authenticated. When deployed, a constructor of the smart contract executes, initializing the smart contract and its state. The state of a smart contract is stored persistently in the distributed ledger. When a transaction is recorded against a smart contract, a message is sent to the smart contract, and the computer code of the smart contract executes to implement the transaction (e.g., debit a certain amount from the balance of an account). The computer code ensures that all the pre-defined conditions are met before the transaction is recorded in the blockchain. For example, a smart contract may support the sale of an asset. The inputs to a smart contract to sell a car may be the identity tokens of the seller, the buyer, and the car and the sale price in U.S. dollars. The computer code ensures that the seller is the current owner of the car and that the buyer has sufficient funds in their account. The computer code then records a transaction that transfers the ownership of the car to the buyer and a transaction that transfers the sale price from the buyer's account to the seller's account. If the seller's account is in U.S. dollars and the buyer's account is in Canadian dollars, the computer code may retrieve a currency exchange rate, determine how many Canadian dollars the seller's account should be debited, and record the exchange rate. If either transaction is not successful, neither transaction is recorded.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram that illustrates aspects of the AC system in some embodiments.

FIG. 2 is a block diagram illustrating changes in the state of an asset card transaction in some embodiments.

FIG. 3 is a flow diagram that illustrates processing of creating asset card transactions of the AC system in some embodiments.

FIG. 4 is a flow diagram that illustrates the processing of a transfer function of the asset card transaction of the AC system in some embodiments.

FIG. 5 is a block diagram that illustrates components of the AC system in some embodiments.

FIG. 6 is a flow diagram that illustrates the processing of a create asset card transaction component of an asset smart contract of the AC system in some embodiments.

FIG. 7 is a flow diagram that illustrates the processing of a transfer component of an asset card smart contract of the AC system in some embodiments.

FIG. 8 is a flow diagram that illustrates the processing of a sell component of the exchange system of the AC system in some embodiments.

FIG. 9 is a flow diagram that illustrates the processing of a full scan component of a vault system of the AC system in some embodiments.

DETAILED DESCRIPTION

A method and system are provided for tracking, via a distributed ledger, units that are divisions of an asset. In some embodiments, an asset card (“AC”) system tracks ownership of assets and ownership of divisions of assets in one or more distributed ledgers. A division of an asset is referred to as a unit of the asset. The AC system may provide an asset distributed ledger for storing an asset transaction for each asset and tracking custody and ownership of an asset during manufacturing, transport, and storage of the asset. An asset transaction includes an asset smart contract and an asset state that identifies an asset and stores other state information about the identified asset. The AC system may also provide an asset card distributed ledger for storing an asset card transaction for each asset for which the ownership of units of the asset can be transferred and for tracking ownership of the units of the asset. An asset card transaction includes an asset card smart contract and an asset card state. The asset card state identifies an asset and identifies the owners of the units of the identified asset. The smart contracts, which may be ERC20-compatible smart contracts, control the changing of the state of the transactions. The asset card transaction for an asset may uniquely identify an asset transaction for the same asset so that the asset state is readily available when transferring ownership of units of the asset. The AC system may be employed for tracking divisions of any type of asset whose ownership interest are considered to be divisible. For example, the AC system may be employed to track ownership of divisions of precious metals (e.g., gold bars or silver bars) and other commodities, such as petroleum. The asset card state for an asset may include a divisibility factor for an asset. For example, the divisibility factor for a 1.0 kilogram gold bar may be 10⁸, which means that the gold bar is tracked in units of 10⁻⁵ of a gram. In other words, the gold bar has 10⁸ units whose ownership can be separately transferred. As another example, the divisibility factor of a 1.0 kilogram may be 10¹¹ with each gram have 10⁸ units of 10⁻⁸ of a gram each. The asset distributed ledger and the asset card distributed ledger may be the same distributed ledger or different distributed ledgers. The distributed ledgers may be blockchain or non-blockchain.

In some embodiments, an asset card smart contract of an asset card transaction controls the transferring of ownership of units of the asset identified by the asset card transaction between entities (e.g., persons and organizations). When an asset card transaction is initially recorded, the asset card state includes an asset identifier, an initial owner, a divisibility factor, characteristic attributes (e.g., weight and dimensions), and an owner table. The asset identifier may a serial number assigned to the asset during the manufacturing process. The serial number may be embedded in the asset (e.g., engraved) and stored in the identification component. The initial owner is the owner of all the units of the asset when the asset card transaction is recorded. The owner table contains entries listing the current owners of units of the asset. Initially, the initial owner may be the only owner listed in the owner table and is listed as owning all the units. The owners may be identified by their addresses (e.g., hash of their public keys). The asset card smart contract may include a transfer function that is invoked when a transfer message corresponding to a transfer transaction is sent to the asset card transaction. The transfer message identifies the current owner of a transfer number of units of the asset and the new owner to whom the transfer number of units of the asset are to be transferred. The transfer message may be signed by the current owner and include the public key of the current owner. The asset card smart contract verifies that the transfer message was signed by using the private key corresponding to the public key in the transfer message and then verifies that the public key can be used to generate the address of the current owner. If the signature of the current owner is verified, then the transfer function updates the owner table to reflect the transfer. For example, the transfer function may mark the entry for the current owner and the entry (if any) for the new owner as no longer valid to indicate that they do not represent the current ownership of the units. The transfer function then adds new entries (marked as valid) indicating the total number of units owned by the current owner (if any) and owned by the new owner. Each entry of the owner table may include a valid flag to indicate whether the entry is valid or not.

In some embodiments, an asset smart contract of an asset transaction controls the transferring of custody and ownership of the asset identified by the asset smart contract. When an asset transaction is initially recorded, the asset state includes an asset identifier, characteristic attributes, location, a divisible flag, an asset card creatable flag, an asset card created flag, a custodian, and an owner. The divisible flag indicates whether the asset is divisible. For example, gold dore may not be divisible, but a gold bar may be divisible. The location identifies the current location of the asset, such as in a vault or in a manufactory. The asset card creatable flag indicates whether an asset card transaction is allowed to be created for the identified asset. The asset card created flag indicates whether an asset card transaction has been created for the identified asset. The asset smart contract may include a transfer custody function and a transfer ownership function. The transfer custody function processes transfer custody messages, which, for example, may be sent when the asset is given to a transportation company to transport to a new location. The transfer ownership function processes a transfer owner message to transfer ownership from the current owner to a new owner. Alternatively, the owner table may only store information relating to the current owners. The complete history of the prior owners and transfers is represented by transfer transactions recorded in the distributed ledger.

The AC system thus allows a physical asset to be divided into units for ease in transferring units of the asset from a current owner to a new owner. For example, if the price of gold is $50.00 per gram, then 10⁵ units of a 1.0 kilogram gold bar with a divisibility factor of 10⁸ would have a value of $50.00. The units of an asset can be transferred to a new owner as a payment by the current owner. The units can thus act as a cryptocurrency that is backed by the asset. In addition, an owner of all the units of an asset can redeem the asset card transaction for the physical asset, in which case the asset card transaction will be marked as redeemed and can no longer be used to transfer units in the asset. For example, the owner of all the units of an asset can tender the asset card transaction to a controlling entity that controls the vault in which the asset is stored. After confirming the asset card transaction is be tendered by the owner of all the units, the controlling entity may pull the asset from the vault and provide it to the owner.

In some embodiments, the AC system may include an exchange system through which clients can buy and sell units of an asset. The exchange system may provide a web site through which clients can provide payment information (e.g., in USD) for purchasing units of assets. For example, the exchange may offer to sell, from a pool of assets owned by the exchange system, 1.0 grams of gold of a gold bar for $52.00. To make a purchase, a client provides their address and transfers $52.00 to an account of the exchange system. Upon confirming payment, the exchange system identifies an asset card transaction with at least 10⁵ units that are owned by the exchange system. The exchange system then sends a transfer message to the asset card smart contract for the asset to transfer 10⁵ units from the address of the exchange system to the address of the client. After the transfer is recorded, the exchange system provides the address of the asset card transaction to the client as confirmation that the transfer has been recorded.

In some embodiments, the exchange system may select asset card transactions for a sale of units to maximize the number of asset card transactions in which the exchange system owns all the units. If all the units of an asset are fully owned by the exchange system, the exchange system has options that would not be available if the exchange system did not own all the units. The options include redeeming the asset, transferring ownership of the entire asset, and so on. To help maximize the number of fully owned assets, the exchange system may initially transfer units to the extent possible from asset card transactions in which the units are not fully owned by the exchange system. When a client sells units of an asset to the exchange system, then those units are available for subsequent sale. To help maximize the number of fully owned assets, the exchange system may select units for a sale transaction from different asset card transactions to minimize the number of asset card transactions in which the units are partially owned by the exchange system. For example, if a sale is for 10⁶ units and 10 asset card transactions each have only 10⁵ units that are currently owned by the exchange system, then the exchange system may transfer 10⁵ units from each of the 10 asset card transactions to the new owner. In addition, various machine learning techniques can be used to learn an allocation strategy based on historical sales and purchases to maximize the number of asset card transactions whose assets are fully owned by the exchange. For example, the AC system may employ a regression analysis to predict the number of purchase and sale transactions, their number of units, and even the transferor (current owner) and transferee (new owner) of the units for every hour over the next 24 hours. The AC system may then use the prediction to identify asset card transactions for the sale of assets to maximize the number of fully owned assets.

The AC system thus digitizes ownership interests in certain assets (e.g., gold or other commodities) to enhance access to the assets, enable tracking of assets via the asset distributed ledger based on their characteristics (e.g., conflict-free gold), and create efficiencies in supply chain management and trade finance. A unit of an asset is backed by the underlying asset (e.g., gold coin or gold bar). The units of an asset thus may be used as a medium of exchange and can be used as an alternative to flat currencies. The AC system provides the computer infrastructure for the creation of asset transactions and asset card transactions, the purchase of units of assets, the redemption of units of assets, the transfer of ownership of units of assets, and so on. As such, the AC system supports use of units of assets in settlement, payments, international remittances, investments, financing, and other activities. The units of an asset may be considered fungible. For example, 10⁴ units of a 10.0 kilogram gold bar may be fungible with 10⁵ units of a 1.0 kilogram gold bar, assuming the asset card transaction for each gold bar has the same divisibility factor.

In some embodiments, the AC system creates and records the asset transactions and the asset card transactions in one or more shared, and eventually interoperable, distributed ledgers so that units can be widely distributed and transferred using the distributed ledger. The distributed ledger may be public or permissioned (e.g., private or semiprivate). The distributed ledger may globally replicate on all nodes all transactions performed by the AC system or may replicate a transaction only on nodes involved in the transaction. Distributed ledgers, including blockchain ledgers, are publicly available from Openchain®, Chain®, Hyperledger®, MultiChain®, the R3 Consortium®, IMB®, and others.

In some embodiments, the AC system may require a purchaser of units of an asset from the exchange system to have been previously approved as a client or user and have an existing account with the exchange system. In some embodiments, before submitting a purchase request, a customer may need to be cleared under applicable know-your-customer (“KYC”) and anti-money laundering (“AML”) regulations and create a digital wallet to reflect the customer's ownership interests in units of assets. The purchase request submitted by a customer may be in any of several forms, including a standard smart contract, digital form, verified message, or e-mail. The purchase request may be recorded in a separate order ledger or in the distributed ledger.

In some embodiments, the assets of the asset card transaction may be stored in a depository or vault. The exchange system may enter into agreements with a depository pursuant to which (1) the depository agrees to treat the asset card distributed ledger as its own registry of ownership of assets and (2) the asset owners are generally provided with the clear right to withdraw the underlying asset upon “digital presentment” of the asset card transaction to the depository.

Although the AC system is described primarily in the context of assets that are minted gold (e.g., gold coin or gold bars), the AC system can be used to support transactions via the asset distributed ledger during the manufacturing process as gold transitions from gold dore to gold bars. The AC system can be used to track gold as it moves from mine to refinery, tracking both changes in custody and changes in ownership.

FIG. 1 is a block diagram that illustrates aspects of the AC system in some embodiments. A manufacturing process 100 for gold involves the processing steps of generating 101 gold dore, combining 102 the gold dore into a batch of gold, and minting 103 gold bars. Each gold dore, each batch of gold, and each gold bar is an asset and is assigned a serial number. The serial number may be embedded in an identification component attached to the asset. An asset distributed ledger 110 includes the various blocks 120 and 130 of transactions. The asset distributed ledger is used to track assets from creation to the final product of the manufacturing process. Each asset has a corresponding asset transaction stored in the asset distributed ledger. The block 120 includes transactions 121 and 122 representing gold dore and asset transaction 123 representing a batch of gold. The block 130 includes asset transactions 131 and 132 that each represent a gold bar. During the manufacturing process, asset transactions are created and recorded in the asset distributed ledger. When custody of an asset changes, such as during transportation from one location to another, the corresponding asset transaction is updated to represent the new custodian. An asset card distributed ledger 140 includes blocks 150 and 160. The blocks of the asset card distributed ledger include asset card transactions for certain types of assets. In this example, the block 160 includes an asset card transaction 161 and an asset card transaction 162, each of which represents a gold bar corresponding to the asset of asset transaction 131 and asset transaction 132, respectively. The asset card transaction may include a reference to a corresponding asset transaction, as illustrated by the dashed arrows.

The computing systems and devices of the AC system may include a central processing unit, input devices, output devices (e.g., display devices and speakers), storage devices (e.g., memory and disk drives), network interfaces, graphics processing units, cellular radio link interfaces, global positioning system devices, and so on. The input devices may include keyboards, pointing devices, touch screens, gesture recognition devices (e.g., for air gestures), head and eye tracking devices, microphones for voice recognition, and so on. The computing systems may include desktop computers, laptops, tablets, e-readers, personal digital assistants, smartphones, gaming devices, servers, and so on. The computing systems may access computer-readable media that include computer-readable storage media and data transmission media. The computer-readable storage media are tangible storage means that do not include a transitory, propagating signal. Examples of computer-readable storage media include memory such as primary memory, cache memory, and secondary memory (e.g., DVD) and other storage. The computer-readable storage media may have recorded on it or may be encoded with computer-executable instructions or logic that implements the AC system. The data transmission media is used for transmitting data via transitory, propagating signals or carrier waves (e.g., electromagnetism) via a wired or wireless connection. The computing systems may include a secure cryptoprocessor as part of a central processing unit for generating and securely storing keys and for encrypting and decrypting data using the keys.

The AC system may be described in the general context of computer-executable instructions, such as program modules and components, executed by one or more computers, processors, or other devices. Generally, program modules or components include routines, programs, objects, data structures, and so on that perform particular tasks or implement particular data types. Typically, the functionality of the program modules may be combined or distributed as desired in various examples. Aspects of the AC system may be implemented in hardware using, for example, an application-specific integrated circuit (ASIC) or field-programmable gate array (“FPGA”).

FIG. 2 is a block diagram illustrating changes in the state of an asset card transaction in some embodiments. Asset card states 200 illustrate the state of an asset card as it changes over time. Asset card state 210 illustrates the state of an asset when it is initially created and recorded in the distributed ledger. Asset card state 210 includes state information 201 comprising a reference to an asset transaction for an asset that is recorded in the asset distributed ledger (location of the asset transaction in the asset distributed ledger), a serial number for the asset, the weight of the asset (1.0 kilograms), a divisibility factor for the asset (10⁸ or alternatively just the exponent 8), and an indication of the initial owner (O.add). The asset card state 201 also includes an owner table 202 with entries that include an owner field, a units field, and a valid field. The owner field identifies an owner of one or more units of the asset. The units field identifies the number of units owned by the owner. The valid field indicates whether the entry is valid. Entry 211 indicates that the initial owner owns all the units of the asset. Asset card state 220 illustrates that owner O.add has transferred 50,000,000 units of the asset to owner O1.add. Entry 221 is marked as not valid, and entries 222 and 223 indicate that owner O.add and owner O1.add each owns 50,000,000 units. Asset card state 230 illustrates that owner O1.add has transferred 25,000,000 units to owner O2.add. Entry 232 is marked as not valid, and entries 234 and 235 indicate that owner O1.add and owner O2.add each own 25,000,000 units. Asset card state 240 illustrates that owner O1.add has transferred 1.0 unit to owner O3.add. Entry 245 is marked as not valid, and entries 246 and 247 indicate that owner O1.add and owner O3.add own 24,999,999 units and 1.0 unit, respectively. Asset card state 250 illustrates that owner O3.add has transferred 1.0 unit to owner O4.add. Entry 257 is marked as not valid, and entry 258 indicates that owner O4.add owns 1.0 unit. Asset card state 260 illustrates that owner O4.add has transferred 1.0 unit to owner O2.add. Entries 265 and 268 are marked as not valid, and entry 269 indicates that owner O2.add now owns 25,000,001 units. The sum of the units of the valid entries is always the divisibility factor of 100,000,000.

FIG. 3 is a flow diagram that illustrates processing of creating asset card transactions with an asset card smart contract for each asset of the AC system in some embodiments. A create asset card transactions component 300 records an asset card transaction for each of the identified assets. In block 301, the component selects the next asset. Each asset may be identified by a reference to an asset transaction in the asset distributed ledger. In decision block 302, if all the assets have already been selected, the component completes, else the component continues at block 303. In block 303, the component creates an asset card transaction corresponding to the selected asset. In block 304, the component records the asset card transaction that includes the asset card smart contract and the asset smart card state for the asset in the asset card distributed ledger and then loops to block 301 to select the next asset.

FIG. 4 is a flow diagram that illustrates the processing of a transfer function of the asset card transaction of the AC system in some embodiments. A transfer component 400 is invoked when a transfer message is received by the asset card transaction. In block 401, the component verifies the transfer request to ensure that it has been signed by the owner whose assets are to be transferred. In block 402, the component updates the owner table of the asset card transaction to reflect the transfer and completes.

FIG. 5 is a block diagram that illustrates components of the AC system in some embodiments. The systems of the AC system may include vault systems 510, client systems 520, an exchange system 530, and distributed ledger nodes 540 with distributed ledger stores 541. The systems communicate via a communications channel 550, such as the Internet. The vault systems track inventory of assets within a vault and interface with the asset distributed ledger and the asset card distributed ledger. The vault system uses the asset card transaction for an asset to verify that an entity asking to redeem an asset is the owner of the asset. The client systems allow clients (i.e., entities) to interact with the distributed ledgers to transfer units of assets, check the balances agreements of assets, and so forth. Each client system may implement a wallet component for locally tracking the units owned by the client, storing private keys, interacting with the exchange system, and so on. The exchange system provides a mechanism through which clients can buy units of assets from the exchange system and sell units of assets to the exchange system. The distributed ledger nodes and the distributed ledger stores implement the asset distributed ledger and the asset card distributed ledger.

FIG. 6 is a flow diagram that illustrates the processing of a create asset card transaction component of an asset smart contract of the AC system in some embodiments. The create asset card component 600 is invoked when an asset transaction receives a create asset card message. In block 601, the component verifies the signature of the create asset card message. In decision block 602, if the signature is verified, then the component continues at block 603, else the component completes, indicating failure. In decision block 603, if the asset state indicates that the location of the asset is in a vault, the component continues at block 604, else the component completes, indicating failure. In decision block 604, if the asset state indicates that an asset card transaction can be created, then the component continues at block 605, else the component completes, indicating failure. In decision block 605, if the asset state indicates that the asset has been minted (i.e., it is divisible), then the component continues at block 606, else the component completes, indicating failure. In decision block 606, if the asset state indicates that an asset card transaction has not yet been created for the asset, then the component continues at block 607, else the component completes, indicating failure. In block 607, the component creates an asset card transaction corresponding to the asset of the asset transaction. In block 608, the component records the asset card transaction in the asset card distributed ledger. In block 609, the component sets the asset card created indicator to indicate that an asset card transaction has been created for the asset and then completes.

FIG. 7 is a flow diagram that illustrates the processing of a transfer component of an asset card smart contract of the AC system in some embodiments. The transfer component 700 is invoked when a transfer message is received by an asset card transaction. In block 701, the component checks the signature of the transfer message to ensure that it has been signed by an owner of the units of the asset. In decision block 702, if the signature is verified, then the component continues at block 703, else the component completes, indicating failure. In decision block 703, if the balance of units owned by the transferor as indicated by the owner table is sufficient to support the transfer, then the component continues at block 704, else the component completes, indicating failure. In block 704, the component marks the entry in the owner table for the transferor to not valid. In decision block 705, if the balance is now zero, then the component continues at block 707, else the component continues at block 706. In block 706, the component adds an entry to the owner table for the transferor with the updated balance and continues at block 707. In decision block 707, if the transferee has an entry in the owner table, the component continues at block 708, else the component continues at block 709. In block 708, the component marks the entry for the transferee as not valid and continues at block 709. In block 709, the component adds an entry for the transferee to the owner table with an updated balance and then completes, indicating success.

FIG. 8 is a flow diagram that illustrates the processing of a sell component of the exchange system of the AC system in some embodiments. The sell component 800 is invoked, indicating the number of units to be sold and the address of the buyer. In block 801, the component identifies an asset card transaction with a best fit to support the sale. The best fit, for example, may be an asset card transaction that tends to maximize the number of assets that are fully owned by the exchange. In block 802, the component creates a transfer message (e.g., a transaction) to transfer the sold number of units to the buyer. In block 803, the component signs the transfer message. In block 804, the component sends the transfer message to the identified asset card transaction to complete the transfer. The component then completes.

FIG. 9 is a flow diagram that illustrates the processing of a full scan component of a vault system of the AC system in some embodiments. The scan component 900 is invoked to scan the inventory in a vault. In block 901, the component selects the next asset in the vault. In decision block 902, if all the assets have already been selected, then the component continues at block 908, else the component continues at block 903. In block 903, the component sends a query to the identification component of the selected asset, requesting the serial number of the asset. In block 904, the component waits for a response or a timeout. In decision block 905, if a response is received, then the component continues at block 906, else the component continues at block 907. In block 906, the component marks the asset as in the vault and loops to block 901 to select the next asset. In block 907, the component marks the asset as not in the vault and loops to block 901 to select the next asset. In block 908, the component records the results and then completes.

The following paragraphs describe various embodiments of aspects of the AC system. An implementation of the AC system may employ any combination of the embodiments. The processing described below may be performed by a computing device with a processor that executes computer-executable instructions stored on a computer-readable storage medium that implements the AC system.

A method performed by one or more computing systems for tracking units that are divisions of an asset is provided. For each of a plurality of assets, the method records in an asset card distributed ledger an asset card transaction. The asset card transaction has an asset card smart contract and an asset card state. The asset card smart contract for controlling transfer of ownership of units of an asset between entities. The asset card state identifying the asset, an owner, and a divisibility factor. The divisibility factor indicating the number of units of the asset. The number of units are initially owned by an initial owner. For each of a plurality of assets, the method also receives by the asset card transaction for that asset a transfer message to transfer a transfer number of units of the asset from a current owner to a new owner. Under control of the asset card smart contract, the method verifies that the transfer message was signed by the current owner and verifies that the current owner owns at least the transfer number of units of the asset. When the verifications are successful, the method updates the asset card state to reflect the transfer of the transfer number of units of the asset from the current owner to the new owner. Each asset card transaction is used to track ownership of units of a single asset. In some embodiments, the asset card state of an asset card transaction specifies a weight of the asset identified by the asset card state. In some embodiments, the method further, prior to recording an asset card transaction that identifies an asset, records in an asset distributed ledger an asset transaction having an asset smart contract and an asset state. The asset smart contract for recording in the asset card distributed ledger an asset card transaction for the asset. The asset state including an identifier of the asset and an indicator indicating whether an asset card transaction has been recorded for the identified asset. In some embodiments, the asset state further includes an identification of an asset location of the asset, an indication of whether an asset card transaction can be created for the asset, and a dividable indicator of whether the asset is in a state where it can be divided into units. In some embodiments, an asset is gold, the asset location is in a vault, and the dividable indicator is that the gold has been minted. In some embodiments, the asset distributed ledger and the asset card distributed ledger are the same distributed ledger. In some embodiments, the asset card state includes an owner table and the updating of the asset card state includes updating the owner table to reflect units owned by the current owner and the new owner after the transfer. In some embodiments, the owner table includes a history of all transfers of units of the asset. In some embodiments, the owner table indicates current ownership of units of the asset. In some embodiments, the owner table does not indicate prior ownership of units of the asset. In some embodiments, the asset card distributed ledger is a blockchain distributed ledger.

In some embodiments, a method performed by one or more computing systems for transferring ownership of a transfer number of units of an asset is provided. The method receives a request to transfer ownership of a unit of an asset from a first entity to a second entity. The first entity owns units of assets. Each asset is represented by an asset card transaction in an asset card distributed ledger. Each asset card transaction has an asset card state indicating entities that each own a specified number of units of the asset. The method identifies n asset card transaction for which the asset card state indicates that the first entity owns some units of the asset, but not all the units of the asset. When an asset card transaction is not identified, the method identifies an asset card transaction for which the asset card state indicates that the first entity owns all the units of the asset. The method transfers ownership of the transfer number of units of the asset of the identified asset card transaction from the first entity to the second entity. In some embodiments, the identifying of asset card transactions seeks to identify asset card transactions to maximize the number of the asset card transactions in which all the units of the asset of the asset card transaction are owned by the first entity. In some embodiments, the asset card transactions are recorded in a distributed ledger. Each asset card transaction has an asset card smart contract and an asset card state. The asset card smart contract for controlling transfer of ownership of units of an asset between entities. The asset card state identifies the asset, an owner of the asset card transaction, a divisibility factor, and owner data. The divisibility factor indicates the number of units of the asset. The number of units is initially owned by an initial owner. The owner data identifies each entity that owns one or more units of the asset and the number of units owned by each entity. In some embodiments, when the first entity is owner of an asset card transaction and owns all the units of the asset of that asset card transaction, the method transfers ownership of the asset card transaction.

In some embodiments, one or more computing systems for tracking units that are divisions of assets is provided. The one or more computing systems includes one or more computer-readable storage mediums storing computer-executable instructions and one or more processors for executing the computer-executable instructions stored in the one or more computer-readable storage mediums. The computer-executable instructions control the one or more computing system to, for each asset, record, in an asset card distributed ledger, an asset card transaction. The asset card transaction has an asset card smart contract and an asset card state. The asset card smart contract for controlling transfer of ownership of units of an asset between entities. The asset card state identifying the asset and a divisibility factor. The divisibility factor indicates the number of units of the asset. Under control of the asset card smart contract, the computer-executable instructions control the one or more computing system to update the asset card state to reflect a transfer of a transfer number of units of the asset from a current owner to a new owner. In some embodiments, the asset card state of each asset card transaction specifies the weight of the asset identified by the asset card state. In some embodiments, the asset card state includes owner data and the instructions that control the one or more computing systems to update the asset card state update the owner data to reflect units owned by the current owner and the new owner after the transfer. In some embodiments, the asset card smart contract conforms to the Ethereum Request for Comment 20 technical standard. In some embodiments, each asset is a gold bar held in a vault. In some embodiments, when an entity who owns all units of a gold bar identified by an asset card transaction takes possession of the gold bar, the asset card state is changed to indicate that the gold bar is no longer in the vault. In some embodiments, each asset has an attached identification component for electromagnetically providing an identification number of the asset. In some embodiments, the identification component is a near-field communication component. In some embodiments, the identification component stores a private key for the asset for signing the identification number.

Although the subject matter has been described in language specific to structural features and/or acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. Accordingly, the invention is not limited except as by the appended claims.

Claims

1. A method performed by one or more computing systems for tracking units that are divisions of an asset, the method comprising:

for each of a plurality of assets, recording, in an asset card distributed ledger, an asset card transaction, the asset card transaction having an asset card smart contract and an asset card state, the asset card smart contract for controlling transfer of ownership of units of an asset between entities, the asset card state identifying the asset, an owner, and a divisibility factor, the divisibility factor indicating the number of units of the asset, the number of units being initially owned by an initial owner; receiving by the asset card transaction a transfer message to transfer a transfer number of units of the asset from a current owner to a new owner; and

under control of the asset card smart contract, verifying that the transfer message was signed by the current owner; verifying that the current owner owns at least the transfer number of units of the asset; when the verifications are successful, updating the asset card state to reflect the transfer of the transfer number of units of the asset from the current owner to the new owner

wherein each asset card transaction is used to track ownership of units of a single asset.

2. The method of claim 1 wherein the asset card state of an asset card transaction specifies a weight of the asset identified by the asset card state.

3. The method of claim 1 further comprising, prior to recording an asset card transaction that identifies an asset, recording in an asset distributed ledger an asset transaction having an asset smart contract and an asset state, the asset smart contract for recording in the asset card distributed ledger an asset card transaction for the asset, the asset state including an identifier of the asset and an indicator indicating whether an asset card transaction has been recorded for the identified asset.

4. The method of claim 3 wherein the asset state further includes an identification of an asset location of the asset, an indication of whether an asset card transaction can be created for the asset, and a dividable indicator of whether the asset is in a state where it can be divided into units.

5. The method of claim 4 wherein an asset is gold, the asset location is in a vault, and the dividable indicator is that the gold has been minted.

6. The method of claim 3 wherein the asset distributed ledger and the asset card distributed ledger are the same distributed ledger.

7. The method of claim 1 wherein the asset card state includes an owner table and the updating of the asset card state includes updating the owner table to reflect units owned by the current owner and the new owner after the transfer.

8. The method of claim 7 wherein the owner table includes a history of all transfers of units of the asset.

9. The method of claim 7 wherein the owner table indicates current ownership of units of the asset.

10. The method of claim 9 wherein the owner table does not indicate prior ownership of units of the asset.

11. The method of claim 1 wherein the asset card distributed ledger is a blockchain distributed ledger.

12. A method performed by one or more computing systems for transferring ownership of a transfer number of units of an asset, the method comprising:

receiving a request to transfer ownership of a unit of an asset from a first entity to a second entity, the first entity owning units of assets, each asset represented by an asset card transaction in an asset card distributed ledger, each asset card transaction having an asset card state indicating entities that each own a specified number of units of the asset;

identifying an asset card transaction for which the asset card state indicates that the first entity owns some units of the asset, but not all the units of the asset;

when an asset card transaction is not identified, identifying an asset card transaction for which the asset card state indicates that the first entity owns all the units of the asset; and

transferring ownership of the transfer number of units of the asset of the identified asset card transaction from the first entity to the second entity.

13. The method of claim 12 wherein identifying of asset card transactions seeks to identify asset card transactions to maximize the number of the asset card transactions in which all the units of the asset of the asset card transaction are owned by the first entity.

14. The method of claim 12 wherein the asset card transactions are recorded in a distributed ledger, each asset card transaction having an asset card smart contract and an asset card state, the asset card smart contract for controlling transfer of ownership of units of an asset between entities, the asset card state identifying the asset, an owner of the asset card transaction, a divisibility factor, and owner data, the divisibility factor indicating the number of units of the asset, the number of units being initially owned by an initial owner, the owner data identifying each entity that owns one or more units of the asset and the number of units owned by each entity.

15. The method of claim 14 further comprising, when the first entity is owner of an asset card transaction and owns all the units of the asset of that asset card transaction, transferring ownership of the asset card transaction.

16. One or more computing systems for tracking units that are divisions of assets, the one or more computing systems comprising:

one or more computer-readable storage mediums storing computer-executable instructions for controlling the one or more computing system to, for each asset, record, in an asset card distributed ledger, an asset card transaction, the asset card transaction having an asset card smart contract and an asset card state, the asset card smart contract for controlling transfer of ownership of units of an asset between entities, the asset card state identifying the asset and a divisibility factor, the divisibility factor indicating the number of units of the asset; and under control of the asset card smart contract, update the asset card state to reflect a transfer of a transfer number of units of the asset from a current owner to a new owner; and

one or more processors for executing the computer-executable instructions stored in the one or more computer-readable storage mediums.

17. The one or more computing systems of claim 16 wherein the asset card state of each asset card transaction specifies the weight of the asset identified by the asset card state.

18. The one or more computing systems of claim 16 wherein the asset card state includes owner data and the instructions that control the one or more computing systems to update the asset card state update the owner data to reflect units owned by the current owner and the new owner after the transfer.

19. The one or more computing systems of claim 16 wherein the asset card smart contract conforms to the Ethereum Request for Comment 20 technical standard.

20. The one or more computing systems of claim 16 wherein each asset is a gold bar held in a vault.

21. The one or more computing systems of claim 20 wherein when an entity who owns all units of a gold bar identified by an asset card transaction takes possession of the gold bar, changing the asset card state to indicate that the gold bar is no longer in the vault.

22. The one or more computing systems of claim 16 wherein each asset has an attached identification component for electromagnetically providing an identification number of the asset.

23. The one or more computing systems of claim 22 wherein the identification component is a near-field communication component.

24. The one or more computing systems of claim 22 wherein the identification component stores a private key for the asset for signing the identification number.