U.S. patent application number 16/262821 was filed with the patent office on 2019-05-30 for asset cards for tracking divisible assets in a distributed ledger.
The applicant listed for this patent is Responsible Gold Operations Ltd.. Invention is credited to Brent William de Jong.
Application Number | 20190164223 16/262821 |
Document ID | / |
Family ID | 62631155 |
Filed Date | 2019-05-30 |
United States Patent
Application |
20190164223 |
Kind Code |
A1 |
de Jong; Brent William |
May 30, 2019 |
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.
Inventors: |
de Jong; Brent William;
(Houston, TX) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Responsible Gold Operations Ltd. |
Houston |
TX |
US |
|
|
Family ID: |
62631155 |
Appl. No.: |
16/262821 |
Filed: |
January 30, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15976798 |
May 10, 2018 |
|
|
|
16262821 |
|
|
|
|
62504386 |
May 10, 2017 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/02 20130101;
G06Q 20/382 20130101; G06Q 2220/00 20130101; H04L 9/0897 20130101;
H04L 9/3247 20130101; H04L 2209/56 20130101; G06Q 20/40 20130101;
G06Q 20/401 20130101; H04L 9/3213 20130101; G06Q 20/389 20130101;
G06Q 40/04 20130101 |
International
Class: |
G06Q 40/04 20060101
G06Q040/04; H04L 9/32 20060101 H04L009/32; G06Q 20/38 20060101
G06Q020/38; H04L 9/08 20060101 H04L009/08 |
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.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation of U.S. patent
application Ser. No. 15/976,798, filed May 10, 2018; which claims
the benefit of U.S. Provisional Application No. 62/504,386, filed
on May 10, 2017, both of which applications are hereby incorporated
by reference in theft entireties.
BACKGROUND
[0002] 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.
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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 predefined 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 sellers account
is in U.S. dollars and the buyers 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
[0007] FIG. 1 is a block diagram that illustrates aspects of the AC
system in some embodiments.
[0008] FIG. 2 is a block diagram illustrating changes in the state
of an asset card transaction in some embodiments.
[0009] FIG. 3 is a flow diagram that illustrates processing of
creating asset card transactions of the AC system in some
embodiments.
[0010] 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.
[0011] FIG. 5 is a block diagram that illustrates components of the
AC system in some embodiments.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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
[0016] 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.sup.8, which means that the gold bar is
tracked in units of of a gram. In other words, the gold bar has
10.sup.8 units whose ownership can be separately transferred. As
another example, the divisibility factor of a 1.0 kilogram may be
10.sup.11 with each gram have 10.sup.8 units of 10.sup.-8 o f 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.
[0017] 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.
[0018] 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 dare 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.
[0019] 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.sup.5 units of a 1.0 kilogram gold bar
with a divisibility factor of 10.sup.8 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.
[0020] 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.sup.5 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.sup.5
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.
[0021] 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.sup.6 units
and 10 asset card transactions each have only 10.sup.5 units that
are currently owned by the exchange system, then the exchange
system may transfer 10.sup.5 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.
[0022] 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 fiat 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.sup.4 units of a 10.0 kilogram gold bar may be fungible
with 10.sup.5 units of a 1.0 kilogram gold bar, assuming the asset
card transaction for each gold bar has the same divisibility
factor.
[0023] 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.RTM., Chain.RTM.,
Hyperledger.RTM., MultiChain.RTM., the R3 Consortium.RTM.,
IMB.RTM., and others.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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").
[0030] 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.sup.8 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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 t he 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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
* * * * *