Hierarchical Digital Issue Tokens and Claim Tokens

Abstract

The first tier of the hierarchy maintains a record of assets issued or otherwise made available by issuers. The available assets may be distributed among accounts within the first tier. Asset ownership is recorded on a distributed ledger. One or more of the first tier accounts may be held by first tier investors (such as institutional investors) that purchase and hold a portion of the available assets as direct / primary investments. One or more of the other first tier accounts may be client omnibus accounts operated by financial institutions that hold a portion of the available assets and make assets available that can be invested by second tier accounts. Interests in assets made available for investment by second tier accounts are recorded on a distributed ledger. In some instances, second tier accounts can offer investments in interests held by the second tier accounts to third tier accounts, which can offer interests to fourth tier accounts, etc.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 380,573, filed October 23, 2022, and U.S. Provisional Patent Application No. 63 / 419,666, filed October 26, 2022, both of which are incorporated herein by reference.

[0002] The present disclosure relates generally to the field of distributed ledger technology (DLT), and more particularly to managing the registration, custody, and ownership of digital assets on DLT using a hierarchy of digital asset tokens and claim tokens. [Background technology]

[0003] Distributed ledgers (e.g., blockchains) were developed as a means for parties to engage in transactions, e.g., financial transactions, without the need for a single trusted intermediary. In such systems, each transaction is recorded independently by multiple nodes. In some implementations, no single entity controls all of the nodes, making it extremely difficult for a malicious actor to tamper with transactions recorded by the nodes. Even in implementations where a single entity controls all of the nodes, it is still extremely difficult to tamper with data recorded by enough nodes to change the consensus expressed by all of the nodes without leaving any trace that the data was tampered with.

[0004] There are many scenarios where it is beneficial for asset custody to be distinct and separate from asset ownership. For example, an investor may purchase gold bars or other precious metal securities, but the physical metal ingots are typically in the custody of a bank or other financial institution. However, traditional blockchain digital asset systems often do not distinguish between custody and ownership. As such, these traditional blockchain digital asset systems are not well-suited to providing primary issuance and secondary trading (potentially at multiple levels of hierarchy) in digital asset investments. Summary of the Invention

[0005] These and other challenges may be solved using hierarchical digital asset tokens and claim tokens. In the first tier of the hierarchy, a digital securities issuance record (defining the number of securities issued / made available by an issuer) is deployed as a smart contract on the platform. This issuance record is managed by a registrar / central securities depository / central account manager and is used to reconcile digital asset token holdings in first-tier accounts (or wallets). In this disclosure, the term account is used to represent the concept of a wallet or account in various DLT ledgers and should be interpreted broadly to include any digital structure capable of recording ownership of digital tokens.

[0006] The available assets may be distributed among accounts within the first tier. Asset ownership is recorded on the first tier blockchain. One or more of the first tier accounts may be custodial accounts of first tier investors (e.g., institutional investors) that purchase and hold a portion of the available assets as direct / primary investments (where permitted by relevant regulatory requirements). One or more of the other first tier accounts may be provider accounts operated by financial institutions (acting as custodians), which hold a portion of the available assets and make the assets available for investment by second tier accounts. Interests in assets made available for investment by second tier accounts are recorded on one or more blockchains for the second tier. The first tier accounts may also include risk accounts of financial institutions that hold a portion of the available assets for their own benefit. In some embodiments, the second tier accounts can offer investments in their interests to third tier accounts, etc. A hierarchy can have any number of tiers, each with a stake in the holdings of the tier above it, recorded on one or more blockchains. [Brief explanation of the drawings]

[0007] The disclosed embodiments have advantages and features that will become more readily apparent from the detailed description, the appended claims, and the accompanying drawings, the brief description of which follows.

[0008] [Figure 1] FIG. 1 is a block diagram illustrating a networked computing environment that may provide custody and ownership of digital assets using hierarchical claim tokens, according to one embodiment. [Figure 2] FIG. 1 is a block diagram of a set of accounts providing secondary and tertiary interests in digital assets using hierarchical claim tokens, according to one embodiment. [Figure 3]1 is a flowchart of a method for assigning second-tier ownership or beneficial interests in a first-tier digital asset to a user according to one embodiment. [Figure 4] 2 is a block diagram of an example computer suitable for use in the networked computing environment of FIG. 1 according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] The drawings and the following description describe specific embodiments for purposes of illustration only. Those skilled in the art will readily recognize from the following description that alternative embodiments of structures and methods may be employed without departing from the principles described. Wherever possible, like or similar reference numerals are used in the drawings to indicate similar or similar functionality. When components share a common numeral followed by a different letter, this indicates that the components are similar or identical. Unless the context dictates otherwise, reference to a numeral alone generally refers to any one or any combination of such components.

[0010] Example System 1 illustrates one embodiment of a networked computing environment 100 that may provide custody and ownership of digital assets using hierarchical claim tokens. In the illustrated embodiment, the networked computing environment 100 includes a first distributed ledger 110A that includes a first set of distributed nodes 112, a second distributed ledger 110B that includes a second set of distributed nodes 114, a management device 150, an asset issuer device 160, a provider client device 170, and an owner client device 180, all connected via a network 190. In other embodiments, the networked computing environment 100 includes fewer, different, or additional components. Furthermore, functionality may be distributed among the components in ways different from those described.

[0011] FIG. 1 shows two distributed ledgers 110A and 110B for illustrative purposes. In practice, a networked computing environment may include any number of distributed ledgers. For example, in one embodiment, a single permissioned distributed ledger is used to store all digital assets, as well as tokens representing beneficial interests in those assets, at all tiers in the hierarchy. Meanwhile, in another embodiment, one or more of the tiers in the hierarchy store tokens representing beneficial interests in digital assets in one or more distributed ledgers that are different from the distributed ledger used to store the digital assets. In FIG. 1, the first distributed ledger 110A is shown to include three distributed nodes 112: a first distributed node 112A, a second distributed node 112B, and an Nth distributed node 112N. Similarly, the second distributed ledger 110B is shown to include a first distributed node 114A, a second distributed node 114B, and an Nth distributed node 114N. In practice, each distributed ledger 110 can (and likely will) include many more nodes.

[0012] The distributed nodes 112, 114 are computing devices. The distributed nodes may manage and provide a blockchain or other type of distributed ledger. The distributed nodes may also store and execute rules established by smart contracts. Thus, when a trigger condition of a smart contract is met, one or more actions may be automatically executed by the distributed nodes 112, 114. In various embodiments, the distributed nodes may operate independently from the management device 150. When an event or data related to a smart contract is generated, the associated information may be added to a block in the blockchain. The blockchain and smart contracts may codify and automatically enforce the rules governing ownership and investment of digital assets.

[0013] When a distributed node 112 or 114 receives a request to execute a transaction, it confirms or denies whether the transaction's associated data matches its records. A transaction is considered successfully verified if a threshold amount of distributed nodes agree that the transaction matches its records. For example, using a Byzantine fault tolerance approach, enough nodes may confirm the validity of a transaction and decide whether to validate it. Similarly, an action defined in a smart contract's rules may be triggered if a threshold amount of distributed nodes agree that the trigger conditions for that action are met.

[0014] A distributed ledger 110 generally takes one of the following forms: - A single global ledger maintained by all nodes in a blockchain network, or - A global ledger made up of multiple local ledgers maintained by individual nodes in the network.

[0015] In DLT embodiments that use a single global ledger, when a change to the blockchain is made (e.g., when a new transaction or block is created), nodes form a consensus on how the change should be integrated into the network of distributed nodes. In consensus, the agreed-upon changes are considered confirmed such that each node maintains a copy that must match the copies stored by other nodes. Changes that do not result in consensus may be ignored. Thus, unlike traditional centralized ledgers, a single party cannot unilaterally tamper with the blockchain.

[0016] In DLT embodiments that use a global ledger composed of multiple local ledgers, when a transaction is submitted to the network, the relevant nodes verify and provide confirmation of the transaction's validity. Upon consensus, agreed-upon changes are considered confirmed and used to update the contract state in the relevant nodes' local ledgers. Unlike embodiments that use a single global ledger, each node maintains its own private state for those ledgers that collectively form the global ledger.

[0017] A blockchain may also include smart contracts, which are sets of executable instructions stored in association with one or more trigger conditions. If a trigger condition is met, the smart contract is triggered to execute the corresponding instructions. Each distributed node 112, 114 may receive the smart contract definition, but the results resulting from the execution of the code in the smart contract are only validated if consensus is reached among the nodes on the state of the smart contract (e.g., only if the trigger condition is met and enough nodes agree that execution of the instructions will lead to a particular outcome). In other embodiments, other types of distributed ledgers may be used.

[0018] The management device 150 is a computing device that provides services to other devices in the networked computing environment 100 to provide hierarchical claim tokens. While only one management device 150 is shown, any number of management devices may be included in the networked computing environment 100. The management device 150 provides and manages hosting of parties. A party may be an individual or legal entity executing commands to interact with the ledger. In one embodiment, parties are assigned various roles through the use of smart contracts that govern which ledgers and data objects (e.g., smart contracts) the parties may view and modify. The permissions of parties in the networked computing environment may be generated from the parties' assigned roles and stored in smart contracts (called "services") that are stored in the distributed ledger (e.g., the first distributed ledger 110A or the second distributed ledger 110B).

[0019] The management device 150 may also manage accounts within the networked computing environment. Typically, an account involves two parties: an account provider and an account owner. The account provider is the party assigned the custodian role and has access to the custodian service functionality. Typically, either party may be the account owner, which may be subject to KYC / AML rules that may result in the party being barred from using the networked computing environment 100. In one embodiment, when the account owner and account provider agree to open a new account, the management device 150 creates a smart contract with information about the account, such as the account identifier, account owner, account provider, as well as the account's KYC status (e.g., active, special, non-trading, or closed). Each custodian / account provider periodically updates the account's KYC status.

[0020] In addition to node hosting options, the management device 150 may also provide interfaces, such as application programming interfaces (APIs), through which other devices in the networked computing environment may submit to one or more distributed ledgers. In one embodiment, the management device 150 provides an interface for first tier accounts in an account hierarchy. The first tier accounts may store tokens for digital assets, while lower tier accounts may store tokens representing claims on the first tier digital assets. For example, qualified institutional investors may be able to own digital assets in the first tier and offer investment opportunities to other investors in one or more secondary markets by issuing tokens to lower tier accounts. In one embodiment, tokens for all tiers are stored on a single blockchain. Alternatively, some or all of the tokens for the second tier (and lower tiers, if used) may be stored on a blockchain separate from the blockchain that stores the first tier tokens. Various embodiments of a distributed ledger hierarchy are described in more detail below with reference to FIG. 2.

[0021] Asset issuer device 160 is a computing device where a user (e.g., a government or private institution) can create (i.e., issue) digital assets. While only one asset issuer device 160 is shown, a networked computing environment can include any number of such devices. In one embodiment, smart contracts capturing asset attributes (e.g., type, initial value, interest rate, validity period, payment amount at maturity, available amount, etc.) are deployed to the ledger and made available to other nodes authorized to view these contracts. Asset issuers can choose to create data objects representing each instance of an asset in the distributed ledger using API interfaces exposed by management device 150. Alternatively, asset issuer device 160 may create data objects representing assets directly on the ledger by hosting its own node.

[0022] Provider client device 170 and owner client device 180 are computing devices through which users (e.g., employees of a financial institution and account holders, respectively) may interact with a distributed ledger, such as distributed ledger 110A or distributed ledger 110B. While only one provider client device 170 and one owner client device 180 are illustrated, in practice, networked computing environment 100 may include any number of such devices. In one embodiment, during account creation, provider client device 170 receives an account creation request from owner client device 180 and, after approving it, formulates / creates (either directly or via management device 150) a smart contract for the account in the distributed ledger (e.g., including identifiers of the provider and owner, as well as KYC information). Users may also use owner client device 180 to submit requests to buy or sell digital assets. Depending on the embodiment, such requests may be sent directly to the appropriate distributed ledger or to provider client device 170 or management device 150 for processing.

[0023] Network 190 provides a communication channel through which other components of networked computing environment 100 communicate. Network 190 may include any combination of local area networks or wide area networks using both wired and wireless communication systems. In one embodiment, network 190 uses standard communication technologies or protocols. For example, network 190 may include communication links using technologies such as Ethernet 802.11, worldwide interoperability for microwave access (WiMAX), 3G, 4G, 5G, code division multiple access (CDMA), and digital subscriber line (DSL). Examples of network protocols used to communicate over network 190 include multiprotocol label switching (MPLS), gRPC Remote Procedure Calls (GRPC), transmission control protocol / Internet protocol (TCP / IP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP), and file transfer protocol (FTP). Data exchanged over network 190 may be represented using any suitable format, such as hypertext markup language (HTML) or extensible markup language (XML). In some embodiments, all or part of the communication links of network 190 may be encrypted using any suitable technique or techniques.

[0024] FIG. 2 illustrates one embodiment of a layered, hierarchical account structure with a custodian that stores securities in a tier one account and offers claim tokens for digital assets in a tier two account. In the illustrated embodiment, the account structure is arranged in a hierarchy with three tiers. However, in principle, there may be any number of tiers within the hierarchy. Each additional tier allows providers holding tokens in a higher tier to further divide the ownership or beneficial interest represented by those tokens into multiple portions represented by further tokens in lower tiers. All tiers may be stored on a single blockchain, with permissions controlling what information each participating entity may see. Alternatively, entities storing assets in tier one may operate a separate blockchain to record beneficial interests in the assets they store.

[0025] Tier 1 210 of the tiered account structure is responsible for the digital custody of the assets themselves. Custody of digital assets is typically limited to a small number of qualified institutional investors depending on jurisdictional requirements (e.g., some jurisdictions do not allow institutional investors to self-custody). Controls are implemented to only allow the account owner to transfer / move assets within the account, as well as view holdings. A tier 1 account may provide ownership or beneficial interest in the assets it stores to other users, hold assets as self-custodian for its own benefit, or both. In the embodiment shown in FIG. 2 , tier 1 210 includes a securities issuing account 211 (which contains the assets when they are initially issued on the ledger), one or more tier 1 investor risk accounts 212, a first tier 1 provider risk account 214, a tier 1 provider omnibus client account 215, a second tier 1 provider risk account 216, and one or more tier 1 segregated accounts 217. As previously mentioned, each account may be a blockchain address, a wallet, or an account represented within the ledger, depending on the DLT technology used. In other embodiments, Tier 1 210 may include different or additional components. For example, any number of providers may have risk accounts and omnibus client / segregated accounts within the Tier 1 ledger 210.

[0026] The securities issuance account (or securities issuance register) 211 is where the initial issuance of a set of assets is recorded. Thus, information about the assets and the number of assets issued is stored using a smart contract. The smart contract may be used for reconciliation against Tier One's asset holdings. The securities issuance account 211 is distinct from a trading account (used to store securities). The securities issuance account 211 does not have custody of the assets and does not represent legal ownership of the assets, but rather serves as a registry of the assets.

[0027] Tier one investor risk accounts 212 are for accounts permitted to trade on the first tier ledger 210 (e.g., institutional investors) that wish to self-custody their assets (i.e., hold an account directly with a registrar). Tier one investor risk accounts 212 hold the investor's primary positions.

[0028] In the illustrated example, there is both a tier one omnibus client account 215 (which stores tokens for multiple entities within a single account) and one or more tier one segregated accounts 217 (with each segregated account storing tokens for a single entity). Depending on local regulatory requirements and client preferences, a tier may use only the tier one omnibus client account 215, only a set of tier one segregated accounts 217, or a combination of both (e.g., if local laws and regulations permit omnibus accounts but one or more clients choose to use segregated accounts). Additionally, while a particular number of different types of accounts are illustrated, the first tier may include accounts of each type for any number of providers that make investments in digital assets available to second-tier users.

[0029] In some embodiments, a provider may have risk accounts and holding accounts. The purpose of a custodian maintaining risk accounts and omnibus accounts is to separate a client's custodial assets (stored in the client omnibus account) from its appropriate assets (stored in the risk account). However, in a typical configuration, a custodian does not hold privately held assets and therefore does not need (and may not have) risk accounts. That said, for completeness, FIG. 2 shows a first tier-one provider risk account 214 in which the custodian may hold digital assets held in its firm-capacity, as well as digital assets stored by other tier-one participants, and a tier-one provider omnibus client account 215 in which the provider stores digital assets for which the provider makes ownership or beneficial interest available to second-tier users. Similarly, a second tier-one provider risk account 216 stores digital assets held by a second provider for appropriate investment. However, the second provider has a tier one segregated account 217 that holds digital assets that provide beneficial interests to second tier users that are segregated from digital assets for which other tier one participants are custodians.

[0030] The second-tier accounts hold tokens representing ownership or beneficial interests in digital assets held in custodian-managed accounts within Tier One 210. The second-tier accounts do not store digital assets themselves, but rather hold claims issued by their respective securities custodians. This may be implemented by ownership or beneficial interest smart contracts signed by the custodian accounts. In the embodiment shown in FIG. 2, the second tier includes a first portion 220 and a second portion 230. Each tier two portion corresponds to a different custodian within Tier One. In one embodiment, the accounts in Tier Two portions 220 and 230 are part of the same ledger that includes the Tier One accounts. Alternatively, some or all of the Tier Two accounts may be stored on different ledgers. It should be noted that although the first tier two division 220 is shown as branching off from the tier one omnibus client account 215 and the second tier two division 230 is shown as branching off from the tier one segregated account 217, the tier two divisions may branch off from the tier one omnibus client account, the segregated account, or any combination of both.

[0031] The first tier two section 220 is for a first tier one provider. In this case, the first tier one provider / custodian secures the securities of its tier two clients by holding the securities in an omnibus account and using custodian-issued claim tokens held in the tier two account to represent ownership or beneficial interest in the digital assets in the tier two account. However, these secondary users do not further divide the ownership or beneficial interest in the tier three account. Thus, accounts in the first tier two section 220 hold digital assets of tier two investors. Digital assets held in the custodian omnibus account are matched with claim tokens in the tier two investor account provided by the custodian. When a tier two user invests in digital assets for which the first tier one provider is the custodian, tokens representing ownership or beneficial interest in the digital assets (or a portion of the digital assets) are added to the tier two user's account 222.

[0032] Similarly, second tier two portion 230 includes second tier two investor account 232, which may store claim tokens (issued by a custodian) representing ownership or beneficial interests in digital assets (or portions of digital assets) for which the second tier one provider is custodian. Second tier two portion 230 may include omnibus client account 236, which further subdivides the ownership or beneficial interests it holds and makes portions of the subdivided ownership or beneficial interests available to third-tier investors, tier two segregated accounts that store tokens representing beneficial interests held by individual tier two participants, or a combination of both. Tier two omnibus client account 236 functions similarly to a tier one omnibus client account (e.g., tier one omnibus client account 215), except that rather than being a custodian of digital assets, tier two omnibus client account 236 holds ownership or beneficial interests in assets of multiple tier two participants. Some or all of the multiple tier two participants may make ownership or beneficial interests in their interests available to third tier investors. Tier two segregated account 238 is similar to tier one segregated account 217, except that it stores ownership or beneficial interests of individual tier two participants. Some or all of the tier two participants may make ownership or beneficial interests in their interests available to third tier investors.

[0033] Tier three 240 includes accounts 242 of tier three users who acquire ownership or beneficial interests from tier two providers. Note that tier three ledger 240 may also include one or more provider accounts that make ownership or beneficial interests in digital assets available to fourth tier users, up to any number of tiers. An advantage of using the layered structure shown in FIG. 2 is that it provides privacy controls, thereby allowing account providers to only know the clients they hold and maintaining a match between the assets they custody and the number of claim tokens issued to custodial clients. For example, a second tier one provider may only need to know which ownership or beneficial interests it granted to a tier two user. It may not need to know whether the tier two user retains these interests for its own benefit or further transfers them to a tier three user. Furthermore, because the tier one user remains the custodian of the digital assets, tier one 210 can remain unchanged when ownership or beneficial interests are traded at tier two 220 and 230. Similarly, tier two 220 and 230 may remain unchanged if beneficial interests are exchanged or traded with tier three 240, etc.

[0034] Another advantage of the tiered structure is that different tier two (or lower) units may be used to offer trading of ownership or beneficial interests in different jurisdictions. Each tier two unit 220, 230 may be configured to comply with local regulatory requirements for trading in securities. Thus, tier one 210 may be universal and may include custody of the underlying digital assets. Meanwhile, tier two may offer trading of securities of the same underlying asset to different markets with different regulatory requirements.

[0035] Example Method Figure 3 illustrates one embodiment of a method 300 for assigning ownership or beneficial interest in digital assets to users. The steps of Figure 3 are shown from the perspective of a computing device managing interactions with the distributed ledger (e.g., provider client device 170) that executes method 300. However, some or all of the steps may be performed by other entities or components. Additionally, some embodiments may perform steps in parallel, in a different order, or perform different steps.

[0036] In the embodiment shown in FIG. 3, method 300 begins with a computing device receiving 310 a request to assign ownership or beneficial interest in digital assets to a user / act as a custodian for the user. The digital assets (represented by a smart contract on a distributed ledger) are stored within an account at the custodian. The computing device / custodian can verify the custody relationship by querying 320 a ledger of custody service contracts that include the custodian and client signatories. The computing device receives 330 a response to the query verifying that the custodian account stores the digital assets. The custodian may verify that it stores the digital assets by verifying that a digital asset token smart contract held by the custodian account includes a registrar signatory and the digital asset's issuer. Assume that custody has been established between the custodian and the client through the use of a smart contract. After settlement occurs, the tier-two account stores (340) a token representing ownership or beneficial interest in the digital assets in the custodian account on the distributed ledger (the user's account is a smart contract on the distributed ledger). The user's ownership or beneficial interest (represented by the claim token smart contract) may be signed with the custodian's digital signature to verify its authenticity. In this way, the user's ownership or beneficial interest in the digital assets may be recorded without tampering with the tier-one blockchain that manages the custody of the digital assets.

[0037] Computing System Architecture FIG. 4 illustrates an exemplary computer 400 suitable for use as a management device 150, an asset issuer device 160, a provider client device 170, an owner client device 180, or a distributed node 112 or 114, according to one embodiment. The exemplary computer 400 includes at least one processor 402 coupled to a chipset 404. For convenience, various operations may be described as being performed by “processor 402.” This should be understood to mean that the described operations are performed by one or more processors operating independently or cooperatively. The chipset 404 includes a memory controller hub 420 and an input / output (I / O) controller hub 422. A memory 406 and a graphics adapter 412 are coupled to the memory controller hub 420, and a display 418 is coupled to the graphics adapter 412. A storage device 408, a keyboard 410, a pointing device 414, and a network adapter 416 are coupled to the I / O controller hub 422. Other embodiments of the computer 400 have different architectures.

[0038] In the embodiment shown in FIG. 4, storage device 408 is a non-transitory computer-readable storage medium such as a hard drive, a compact disk read-only memory (CD-ROM), a DVD, or a solid-state memory device. Memory 406 holds, for example, instructions for executing the methods described above and data used by processor 402. Pointing device 414 may be a mouse, a trackball, a touchscreen, or any other type of pointing device and may be used in combination with keyboard 410 (which may be an on-screen keyboard) to input data into computer system 400. Graphics adapter 412 displays images and other information on display 418. Network adapter 416 couples computer system 400 to one or more computer networks (e.g., network 190). The types of computers used by the entities of FIG. 1 can vary depending on the embodiment and the processing power required by the entities. Additionally, a computer may lack some of the components described above, such as keyboard 410, graphics adapter 412, and display 418.

[0039] Additional Considerations Some of the above description has described embodiments in terms of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the computing arts to effectively convey the substance of their work to others skilled in the art. These operations, while described functionally, computationally, or logically, will be understood to be performed by computer programs including instructions for execution by a processor or equivalent electrical circuits, microcode, or the like. Further, it will prove convenient at times to refer to these arrangements of functional operations as modules, without loss of generality.

[0040] As used herein, a reference to "one embodiment" or "an embodiment" means that a particular component, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in this specification do not necessarily all refer to the same embodiment. Similarly, the use of "a" or "an" before an element or component is done merely for convenience. This description should be understood to mean that one or more of the element or component are present, unless it is clear that something else is meant.

[0041] When values ​​are described as "approximate" or "substantially" (or derivatives thereof), unless otherwise clear from the context, such values ​​should be construed to be exact + / - 10%. As an example, "approximately 10" should be understood to mean "within the range of 9 to 11."

[0042] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or other variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, provision, or apparatus comprising a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed in or inherent in such process, method, provision, or apparatus. Also, unless expressly stated to the contrary, "or" refers to an inclusive or, not an exclusive or. For example, condition A or B can be satisfied by any one of the following: A is true (or present) and B is false (or absent), A is false (or absent) and B is true (or present), and both A and B are true (or present).

[0043] Upon reading this disclosure, those skilled in the art will recognize still additional alternative structural and functional designs for systems and processes for providing hierarchical claim tokens. Accordingly, while specific embodiments and applications have been illustrated and described, it should be understood that the described subject matter is not limited to the precise configurations and components disclosed. The scope of protection should be limited only by the scope of the claims as may ultimately be issued.

Claims

1. 1. A computer-implemented method comprising: receiving a request to assign ownership or beneficial interest in digital assets held by a tier one custodian account on a distributed ledger to a tier two user account, wherein the tier two user account and the custodian account are smart contracts on the distributed ledger; sending a request to the custodian account on the distributed ledger to verify that the custodian account stores the digital asset, wherein the custodian account verifies the storage of the digital asset using a digital asset smart contract that includes a digital signature of a registrar confirming that the custodian account stores the digital asset; receiving verification of custody of the digital assets from the custodian account; In response to receiving the verification result, storing tokens representing ownership or beneficial interest in the digital assets in the custodian account of the tier one in a user account of the tier two; A method comprising:

2. The smart contract for the digital asset further includes a signature of the issuer of the digital asset. The method of claim 1.

3. the owner of the tier one custodian account on the distributed ledger has a risk account for holding one or more additional instances of the digital asset on behalf of the owner of the tier one custodian account; The method of claim 1.

4. The Tier 1 custodian accounts are operated by qualified financial institutions and the Tier 2 user accounts are operated by retail investors; The method of claim 1.

5. the tier two user account is one of a plurality of tier accounts within a tier, each account within the tier including tokens representing an ownership or beneficial interest in the tier immediately preceding the tier; The method of claim 1.

6. the token representing the ownership or beneficial interest includes a digital signature of a custodian; The method of claim 1.

7. receiving a request from the tier three account on the distributed ledger to assign ownership or beneficial interest in the tokens to the tier three account; verifying that the token is signed with the digital signature of the custodian; assigning the ownership or beneficial interest in the token to the tier three account in response to the token being signed with the digital signature of the custodian, wherein the ownership or beneficial interest in the token is one of multiple ownership or beneficial interests in the token assigned to different tier three accounts on the distributed ledger; further comprising: The method of claim 6.

8. ownership or beneficial interest in the digital assets is assigned to the Tier 2 user account without changing any account within the Tier 1; The method of claim 1.

9. The digital assets are issued by an issuer and attached to an issuer account, the issuer account being a smart contract on the structure of a tier one account in the distributed ledger, and the issuer account does not store the digital assets but acts as a transaction account for holding the digital assets when the digital assets are initially created on the distributed ledger. The method of claim 1.

10. the tier two user account is one of a plurality of tier two accounts, each of which records ownership or beneficial interest in a different instance of the digital asset at the tier one custodian; The method of claim 1.

11. 1. A non-transitory computer-readable storage medium storing computer program instructions that, when executed by a computing system, cause the computing system to perform operations, the operations including: receiving a request to assign ownership or beneficial interest in digital assets held by a tier one custodian account on a distributed ledger to a tier two user account, wherein the tier two user account and the custodian account are smart contracts on the distributed ledger; sending a request to the custodian account on the distributed ledger to verify that the custodian account stores the digital asset, wherein the custodian account verifies the storage of the digital asset using a digital asset smart contract that includes a digital signature of a registrar confirming that the custodian account stores the digital asset; receiving verification of custody of the digital assets from the custodian account; In response to receiving the verification result, storing tokens representing ownership or beneficial interest in the digital assets in the custodian account of the tier one in a user account of the tier two; 1. A non-transitory computer-readable storage medium, comprising:

12. The smart contract for the digital asset further includes a signature of the issuer of the digital asset. The non-transitory computer-readable storage medium of claim 11.

13. the owner of the tier one custodian account on the distributed ledger has a risk account for holding one or more additional instances of the digital asset on behalf of the owner of the tier one custodian account; The non-transitory computer-readable storage medium of claim 11.

14. The Tier 1 custodian accounts are operated by qualified financial institutions and the Tier 2 user accounts are operated by retail investors; The non-transitory computer-readable storage medium of claim 11.

15. the tier two user account is one of a plurality of tier accounts within a tier, each account within the tier including tokens representing an ownership or beneficial interest in the tier immediately preceding the tier; The non-transitory computer-readable storage medium of claim 11.

16. the token representing the ownership or beneficial interest includes a digital signature of a custodian; The non-transitory computer-readable storage medium of claim 11.

17. The operation is receiving a request from the tier three account on the distributed ledger to assign ownership or beneficial interest in the tokens to the tier three account; verifying that the token is signed with the digital signature of the custodian; assigning the ownership or beneficial interest in the token to the tier three account in response to the token being signed with the digital signature of the custodian, wherein the ownership or beneficial interest in the token is one of multiple ownership or beneficial interests in the token assigned to different tier three accounts on the distributed ledger; further comprising:

17. The non-transitory computer-readable storage medium of claim 16.

18. ownership or beneficial interest in the digital assets is assigned to the Tier 2 user account without changing any account within the Tier 1; The non-transitory computer-readable storage medium of claim 11.

19. The digital assets are issued by an issuer and attached to an issuer account, the issuer account being a smart contract on the structure of a tier one account in the distributed ledger, and the issuer account does not store the digital assets but acts as a transaction account for holding the digital assets when the digital assets are initially created on the distributed ledger. The non-transitory computer-readable storage medium of claim 11.

20. the tier two user account is one of a plurality of tier two accounts, each of which records ownership or beneficial interest in a different instance of the digital asset at the tier one custodian; The non-transitory computer-readable storage medium of claim 11.

Images