System, apparatus, and method for identifying and securely storing differentiated features in distributed ledgers within distributed ledger-based network based on homogenized and non-homogenized token

Abstract

The invention relates to a system, apparatus and method for identifying and securely storing differentiated features in a distributed ledger within a distributed ledger-based network based on homogenized and non-homogenized token. In some embodiments, a method includes storing data associated with a homogenized asset in a distributed ledger database. The method comprises dividing the homogenized token into a first set of homogenized token groups based on the data and sending each homogenized token group of the first set of homogenized token groups to a communication device of the first set of communication devices via a distributed ledger-based network and based on an asymmetric cryptographic key pair, and sending the non-homogenized token of each homogenized token group in the second set of homogenized token groups to the specified receiver communication device by the second plurality of communication devices. The first set of homogenized token groups is divided into a second set of homogenized token groups and received at a second set of communication devices.

Description

[0001] This application is a divisional application of the invention patent application with application number 202080081078.4, application date November 19, 2020, and invention name "Systems, devices and methods for identifying and securely storing distinguishing features of distributed ledgers based on homogeneous and non-homogeneous tokens in a distributed ledger-based network."

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application is a non-provisional application of U.S. Provisional Application Serial No. 62 / 938,210, filed on November 20, 2019, entitled “Methods and Systems for Identifying Distinguishing Characteristics of Fungible Assets on Distributed Ledger-Based Networks” and claims priority under 35 U.S.C. §§119, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0004] Some embodiments described herein generally relate to transforming data structures of a distributed ledger-based network. In particular, but not by way of limitation, some embodiments described herein relate to systems, devices, and methods for identifying and storing distinguishing features in a distributed ledger based on fungible tokens and non-fungible tokens within a distributed ledger-based network. Background Art

[0005] A distributed ledger is a consensus of replicated and synchronized data that is geographically shared across multiple nodes on a network. Without the use of a centralized data store, each distributed ledger database replicates and holds an identical copy of the ledger. Distributed ledgers can employ executable code (also known as smart contracts) to manage transactions and store transaction records between different participants in a distributed ledger-based network (DLN) without the need for a central authority. However, this transparency can reduce or even eliminate any privacy or confidentiality that participants need or seek when interacting with a DLN or its participants.

[0006] Thus, there is a need for a distributed ledger-based network that provides a decentralized and transparent platform to facilitate transactions between participants and protect the privacy or confidentiality required by the participants. Summary of the invention

[0007] In some embodiments, a method includes storing data associated with a set of asset shares from a homogenous set of assets in a first instance of a distributed ledger database at a transaction initiating communication device. The method includes dividing the homogenous token set into a first set of homogenous token groups based on data at a processor of the transaction initiating communication device. Each asset share in the set of asset shares is associated with a communication device in the first set of communication devices. The homogenous token set collectively represents a homogenous asset set on a distributed ledger-based network. The method includes sending each homogenous token group in the first set of homogenous token groups via a distributed ledger-based network and at least in part based on an asymmetric cryptographic key pair to a communication device that is (1) associated with that homogenous token group and (2) from the first set of communication devices, so that a second plurality of communication devices sends a non-homogeneous token set of each homogenous token group in the second set of homogenous token groups to a designated recipient communication device. The first set of homogeneous token groups is divided into a second set of homogeneous token groups and received at a second set of communication devices, the second set of communication devices being at a different level than the first set of communication devices in terms of the order of data transmission. Each non-fungible token in the set of non-fungible tokens is indivisible and is associated with (1) a transaction destination in the set of transaction destinations, and (2) an identifier from the set of identifiers, the second set of communication devices not including the transaction initiating communication device.

[0008] In this application, tokens do not include virtual currencies. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A distributed ledger-based network (DLN) is shown according to some embodiments, which is configured to establish a chain of custody of assets in a network of cascaded communicating devices in the DLN and reveal or identify distinguishing characteristics of the assets, wherein the assets are represented on the DLN via tokens.

[0010] Figure 2A-2C An example sequential flow diagram is shown illustrating establishing a chain of custody of an asset in a network of cascaded communicating devices in a DLN, and identifying distinguishing characteristics of the asset, wherein the asset is represented on the DLN via a token, according to some embodiments.

[0011] Figure 3 A flow chart is shown that illustrates a method of establishing chain of custody of an asset in a network of cascaded communication devices in a DLN, in accordance with some embodiments. DETAILED DESCRIPTION

[0012] In some embodiments, the parties involved in a transaction may choose to use a public or private (permissioned) distributed ledger-based network (DLN) to record the details of the transaction and manage its operation. The DLN may provide a decentralized platform that is transparent to all participants of the network, if not to the general public, and may therefore be viewed as a consensus-based platform that promotes trust between transaction participants without the need for a central authority to manage the network. For example, parties involved in a transaction involving an asset (e.g., on or off the DLN) may represent the asset on the DLN (e.g., blockchain) via a token and use a self-executing code segment or program (e.g., smart contract) on the DLN to manage the transaction on the DLN.

[0013] In some embodiments, distinguishable assets can be represented by non-fungible tokens, while indistinguishable assets can be represented by homogenous tokens. Examples of such assets include financial instruments (e.g., dividends, interest payments, capital gains, etc.), legal digital assets (e.g., digital RMB, excluding prohibited virtual currencies), physical objects, etc. In some implementations, homogenous tokens represent non-interchangeable or indistinguishable assets. Homogenous tokens can be of the same type and can be aggregated and / or divided. Examples of homogenous tokens include, but are not limited to, a certain amount of financial instruments, legal tender, stocks, wages, reams of paper, etc. Non-fungible tokens represent uniquely identifiable or distinguishable assets. Non-fungible tokens cannot be divided and combined to increase or decrease the "amount" of non-fungible tokens. Non-fungible tokens can have a unique identifier or serial number. In some examples, non-fungible tokens allow tracking of individual assets, and tracking at the level of individual assets can use more storage and computing than using homogenous tokens representing a group or batch of assets. Examples of non-fungible tokens include, but are not limited to, tokens that identify ownership of an asset, a car’s vehicle identification number (VIN), a property deed, a shipment tracking number, etc.

[0014] In some embodiments, a fungible token may represent an asset or a right to an asset (rather than the asset itself). Throughout the description herein, assets and rights to assets may be used interchangeably. In some examples, a fungible token represents an asset. In some examples, a fungible token represents the allocation and ownership of rights to dividends (also known as "dividend rights"). In some examples, a fungible token represents a "right" or "right" in an asset, rather than directly representing the asset itself. For example, a property deed is not the property itself, it is the right to claim ownership of that property.

[0015] In some implementations, a self-executing code snippet or smart contract can regulate transactions between parties by, for example, verifying proofs that the parties to the transaction can submit in connection with the transaction, as discussed below. In some implementations, records of secure transactions on a DLN can be used to establish a chain of custody for assets represented on the DLN via tokens in a network of communication devices on the DLN (operated by a group of entities). In some implementations, information about any communication device that interacts with a fungible token can be recorded in the chain of custody of that fungible token. In other words, when a fungible token is transferred from a sending communication device to a receiving communication device, the identifiers of the sending communication device to the receiving communication device can be recorded in a distributed ledger database of a distributed ledger network (DLN). Therefore, the chain of custody via the DLN provides integrity, traceability, authentication, verifiability, and security of token transfers for both participating and non-participating parties on the DLN.

[0016] In some embodiments, the DLN may be and / or support a blockchain. Throughout this disclosure, in some embodiments, the terms "distributed ledger-based network" and "blockchain network" may be used interchangeably. Similarly, in some embodiments, the terms "self-executing code" or "self-executing code snippet" and "smart contract" may be used interchangeably. In addition, the term "transaction" may be used to refer to interactions on the DLN between DLN participants involving assets. Interactions or transactions include establishing a chain of custody of assets by tracking the division of homogeneous tokens representing assets and allocations to entities and identifying the distinguishing characteristics of assets by generating non-homogeneous tokens representing the same assets (e.g., via generating a token that includes a unique identifying feature of the asset). The terms "off-chain" or "outside the DLN" should be understood to mean "not on a blockchain network" or "not on the DLN". For example, a statement such as "data is stored outside the DLN" should be understood to mean a statement that "data is not stored on the storage system(s) of the DLN or is not controlled by the DLN (but is instead stored in or controlled by a system elsewhere, i.e., on a storage system not on the DLN.)". The embodiments described herein may take place in, for example, a public DLN or a private (licensed) DLN.

[0017] In some embodiments, the trust provided by a distributed ledger-based network without the need for a central authority stems from the network's transparency to at least all participants of the network (and, in the case of a public network, to the public at large). However, such transparency may reduce or even eliminate any privacy or confidentiality that participants require or seek when interacting with the network or its participants. For example, in the case of a public network, any interested party may access and inspect the distributed ledger on the network to obtain detailed information (e.g., including details of confidential financial transactions) about all transactions represented on the ledger since the inception of the network (because, at least in most cases, the ledger is substantially immutable). Transparent access to detailed information has the same implications among participants of a private or permissioned distributed ledger network.

[0018] Thus, one or more embodiments described herein operate with a distributed ledger-based network that provides a decentralized and trusted platform that enables (one or more) embodiments to efficiently share information between participants over the network while maintaining distinguishing characteristics of security and privacy. In some implementations, smart contracts allow for the tokenization of financial assets (e.g., dividend rights declared in a dividend event triggered by an initiating financial intermediary (such as a local custodian)). In addition, the disclosed methods and systems automatically interact with intermediate communication devices to extract key information for identifying, for example, each successive level of equity. Fungible tokens can be distributed to multiple participants via a DLN. Once the transaction destination of the fungible token is identified (e.g., the owner of the fungible token (natural person or institution)), the smart contract allows the generation of a non-fungible token based on the fungible token, and provides the recipient of the non-fungible token with information for calculating the value (e.g., withholding tax) assigned to that non-fungible token based on the subset of the fungible token represented by that fungible token and the additional information provided by the non-fungible token (e.g., treaty category, country of residence, identity and certificate of residence (COR) that can be encrypted to access the investor). In some implementations, the correct withholding tax amount can be determined based on cross-border investment income, eliminating the need for calculations at the transaction initiating communication device and other intermediate communication devices. For example, such calculations include payment reconciliations at various levels of the financial intermediary network. One or more embodiments described herein increase the accuracy of calculations, reduce the possibility of fraud, and increase trust among all participants. One or more embodiments described herein also eliminate the need for lengthy and expensive recovery processes, for example, when withholding tax calculations are inaccurate due to lack of information and lack of trust within existing systems.

[0019] In some embodiments, the level of privacy and security available on a DLN (e.g., a private or public DLN) can be enhanced via the implementation of zero-knowledge proofs (ZKPs) in the DLN. In some implementations, a ZKP-enabled DLN can provide at least an increased level of privacy to transaction participants while still maintaining the level of trust provided by a decentralized network (i.e., without a central authority). For example, a ZKP-enabled DLN (e.g., a ZKP-enabled public DLN or blockchain) can be used to facilitate transactions without revealing publicly or to other participants of the ZKP-enabled DLN details of the transaction, such as, but not limited to, the identities of the parties to the transaction, the assets transferred as part of the transaction, tokens representing assets on the ZKP-enabled DLN (e.g., fungible or non-fungible tokens representing assets on the ZKP-enabled DLN), etc.

[0020] In some embodiments, a method includes storing data associated with a set of asset shares from a homogenous set of assets in a first instance of a distributed ledger database at a transaction initiating communication device. The method includes dividing the homogenous token set into a first set of homogenous token groups based on the data at a processor of the transaction initiating communication device. Each asset share in the set of asset shares is associated with a communication device in the first set of communication devices. The homogenous token sets collectively represent the homogenous asset set, and these representations can be stored on a distributed ledger-based network. The method includes sending each homogenous token group in the first set of homogenous token groups via a distributed ledger-based network and at least in part based on an asymmetric cryptographic key pair to a communication device that is (1) associated with that homogenous token group and (2) from the first set of communication devices, so that a second plurality of communication devices sends a non-homogeneous token set of each homogenous token group in the second set of homogenous token groups to a designated recipient communication device. The first set of homogeneous token groups is divided into a second set of homogeneous token groups and received at a second set of communication devices, the second set of communication devices being at a different level than the first set of communication devices in terms of the order of data transmission. Each non-fungible token in the set of non-fungible tokens is indivisible and is associated with (1) a transaction destination in the set of transaction destinations and (2) an identifier from the set of identifiers, the second set of communication devices not including the transaction initiating communication device.

[0021] As used herein, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, the term "transaction destination" is intended to refer to a single transaction destination or a plurality of transaction destinations. For another example, the term "token" is intended to refer to a single token or a plurality of tokens.

[0022] Figure 1A DLN is shown according to some embodiments, which is configured to establish a chain of custody of assets in a network of cascaded communication devices in the DLN and identify distinguishing characteristics of the assets, where the assets are represented on the DLN via tokens. In some embodiments, the DLN 100 includes a collection of communication devices (or computing nodes) 102a-102e, which are configured to communicate with each other via peer-to-peer (P2P) connections. In some implementations, the communication devices 102a-102e can be computing devices, including but not limited to computers, servers, processors, data / information processing machines or systems, etc., and can include data storage systems such as databases, memories (volatile and non-volatile). In some implementations, the P2P connection can be performed by utilizing wireless communication protocols or standards (such as The DLN 100 is provided by a wired and / or wireless communication system or network (not shown) such as but not limited to the Internet, an intranet, a local area network (LAN), a wide area network (WAN), etc. The DLN 100 may be a public DLN or a private (licensed) DLN.

[0023] In some embodiments, the DLN 100 may include self-executing code or smart contracts that are configured to execute when conditions agreed upon between the transaction parties are met (e.g., executing a transaction including the division and distribution of a fungible token when the conditions are met, such as but not limited to the expiration of a deadline). For example, some or all of the communication devices 102a-102e may include a copy of the self-executing code that self-executes when the conditions are met. In some implementations, the communication devices 102a-102e may communicate the results of the execution of their respective self-executing codes to each other, for example, to reach a consensus on the results. In some implementations, one or more of the communication devices 102a-102e may have the self-executing code self-execute, and the results will be transmitted to the rest of the communication devices 102a-102e for confirmation.

[0024] In some embodiments, the self-executing code or smart contract may facilitate transactions (or transfers of tokens) on the DLN 100 by providing transaction participants with confidence in the integrity of the transaction. For example, a transaction between two communication devices involving an asset may include a ZKP that proves a characteristic associated with the asset without revealing the underlying information associated with the characteristic. In such an implementation, once the ZKP is verified by the self-executing code snippet, the communication devices may have confidence in the integrity of the transaction (i.e., the fact that the characteristic associated with the asset is verified or accurate), even without access to the underlying information. As an example, the asset may be a financial instrument, and a first communication device may wish to prove an assertion about the country of residence of the owner of the financial instrument (i.e., the asset characteristic) to a second communication device without having to reveal the identity of the asset (i.e., the underlying information). Therefore, the first transaction communication device may submit a ZKP to this effect to the self-executing code snippet on the DLN 100 that supports the ZKP. After the self-executable code snippet verifies the ZKP, the second communication device can have confidence in the accuracy of the verification assertion as a result of the self-executable code snippet's verification of the proof, thereby facilitating transactions (or transfers of tokens) on the ZKP-enabled DLN 100.

[0025] In some embodiments, the DLN 100 may be linked to one or more oracles (not shown) or data feeds that provide external data to the DLN 100. In some implementations, as discussed above, self-executing code or smart contracts may be automatically executed upon fulfillment of some conditions of a transaction, and the oracle may provide data that may be used to evaluate whether the conditions are met. For example, a transaction may depend on a deadline, a stock price, weather conditions, etc., and the oracle may provide the necessary information to the smart contract to facilitate the transaction. Upon receiving the information, the smart contract may self-execute upon determining that the conditions of the transaction have been met. For example, a transaction between the transaction parties 110a, 110b, 110c may involve the transaction party 110a splitting a batch of financial instruments (e.g., dividends) into two parts and distributing the split parts to the transaction parties 110b and 110c when a condition is met (e.g., expiration of a deadline), and the smart contract may execute the transaction only when the oracle receives information that the condition is met (i.e., expiration of the deadline).

[0026] In some embodiments, at least a substantial number of the total number of communication devices 102a-102e (e.g., at least greater than 50%, 60%, 75%, 90%, including values ​​and sub-ranges therebetween, of the communication devices 102a-102e constituting the DLN 100) include a copy of the distributed ledger 104a-104e (or a distributed ledger, or an instance of the DLN), and transactions occurring on the network are recorded on the distributed ledger 104a-104e. In some implementations, when a substantial number of the communication devices 102a-102e or a subset thereof agree on the validity of the transaction, the transaction may be recorded on the distributed ledger 104a-104e. The distributed ledger 104a-104e may be immutable or nearly immutable in the sense that in order to change the distributed ledger 104a-104e, at least such a substantial portion of the communication devices 102a-102e must reach consensus, which may become increasingly difficult as the number of communication devices 102a-102e is large (and the distributed ledger 104a-104e becomes longer).

[0027] In some embodiments, the communication devices 102a-102e of the DLN 100 can transmit encrypted data messages (e.g., whisper messages) over a private or shared communication channel, where the messages are not recorded on the DLN (e.g., outside the DLN). Blockchain transactions and events are visible to all nodes. Zero-knowledge proof (ZKP) methods can obfuscate wallet addresses (or identifiers of communication devices 102a-1023), but transactions and events are "public". The whisper messaging protocol is an example of a parallel mechanism that allows private encrypted communications. The secure messaging system described herein is not limited to the whisper messaging protocol. In some implementations, messages can be "broadcast" to all nodes, but only (one or more) recipients can decode the message with the correct key. Unlike transactions and events, messages are not recorded on the DLN 100. In some implementations, after the transmission of a fungible token or a non-fungible token, the communication devices 102a-102e can use encrypted messaging to send private notifications, and the receiving communication device can then perform the next cascade action. In some implementations, some encrypted messages containing private announcements are recorded on the DLN, where only the intended recipient can decode the message with the correct decryption key (eg, a private key included in a private-public encryption key pair).

[0028] In some implementations, encrypted messages are used in part to specify a private communication channel (such as a secure REST API) where additional private information associated with a token can be transmitted outside of (or outside of) the DLN. When secure messaging is used with a private communication channel outside of the DLN, private information associated with a fungible or non-fungible token can be split between information sent via secure messaging and information sent over the private communication channel (such as a secure REST API).

[0029] Figure 2A-2C An example sequential flow chart is shown, according to some embodiments, illustrating establishing a chain of custody of assets in a network of cascaded communication devices in a distributed ledger (DLN), and identifying distinguishing characteristics of the assets, where the assets are represented on the DLN via tokens. The DLN 200 is similar to the example of the embodiment of the present invention. Figure 1 The DLN 100 described above. A collection of communication devices (or computing nodes) may be configured to communicate with each other via the DLN 200. The collection of communication devices includes a transaction initiation communication device 290, a transaction destination communication device 291a-291m, and a collection of cascade intermediate communication devices 20nm (where n=1, 2, ..., N; m=1, 2, ..., M, N and M are finite natural numbers, representing the number of layers in the cascade order and the number of entities within the layer, respectively). The transaction destination communication devices 291a-291m may be operated by the transaction destination (or a natural person or the ultimate entity of a homogeneous asset) ( Figure 2A-2C not shown).

[0030] The collection of cascaded intermediate communication devices 20nm is physically and functionally similar to the Figure 1 The communication devices 102a-102e described above are similar. In some implementations, the set of cascaded intermediate communication devices 20nm can be configured to communicate with each other via the peer connection of the DLN 200. In these implementations, the set of cascaded intermediate communication devices 20nm can be spread across various geographical locations and is not necessarily hierarchical in the network topology. The set of cascaded intermediate communication devices 20nm can be hierarchical according to the order of data transmission. In other words, the set of cascaded intermediate communication devices 20nm can be at different levels in the order of data transmission. This hierarchical structure of the set of cascaded intermediate communication devices can be dynamic and change over time.

[0031] For example, the set of cascaded intermediate communication devices 20nm may include a first plurality of communication devices 201a-201m, a second plurality of communication devices 202a-202m, and a third plurality of communication devices 20Na-20Nm. In some implementations, the transaction initiation communication device 290 and the set of cascaded intermediate communication devices 20nm may participate in the DLN 200. In some implementations, the transaction destination communication devices 291a-291m may or may not participate in the DLN 200.

[0032] In some implementations, the transaction initiation communication device 290 may possess assets associated with the transaction destination (or end entity) operating the transaction destination communication device 291a-291m. However, the transaction initiation communication device 290 may not possess information that can distinguish some or all assets from each other. For example, the transaction initiation communication device 290 may not possess information related to the relationship between the assets and the transaction destination (e.g., which assets (or portions thereof) are associated with which transaction destinations), or information related to the transaction destination (e.g., information such as, but not limited to, the identity, location, etc. of the transaction destination), etc. In such implementations, since it does not possess information that distinguishes assets from each other, the transaction initiation communication device 290 can use a fungible token representing the asset to initiate a transaction and establish (and represent on the DLN) an asset custody chain from the transaction initiation communication device 290 to the transaction destination via the network of cascaded intermediate entities 20Nm. The establishment of a chain of custody for an asset represented by a fungible token on the DLN 200 (and representation on the DLN) may allow the transaction initiating communication device 290 to discover or identify distinguishing characteristics of the asset (e.g., such as the above-mentioned information about the transaction destination and / or its relationship to the asset). The establishment of a chain of custody may also allow the network of cascading intermediary entities 20Nm and / or transaction destination communication devices 291a-291m to update their records about the asset (e.g., ownership of the asset).

[0033] In some implementations, the transaction initiating communication device 290 may possess the above information, but may still use a fungible token to represent the asset to establish (and represent on the DLN) a chain of custody of the asset from the transaction initiating communication device 290 to the transaction destination. Using a fungible token to represent the asset when establishing a chain of custody of the asset may be computationally more efficient and less burdensome to the DLN than, for example, using a non-fungible token. In some implementations, a fungible token may contain less information related to the asset than a non-fungible token. Therefore, computations performed by the DLN (e.g., by an automatically executed code snippet on the DLN) to establish a chain of custody of the asset on the DLN (compared to computations involving non-fungible tokens) may involve less processing power and / or memory space and costs of transactions on the DLN.

[0034] In some implementations, the relationship between an asset and a transaction destination may be one of ownership or other relationships (e.g., obligations, etc.). The relationship between an asset and a transaction destination may also be a rights relationship (e.g., the right to receive dividends, voting rights, etc.). In some implementations, the interest relationship between an asset and a transaction destination may be a relationship at a given point in time or when a specific event occurs. As a non-limiting illustrative example, an asset may be a security or financial instrument (e.g., dividends, capital gains, interest, etc.) issued by a security issuer (e.g., a transaction initiation communication device 290), and the transaction destination may be the owner of a security that becomes entitled to receive dividends at a specified point in time. The custody chain established by the transaction initiation communication device 290 may allow for the discovery or identification of (homogeneous) distinguishing features of financial instruments (or assets in general), including which transaction destination owns how many instruments (or assets in general).

[0035] To establish a chain of custody, in some embodiments, the transaction origination communication device 290 may initially identify the unit of the fungible asset and generate or mint a fungible token for each unit of the fungible asset using a processor (which may or may not be part of the DLN 200). The set of fungible tokens collectively represents the set of fungible assets on the DLN 200. In some implementations, the fungible token does not include any identifying information that identifies the transaction destination (or the entity that is the beneficial owner of the fungible token). For example, if the transaction origination communication device 290 is operated and / or managed by a securities issuer that declares a dividend of a given amount per share for the total number of shares issued, then the unit of the fungible asset is a single share, and the transaction origination communication device 290 (operated by the securities issuer or a related entity (such as a local custodian of the fungible asset)) may mint a fungible token for each unit of the fungible asset. In some implementations, the transaction destination (or ultimate entity) operating the transaction destination communication devices 291a-291m may be the owner or destination of all or at least a subset of the fungible assets.

[0036] After generating the fungible token, the transaction initiating communication device 290 can then divide the total number of fungible tokens in proportion to the holdings of the fungible assets of the first set 201a-201m of communication devices. In other words, the first set 201a-201m of communication devices can be part of the custody chain of the fungible assets held by the transaction initiating communication device 290 for the benefit of the transaction destination. The total number of fungible tokens can be divided into a first set of fungible token groups according to the share of the fungible assets held by each entity operating the first set 201a-201m of communication devices. For example, if the total number of fungible tokens (e.g., measured in units of assets) is T, then the total number of fungible tokens can be divided into a set of a_m=T*x_m, where x_m is the share of the fungible assets held by the first set 201a-201m of communication devices. The share of the fungible assets held by each communication device in the first set 201a-201m of communication devices can be different or the same from each other. For example, if the total number of homogenous tokens in the first set of communication devices is 1 million tokens, and the asset shares of each communication device are 50%, 10%, and 40%, respectively, then the first communication device, the second communication device, and the third communication device receive 500,000 tokens, 100,000 tokens, and 400,000 tokens. Then, the transaction initiating communication device transmits each homogenous token group (500,000 tokens, 100,000 tokens, and 400,000 tokens) to the first communication device, the second communication device, and the third communication device, respectively, via the distributed ledger network. The transaction initiating communication device 290 can then transmit each homogenous token set a_m (and / or an identifier of the transaction initiating communication device 290, an identifier of each of the first communication device, the second communication device, and the third communication device, respectively, and / or other information of the transaction initiating communication device 290) to the corresponding communication device in the first set 201a-201m of communication devices. In some implementations, the transaction initiating communication device 290 may store data associated with the shares of the fungible asset in a first instance of the distributed ledger database of the DLN 200 before partitioning the set of fungible tokens. In some implementations, when the fungible tokens are held by a single communication device, the transaction initiating communication device 290 may not partition the set of fungible tokens, but instead send the entire set of fungible tokens to that communication device.

[0037] refer to Figure 2A-2CIn the specific example in FIG. 1 , a local custodian LC1 (operating a transaction initiation communication device 290) owns one million shares of an asset belonging to the ultimate owners or investors I1 to I12 (i.e., the transaction destinations operating transaction destination communication devices 291a-291m). In order to establish a chain of custody from the local custodian LC1 to investors I1 to I12, the local custodian LC1 may mint or generate a homogenous token for each unit (i.e., share) of the homogenous asset or share. The first set of entities (the first set of operating communication devices 201a-201m) may be global custodians GC1-GC3, which are tasked with safely keeping the homogenous assets of their respective clients (such as asset managers AM, investors I, asset distributors D, etc.). The transaction initiation communication device 290 operated by the local custodian LC1 may then distribute the million homogenous tokens according to the shareholdings of the global custodians GC1-GC3 that have direct account relationships with the local custodian LC1. Since GC1 owns half of a million shares, GC2 owns one-tenth of a million shares, and GC3 owns four-tenths of a million shares, the transaction initiation communication device 290 operated by the local custodian LC1 can divide the fungible tokens into three sets: half of a million tokens, one-tenth of a million tokens, and four-tenths of a million tokens. The transaction initiation communication device 290 operated by the local custodian LC1 can transfer each set of tokens from the first set of communication devices operated by the global custodian to a corresponding communication device. In some implementations, when a first party has a direct account relationship with a second party, the first party has identification information of the second party, and / or the second party has established an account with the first party, so that the first party can transfer tokens directly to the second party without an intermediary.

[0038] In some implementations, communication devices (between a collection of cascaded intermediate communication devices 20nm or between a transaction initiating communication device 290 and a collection of cascaded intermediate communication devices 20nm) communicate with each other using a secure messaging protocol. Specifically, a communication device (a transaction initiating communication device 290 or a collection of cascaded intermediate communication devices 20nm) can send (or broadcast) a message to each node or communication device on the DLN 200. In some implementations, a communication device (a transaction initiating communication device 290 or a collection of cascaded intermediate communication devices 20nm) can send (or broadcast) a message to its neighboring communication devices or nodes on the DLN 200. All communication devices continuously forward the message to their neighboring communication devices until the intended receiving communication device receives it. However, only the intended receiving communication device has the key to decrypt the message. In some implementations, a message may include, but is not limited to: (1) a message identifier, (2) a subject of the message, (3) a message body, (4) a "to" field: a recipient identifier, (5) a "sender" field: an identifier of the sending communication device, (6) a message status field, indicating whether the message has been received by the intended receiving communication device, or whether the sending communication device has received a confirmation message from the receiving communication device, etc. For example, when a transaction initiating communication device 290 (operated by LC1) transfers a set of homogenous tokens to a communication device in the first set of communication devices (e.g., 201a operated by GC1), the transaction initiating communication device 290 may broadcast the message (using the homogenous token) to all of its neighboring communication devices. However, only communication device 201a (operated by GC1) has the key to decrypt the message and receive the homogenous token.

[0039] A communication device including a sending communication device and a receiving communication device (a collection of a transaction initiating communication device 290 or a cascaded intermediate communication device 20nm) can periodically check the message status in a local database. When the sending communication device does not receive a confirmation message from the receiving communication device, the sending communication device can resend the message. A communication device including a sending communication device and a receiving communication device (a collection of a transaction initiating communication device 290 or a cascaded intermediate communication device 20nm) can listen to all confirmation messages. Once a confirmation message is received, the communication device can update its message status field. After the sending communication device sends the message and the receiving communication device receives the message, the receiving communication device can check whether the message exists in its database (based on the message identifier). If the message is a new message, the receiving communication device can start an action based on the message (e.g., further divide the homogenous token, transfer the homogenous token to the next communication device, or record the homogenous token in its database, etc.). If the message does not exist in its database, the receiving communication device can also update its message status field. The receiving communication device can send a confirmation message back to the sending receiving communication device. When the sending and receiving communication devices receive the confirmation message, the receiving communication device may update the confirmation status in its database. In some implementations, the confirmation message may include, but is not limited to, (1) a message identifier, (2) a subject of the message, and the like.

[0040] In some implementations, the establishment and representation of the chain of custody of assets on the DLN from the transaction initiating communication device 290 to the transaction destination via the network of cascaded intermediate entities 20nm can be repeated as described above until all homogenous tokens generated by the transaction initiating communication device 290 are distributed to the last set of communication devices 20Na-20Nm according to the asset holding shares of the last set of entities operating the last set of communication devices 20Na-20Nm. Each time a homogenous token is transferred from a sending communication device to a receiving communication device, the identifiers of the sending communication device and the receiving communication device can be recorded in the distributed ledger database of the DLN so that a chain of custody of the homogenous token can be established.

[0041] For example, after a communication device in the first set 201a-201m of communication devices receives its corresponding homogeneous token group (from the first set of homogeneous token groups), the first set 201a-201m of communication devices may divide the first set of homogeneous token groups into a second set of homogeneous tokens based on the share of homogeneous assets held by each entity operating the second set 202a-202m of communication devices. The first set 201a-201m of communication devices may transfer each homogeneous token group from the second set of homogeneous tokens to a corresponding communication device in the third set 203a-203m of homogeneous tokens. When all homogeneous tokens generated by the transaction initiating communication device 290 are distributed to the last set 20Na-20Nm of communication devices, the last set 20Na-20Nm of communication devices may divide the homogeneous tokens into the last set of homogeneous token groups based on the share of homogeneous assets held by each transaction destination operating the transaction destination communication devices 291a-291m. In some implementations, the last set 20Na-20Nm of communication devices may transfer the last set of homogenous token groups to a corresponding communication device in the set 291a-291m of transaction destination communication devices. In other implementations, the last set 20Na-20Nm of communication devices may have a direct account relationship with the transaction destination. The last set 20Na-20Nm of communication devices may record the transfer of the last set of homogenous token groups in the account of the transaction destination, and save the last set of homogenous token groups in the last set 20Na-20Nm of communication devices without transferring them to the transaction destination communication devices 291a-291m. The direct account relationship between the transaction destination and the last set 20Na-20Nm of communication devices includes: (1) each communication device in the last set 20Na-20Nm of communication devices includes an identifier of the transaction destination; and (2) the homogenous token may be directly transferred to the transaction destination communication device associated with that transaction destination based on the identifier. In some implementations, when a communication device (a transaction initiating communication device 290 or any communication device in a set of cascaded intermediate communication devices 20nm) transfers to another communication device (any communication device in a set of cascaded intermediate communication devices 20nm), the sending communication device may send an identifier of the sending communication device and an identifier of the receiving communication device together with the homogenized token.

[0042] In some implementations, based on the share of homogenous assets held by each communication device, some communication devices in the set of cascaded intermediate communication devices 20nm may not divide their homogenous tokens and send the entire set of homogenous tokens to another (multiple) communication device. In some implementations, based on the share of homogenous assets held by each communication device, more than one communication device in the set of cascaded intermediate communication devices may combine their homogenous tokens and send the combined homogenous tokens to another (multiple) communication device. In other words, not every communication device in the set of cascaded intermediate communication devices 20nm divides its homogenous tokens in each distribution event.

[0043] refer to Figure 2A-2C In a specific example embodiment of the invention, the communication device 201a operated by the global custodian GC1 may divide half of the received one million tokens in proportion to the shareholdings of the asset managers (AMs) who have a direct account relationship with the global custodian GC1. In other words, the communication device 201a operated by the global custodian GC1 may divide half of the one million tokens into one set of two hundred thousand tokens and two sets of one hundred and fifty thousand tokens based on the respective shares of the assets or shareholdings of the asset managers, and transfer the sets of tokens to the communication devices 202a-202m operated by AM1, AM2 and AM3 respectively. The communication device 201b operated by GC2 may transfer one hundred thousand tokens from the network of the cascaded intermediate entity 20nm having a direct account relationship with GC2 to the communication device 20Ni (i.e., to the distributor D8). In this way, all homogenized tokens generated by the transaction initiation communication device 290 are distributed to the last set of communication devices 20nm (or generally speaking, to the communication devices in the set of cascaded intermediate communication devices 20nm that have a direct account relationship with the transaction destination of the operating transaction destination communication devices 291a-291m). In this example, the communication device 201c from the first set of communication devices and operated by the global custodian GC3 is also a communication device in the last set 20Nm of communication devices. The communication device 201c operated by GC3 has a direct account relationship with the transaction initiation communication device 290 and the transaction destination communication device 291l. In this example, the communication devices in the set of cascaded intermediate communication devices 20nm that have a direct account relationship with the transaction destination of the operating transaction destination communication devices 291a-291m include the last set of communication devices 20nm and the communication device 201c (also referred to as the last set 20Nm of communication devices).

[0044] In some embodiments, a set of cascaded intermediate communication devices 20nm may be configured to communicate with each other via a peer connection of the DLN 200. The set of cascaded intermediate communication devices 20nm may be spread across different geographical locations and not hierarchical in network topology (or physical connection). In some implementations, the set of cascaded intermediate communication devices 20nm may be hierarchical in the order of data transmission. In other words, in the order of transmitting data between the set of cascaded intermediate communication devices 20nm, the cascaded communication devices 20nm within the set of cascaded intermediate communication devices 20nm may be at different levels. This hierarchical structure of the set of cascaded intermediate communication devices may be dynamic and change over time. In other words, the communication devices in the set of cascaded intermediate communication devices 20nm may be at the first level at the first time and at the second level at the second time. This hierarchical structure of the set of cascaded intermediate communication devices may be implicit in (or inferred from) the distribution and segmentation mode of homogeneous tokens, which may include, for example, lateral transfer (i.e., transfer of homogeneous tokens within the same level of communication devices) or bypassing the communication devices in the set of cascaded intermediate communication devices.

[0045] In some implementations, each time a homogenous asset is distributed to a transaction destination (e.g., a distribution event or a dividend event), the pattern of distributing and subdividing the homogenous tokens (or the order of data transfer) can track different patterns (or pathways) through the set of cascaded intermediate communication devices 20nm of the peer-to-peer network DLN200, from which the hierarchical structure of token transfers (and therefore the chain of custody of the set of homogenous assets) can be inferred. For the distribution and division of different sets of homogenous assets, the track (or pattern, or pathway) may follow exactly the same path as the set of cascaded intermediate communication devices 20nm (reflecting the business relationship between the entities), or the track (or pattern) may be significantly different from one distribution event to another. In other words, for different distribution events of different sets of homogenous assets, for example, the communication devices in the set of cascaded intermediate communication devices 20nm may not be involved in a given distribution event and are therefore skipped, and the entirety of the communication devices at one level may not participate in a given distribution event and are therefore skipped. The track (or pattern or pathway) through the set of cascaded intermediate communication devices 20nm can be completely reversed due to different distribution events. In other words, the trajectory (or pattern or path) through the set of cascaded intermediate communication devices 20 nm can be any pattern.

[0046] For example, the path of the distribution event of the homogenous token may include a diamond pattern. Specifically, the first communication device in the set of cascaded intermediate communication devices 20nm may divide the homogenous token into a first set of homogenous tokens, a second set of homogenous tokens, and a third set of homogenous tokens. The first communication device may send the first set of homogenous tokens and the second set of homogenous tokens to the second communication device in the set of cascaded intermediate communication devices 20nm and the third communication device in the set of cascaded intermediate communication devices 20nm, respectively. Subsequently, the second communication device and the third communication device may send the first set of homogenous tokens and the second set of homogenous tokens to the fourth communication device in the set of cascaded intermediate communication devices 20nm. The first communication device may send the third set of homogenous tokens to the fourth communication device without passing through the cascaded intermediate communication device.

[0047] For another example, the path of the distribution event of the homogenous token can be a circular "loop" relationship between communication devices. Specifically, the first communication device in the set of cascaded intermediate communication devices 20nm can send a first set of homogenous tokens to the second communication device in the set of cascaded intermediate communication devices 20nm. The first communication device can send a second set of homogenous tokens to a third communication device in the set of cascaded intermediate communication devices 20nm. The second communication device can divide the first set of homogenous tokens into a third set of homogenous tokens and a fourth set of homogenous tokens. The second communication device can send the third set of homogenous tokens back to the first communication device, and the first communication device then divides the third set of homogenous tokens. For example, during the cascading process, a shareholder identified as being at a "lower" level may be a fund (or other type of collective investment vehicle) holding securities shares, while the financial entity holding the accounting of the fund may be at a "higher" level.

[0048] In some implementations, the communication devices in the set of cascaded intermediate communication devices 20nm may be operated by a parent entity and its subordinate entities. Thus, the same communication device may appear multiple times in different levels of the path of the distribution event.

[0049] In some implementations, when all fungible tokens are distributed to intermediary communication devices that have a direct account relationship with the transaction destination, these intermediary communication devices (i.e., reference Figure 2AIn the example in FIG. 1 , the last set of communication devices 20Nm and communication device 201c) can continue to convert the homogenous token into a non-homogeneous token by combining the identification characteristics or information of the transaction destination (or final entity) known to the intermediate entity. In some implementations, these intermediate communication devices (i.e., the last set of communication devices 20Nm and communication device 201c) can generate a new non-homogeneous token including the identification characteristics or information instead of converting the homogenous token into a non-homogeneous token.

[0050] In some implementations, these intermediate communication devices may generate (or convert fungible tokens into) non-fungible tokens, each of which includes (1) an identifier of a transaction destination, (2) an identifier of a communication device (among these intermediate communication devices) that generates (or converts from) the non-fungible token, (3) an identifier of a communication device in a set of cascaded intermediate communication devices 20nm that transfers any fungible token in a set of fungible tokens associated with that non-fungible token, and / or (4) a “value” parameter representing the number of fungible tokens associated with that transaction destination. In other words, the number of fungible tokens may be represented as a “value” parameter of a non-fungible token, but the non-fungible token does not include the associated fungible token. Thus, a chain of custody for each fungible token may be established based on a single non-fungible token of a given transaction destination communication device and the information contained in the non-fungible token (e.g., based on (1) an identifier of the transaction destination, (2) an identifier of the communication device (of these intermediate communication devices) that generated (or converted from the fungible token), and / or (3) an identifier of a communication device in a set of cascaded intermediate communication devices 20nm that transferred any fungible token in the set of fungible tokens associated with that non-fungible token). In some implementations, the non-fungible token may include other data fields associated with the transaction destination or characteristic information associated with the transaction destination (e.g., the name of the transaction destination, the location of the transaction destination, the country of residence, the type of entity of the transaction destination (e.g., a company, pension fund, natural person, etc.), etc.). In some implementations, the chain of custody may start from the transaction initiating communication device and end at a communication device that has a direct account relationship with the transaction destination (or a communication device of these intermediate communication devices that generated or converted the non-fungible token from the fungible token).

[0051] For example, the last set of communication devices 20Nm that have a direct account relationship with the transaction destination may have access to identification or distinguishing characteristics of the transaction destination, such as, but not limited to, the identity of the transaction destination, the location (residence) of the transaction destination, etc. The last set of communication devices 20Nm may then transfer or send the non-fungible token to the transaction initiating communication device 290 (e.g., Figure 2B). By using non-fungible tokens, the communication device 290 initiating the transaction can then identify or reveal distinguishing characteristics of the fungible asset, examples of which include ownership (e.g., the identity of the asset owner) and details related to ownership (e.g., the owner's residence or location, etc.).

[0052] In some implementations, upon receiving a non-fungible token, the transaction initiating communication device 290 may be based on the information contained in each non-fungible token (e.g., the value parameter of the non-fungible token; or the first value) and the algorithm. Each non-fungible token in the non-fungible token set corresponds to a second value (or a derived value) in the value set (or a derived value set). The transaction initiating communication device 290 may record the second value in the value set with the non-fungible token in the non-fungible token set (and store it locally in the transaction initiating communication device 290 and / or the distributed ledger database) as the second value parameter associated with that non-fungible token. In some implementations, the transaction initiating communication device 290 may calculate the difference between the value parameter (or the first value) of the non-fungible token and the second value associated with the non-fungible token, and record it as a third value associated with the non-fungible token (and store it locally in the transaction initiating communication device 290 and / or the distributed ledger database). The third value associated with that non-fungible token is associated with a subset of homogeneous tokens. The transaction initiating communication device 290 may send the non-fungible token, the second value associated with that non-fungible token, and the third value to a communication device in one or more intermediate communication devices that have a direct account relationship with the transaction destination, so that the communication device can record these values ​​with the account of the transaction destination (and store them locally in the intermediate communication device and / or distributed ledger database). In some implementations, the transaction initiating communication device 290 may send the non-fungible token, the second value associated with the non-fungible token, and the third value to a communication device in one or more intermediate communication devices that have a direct account relationship with the transaction destination. The transaction initiating communication device 290 may send the second value associated with that non-fungible token to a different entity on behalf of the transaction destination. In these implementations, the transaction destination is entitled to a number of homogeneous tokens equal to the third value of the non-fungible token. A number of homogeneous tokens equal to a third value of a non-homogeneous token are a subset of homogeneous tokens equal to a first value of the non-homogeneous token.

[0053] For example, the transaction initiating communication device 290 may calculate the withholding tax (i.e., the second value) based on the number of shares (the "value" parameter of the non-fungible token) and the withholding tax (i.e., the second value) may vary based on other information contained in the non-fungible token, such as the country of residence of the transaction destination and the type of transaction destination (e.g., company, pension fund, natural person, etc.). In the event of a dividend, the second value (or a derived value) may determine the net amount of the dividend that should be distributed to the transaction destination (or ultimate entity) and the total amount of withholding tax that may be remitted to the tax authorities.

[0054] In some implementations, the transaction initiating communication device 290 may store data associated with the set of non-fungible tokens and the set of fungible tokens in a second instance of the distributed ledger database. For each non-fungible token in the set of non-fungible tokens, the data associated with that non-fungible token may include (1) an identifier of the transaction destination, (2) an identifier of the communication device (among these intermediate communication devices) that generated (or converted from the fungible token), (3) an identifier of a communication device in the set of cascaded intermediate communication devices 20nm that transferred any fungible token in the set of fungible tokens associated with that non-fungible token, (4) a "value" parameter representing the number of fungible tokens associated with that transaction destination, and / or (5) a second value (or a derived value) calculated based on the value of the non-fungible token.

[0055] The second instance of the distributed ledger database may be replicated, shared, synchronized, and transportable between multiple communication devices in the set of cascaded intermediate communication devices 20nm of the DLN 200. The chain of custody of the fungible token may be established and represented via the second instance of the distributed ledger database of the DLN 200.

[0056] In some embodiments, the transaction destination (or the ultimate entity or owner of the fungible asset) may have a connection with an intermediate communication device (i.e., a reference Figure 2A The last set of communication devices in the example 201a-291m and communication device 201c) accounts and the transfer of the token is recorded by these intermediate communication devices (the upper level of the transaction destination communication devices 291a-291m) via the DLN 200. The transaction destination communication devices 291a-291m may not participate in the DLN 200.

[0057] Figure 2C A method of establishing a chain of custody of assets in a network of cascading communication devices in a distributed ledger based network (DLN) and identifying distinguishing features of the assets is shown. Figure 2B An alternative embodiment to the embodiment described in , where assets are represented on the DLN via tokens. Figure 2BAs described, the non-fungible token is sent to the transaction initiating communication device 290, and the last set of communication devices 20Nm can transmit or send the non-fungible token to the designated recipient communication device 299. In these implementations, the designated recipient communication device 299 can be different from the transaction initiating communication device 290. The designated recipient communication device 299 can be any communication device (or node) on the DLN 200. By using the non-fungible token, the designated recipient communication device 299 can then identify or reveal the distinguishing characteristics of the fungible asset, examples of which include ownership (e.g., the identity of the owner of the asset) and details related to ownership (e.g., the owner's residence or location, etc.).

[0058] In some implementations, similar to Figure 2B The process and method described above performed by the transaction initiating communication device 290, upon receiving a non-fungible token, the designated recipient communication device 299 may determine a second value (or, a derived value) based on the information contained in each non-fungible token (e.g., a value parameter of the non-fungible token; or a first value) and an algorithm. The designated recipient communication device 299 may record the second value in the value set together with the non-fungible token in the non-fungible token set (and store it locally in the transaction initiating communication device 290 and / or in a distributed ledger database) as a second value parameter associated with that non-fungible token. In some implementations, the designated recipient communication device 299 may calculate and record a third value (and store it locally in the designated recipient communication device 299 and / or in a distributed ledger database). The designated recipient communication device 299 may send a non-fungible token, a second value associated with that non-fungible token, and / or a third value to a communication device in (one or more) intermediate communication devices that have a direct account relationship with the transaction destination, so that the communication device may record these values ​​with the account of the transaction destination (and store them locally on the intermediate communication device and / or in the distributed ledger database). The designated recipient communication device 299 may send the second value associated with that non-fungible token to a different entity on behalf of the transaction destination. In some implementations, the designated recipient communication device 299 may store data associated with a set of non-fungible tokens and a set of homogenous tokens in a second instance of a distributed ledger database. The second instance of the distributed ledger database may be replicated, shared, synchronized, and transmitted between multiple communication devices in a set of cascaded intermediate communication devices 20nm of the DLN 200. The chain of custody of the homogenous token may be established and represented via the second instance of the distributed ledger database of the DLN 200.

[0059] For example, the designated recipient communication device 299 can calculate the withholding tax (e.g., the second value) based on the number of shares (the "value" parameter of the non-fungible token), and the withholding tax (i.e., the second value) can vary based on other information contained in the non-fungible token, such as the country of residence of the transaction destination and the type of transaction destination (e.g., company, pension fund, natural person, etc.). In a dividend event, the second value (or derived value) can determine the net amount of dividends that should be distributed to the transaction destination (or ultimate entity) and the total amount of withholding tax that can be remitted to the tax authorities. In some implementations, the designated recipient (operating the designated recipient communication device 299) can be announced when the dividend event is announced so that all participants (communication devices on the DLN 200) can send non-fungible tokens to the designated recipient communication device 299. Alternatively, the transaction initiating communication device 290 can receive non-fungible tokens and then send them to the designated recipient communication device 299. In the event of a dividend, the designated recipient (operating the designated recipient communication device 299) may be referred to as a "withholding tax agent" (or WHT agent). In different countries, the role of the withholding tax agent may be performed by different entities in the market. In some countries, the local custodian is the withholding tax agent, but in other countries, a different actor is the withholding tax agent.

[0060] Back to Figure 2A In some embodiments, the privacy and confidentiality of the establishment and representation of the asset custody chain can be enhanced by using zero-knowledge proofs. In some embodiments, the set of homogenous tokens a_m can be transferred from the transaction initiating communication device 290 to the corresponding communication devices in the first set of communication devices 201a-201m via a homogenous token commitment calculated using the following: Where P transferor is the public key associated with the transaction initiating communication device 290 (i.e., the transferor of the token) on the DLN 100, S a_m is a random number, H is a cryptographic hash function or algorithm (e.g., SHA-256), and Represents a combination operator (for example, the concatenation operator |, etc.). transferor Can be DLN 200 (or about Figure 1 The public key of the asymmetric cryptographic key pair associated with the transaction initiating communication device 290 on the DLN 100 described above. a_m represents a homogeneous token set a_m on the DLN, where the ownership of the homogeneous token commitment (and the homogeneous token set a_m) is assigned to the transaction initiating communication device 290 as a token in the casting or generation of the homogeneous token commitment Z a_m The result of using the public key of the transaction initiating communication device 290 on the DLN 200. In some implementations, the token commitment Za_m The calculation can include dividing S a_m , P transferor and / or additional elements in addition to or in place of a_m. In some embodiments, the token commitment includes a random number (e.g., a secure and randomly generated serial number), a public identifier of the transaction initiating communication device 290 on the DLN (e.g., a public key of an asymmetric cryptographic key pair of the transaction initiating communication device 290), and the number or value of the token (e.g., a_m). In some implementations, when calculating the token commitment Z a_m The application of a hash function in allows the generation or minting of token commitments without revealing the random number S a_m 、Public key P transferor That is, even when the transaction initiating communication device 290 generates Z using its public account on the DLN a_m When the random number S a_m 、Public key P transferor and / or token a_m, the amount or value of the token may also be in DLN 200 (or about Figure 1 In some implementations, the token commitment Z a_m The information itself may also be private or confidential, i.e., not disclosed in the DLN 200 (or in relation to the Figure 1 In some implementations, the token commitment Z a_m The generation or minting of can be done off-chain (i.e., outside the DLN). In some implementations, by using a homogenous token commitment calculation method And based on the public identifier of the transferor of the homogenous token and the amount or value of the transferred token, the zero-knowledge proof method can be used for any transfer of the homogenous token within the set of cascaded intermediate communication devices 20nm.

[0061] refer to Figure 2A In some implementations, the transfer of the fungible token set a_m from the transaction initiating communication device 290 to the corresponding communication devices in the first set 201a-201m of communication devices can be completed on the DLN by generating a new fungible token commitment that assigns ownership of the fungible token set a_m to the corresponding communication devices in the first set 201a-201m of communication devices. It can be performed together with the invalidation or invalidation of the existing token commitment that assigns ownership of the fungible token a_m to the transaction initiating communication device 290. This new fungible token commitment that assigns ownership of each fungible token set a_m to the corresponding communication device in the first set 201a-201m of communication devices can be generated by the transaction initiating communication device 290 using a processor as follows: where S′ a_m is a random number and P 201mis the public key (eg, the public key of an asymmetric encryption key pair) of the corresponding communication device in the first set of communication devices 201a-201m on the DLN 200. a_m Invalid null character N a_m Can be used to generate Z a_m The hash function is applied to the random number to calculate. For example, the transaction initiating communication device 290 can use the processor to calculate the invalid symbol N as follows a_m :N a_m =H(S a_m ⊕V transferor ), where V transferor It includes the public key P transferor The private key in the private key-public key pair (i.e., asymmetric encryption key pair). a_m When included in the invalidation symbol data structure of DLN, the existing token commitment Z a_m In other words, the invalid symbol N in the invalid symbol data structure of DLN a_m The existence of Z can be regarded as a token commitment a_m Instructions that are no longer valid.

[0062] In some implementations, the transaction initiating communication device 290 submits a token commitment Z to a self-executable code snippet on the DLN. a_m and Z′ a_m 、Invalid character N a_m and includes each Z′ a_m After verifying the ZKP including the proof of the corresponding homogeneous token of the homogeneous token set a_m, the transfer of the homogeneous token set a_m from the transaction initiating communication device 290 to the corresponding communication device in the first set of communication devices 201a-201m can be effective. After verifying the ZKP by the self-executing code snippet, in some implementations, Z′ a_m A token commitment data structure may be added to the DLN to confirm that a homogenous token set a_m has been transferred from the transaction initiating communication device 290 to a corresponding communication device in the first 201a-201m of the communication devices.

[0063] In some implementations, the establishment and representation of the asset custody chain from the transaction initiating communication device 290 to the transaction destination via the set of cascaded intermediate communication devices 20nm can be repeated as disclosed above until the token commitment for each communication device in the last set 291a-291m of communication devices in the set of cascaded intermediate communication devices 20nm is added to the token commitment data structure of the DLN (or generally, the token commitment of each communication device that has a direct account relationship with the transaction destination is added to the token commitment data structure of the DLN). For example, referring to Figure 2A-2BIn a specific example embodiment of the present invention, the communication device 201a operated by the global custodian GC1 may divide half of the received one million tokens in proportion to the shareholdings of the asset managers (AMs) (i.e., AM1, AM2, and AM3) that have direct account relationships with the global custodian CG1. That is, the communication device 201a operated by the global custodian GC1 may divide half of the one million tokens into one set of two hundred thousand tokens and two sets of one hundred and fifty thousand tokens based on the respective shares of the assets or shareholdings of the asset managers (AMs). The communication device 201a operated by the global custodian GC1 may then proceed to generate new token commitments as discussed above to transfer the sets of tokens to AM1, AM2, and AM3, generating an invalidator to invalidate or invalidate the token commitment transferred to GC1 from the transaction initiation communication device 290 operated by LC1 (so that GC's ownership of half of the one million tokens is no longer valid). The communication device 201a may submit new token commitments to the self-executable code snippet on the DLN to add the new token commitments to the token commitment data structure of the DLN (e.g., confirming that ownership of three sets of tokens belongs to AM1, AM2, and AM3, respectively). The communication device 201a operated by the global custodian GC1 may generate each new token commitment by applying a hash function H to each of the corresponding token sets of AM1, AM2, and AM3 and the corresponding public keys on the DLN, etc., indicating that ownership of the token sets has been transferred to the corresponding asset manager. When submitting new token commitments, the communication device 201a operated by the global custodian GC1 may also submit to the self-executable code snippet the ZKP that the communication device 201a generated each new token commitment, etc., by applying the hash function H to the corresponding token sets, etc. to be transferred to the corresponding communication devices 202a-202m operated by the asset manager. In this way, all homogenized tokens generated by the transaction initiating communication device 290 are distributed to the communication devices in the last set 20Nm of communication devices (or generally speaking, to the communication devices in the set of cascaded intermediate communication devices 20nm that have a direct account relationship with the transaction destination).

[0064] Once all homogenous tokens are distributed to the intermediary communication devices in the set of 20nm cascaded intermediary communication devices that have a direct account relationship with the transaction destination, the intermediary communication device ( Figure 2AThe communication devices 201m and 201c in the example can then proceed to generate and transfer a non-fungible token to the transaction initiating communication device 290 or the designated recipient communication device 299, which non-fungible token combines the identification characteristics or information of the transaction destination known to the intermediate entity. For example, an intermediate communication device that has a direct account relationship with the transaction destination can access the identification or distinguishing characteristics of the transaction destination, such as but not limited to the identity of the transaction destination, the location of the transaction destination (e.g., place of residence), etc. Therefore, the intermediate communication device can generate a non-fungible token that includes the identification characteristics or information of the transaction destination. Such a non-fungible token may also include any information contained in the homogenous token. The intermediate communication device can then transmit or send the non-fungible token to the transaction initiating communication device 290 (e.g., Figure 2B ) or a designated recipient communication device 299 (e.g., Figure 2C ). As discussed above, the intermediary communication device can generate a new token commitment and use ZKP to prove the identity of the transaction destination without disclosing any identifying information. Therefore, as discussed above, the use of fungible and non-fungible tokens can allow for the disclosure or identification of distinguishing characteristics of otherwise fungible assets, examples of which include ownership of the asset (e.g., the identity of the owner of the asset) and details related to the ownership of the asset (e.g., the owner's place of residence or location, etc.).

[0065] Figure 3 A flow chart illustrating a method for establishing a chain of custody of assets in a network of cascaded communication devices in a DLN according to some embodiments is shown. The method 300 may be performed, for example, in a distributed ledger-based network (DLN) of multiple communication devices such as Figure 1 The method is executed at a processor of a communication device 102a-102e). Figure 2A-2B In certain example embodiments, the method 300 may be executed at a processor of the transaction initiating communication device 290 .

[0066] At step 301, a processor at a transaction initiating communication device may store data associated with a set of asset shares from a set of homogenous assets in a first instance of a distributed ledger database. Examples of such homogenous assets include financial instruments (e.g., dividends, interest payments, capital gains, etc.), legal digital assets (e.g., digital RMB, excluding prohibited virtual currencies), physical objects, etc. In some implementations, homogenous tokens represent interchangeable or indistinguishable assets. Homogenous tokens may be of the same type and may be aggregated and / or split. Examples of homogenous tokens include, but are not limited to, amounts of financial instruments, legal tender, stocks, wages, reams of paper, etc. Non-homogeneous tokens represent uniquely identifiable or distinguishable assets. Non-homogeneous tokens may have a unique identifier or serial number. In some implementations, the transaction initiating communication device may be operated by an issuer. The transaction initiating communication device is configured to communicate with a collection of cascaded intermediate communication devices (e.g., Figure 2A-2B 20 nm) in a first set of communication devices (e.g., Figure 2A-2B The transaction initiating communication device stores data associated with the homogenized asset share of each communication device in the first set of communication devices in a first instance of the distributed ledger database. For example, the transaction initiating communication device is configured to distribute and establish a chain of custody for one million tokens. The chain of custody for one million tokens begins at the transaction initiating communication device and ends at the transaction destination ( Figure 2A-2B The operation in the transaction destination communication device 291a-291m) is ended. In some implementations, the relationship between the token (or asset) and the transaction destination can be one of ownership or others (e.g., obligations, etc.). The relationship between the token (or asset) and the transaction destination can also be a rights relationship (e.g., the right to obtain dividends, voting rights, etc.). In this example, the first communication device in the first set of communication devices receives 50% of the share of one million tokens, the second communication device in the first set of communication devices receives 10% of the share of one million tokens, and the third communication device in the first set of communication devices receives 40% of the share of one million tokens. The processor at the transaction initiating communication device stores each share in the share set and the identifier of the communication device associated with the share in the identifier set in the first instance of the distributed ledger database.

[0067] At step 303, a processor at a transaction initiating communication device divides a set of homogenous tokens into a first set of homogenous token groups based on the data. Each asset share in the set of asset shares is associated with a communication device in the first set of communication devices. The processor at the transaction initiating communication device identifies units of homogenous assets and generates or mints homogenous tokens for each unit of homogenous assets. The set of homogenous tokens collectively represents a set of homogenous assets on the DLN. After generating the homogenous tokens, the processor at the transaction initiating communication device divides the total number of homogenous tokens in proportion to the homogenous asset holdings of the first set of communication devices. In other words, the first set of communication devices can be part of a chain of custody of homogenous assets held by the transaction initiating communication device for the benefit of the transaction destination. The total number of homogenous tokens can be divided into the first set of homogenous token groups according to the homogenous asset shares held by each entity operating the first set of communication devices. For example, if the total number of homogenous tokens is one million tokens and the asset shares of each communication device in the first set of communication devices are 50%, 10%, and 40%, respectively, then the first communication device, the second communication device, and the third communication device receive 500,000 tokens, 100,000 tokens, and 400,000 tokens. Then, the transaction initiating communication device transfers each homogenous token group (500,000 tokens, 100,000 tokens, and 400,000 tokens) to the first communication device, the second communication device, and the third communication device, respectively, via the distributed ledger network.

[0068] At step 305, a processor at a transaction initiating communication device sends each of the first set of homogeneous token groups to a communication device that is (1) associated with that homogeneous token group and (2) from the first set of communication devices via a distributed ledger-based network and based at least in part on an asymmetric encryption key pair. In some embodiments, the privacy and confidentiality of the establishment and representation of the asset custody chain can be enhanced by using zero-knowledge proofs (ZKPs). The homogeneous token set a_m can be transferred from the transaction initiating communication device to a corresponding communication device in the first set of communication devices via a homogeneous token commitment calculated using: Where P transferor is the public key associated with the transaction initiating communication device (i.e., the transferor of the token) on the DLN. a_m is a random number, H is a cryptographic hash function or algorithm (e.g., SHA-256), and Represents a combination operator (for example, the concatenation operator |, etc.). transferor It can be the public key of the asymmetric encryption key pair associated with the transaction initiating communication device on the DLN. a_mRepresents a set of homogeneous tokens a_m on DLN, where the ownership of the homogeneous token commitment (and the set of homogeneous tokens a_m) is assigned to the transaction initiating communication device as the owner of the homogeneous token commitment Z in minting or generating the homogeneous token commitment Z a_m The result of using the public key of the transaction initiating communication device on the DLN. In some implementations, the token commitment Z a_m The calculation can include dividing S a_m , P transferor and / or additional elements in addition to or in place of a_m. In some embodiments, the token commitment includes a random number (e.g., a secure and randomly generated serial number), a public identifier of the transaction initiating communication device on the DLN (e.g., a public key of an asymmetric encryption key pair of the transaction initiating communication device), and the number or value of the token (e.g., a_m). In some implementations, when calculating the token commitment Z a_m The application of a hash function in allows the generation or minting of token commitments without revealing the random number S a_m 、Public key P transferor And / or the identity of the token a_m. That is, even when the transaction initiating communication device uses its public account on the DLN to generate Z a_m When the random number S a_m 、Public key P transferor and / or token a_m, the amount or value of the token may also be kept secret on the DLN. In some implementations, the token commitment Z a_m The token Z itself may also be private or secret, i.e., not publicly revealed on the DLN. In some implementations, the token commitment Z a_m The generation or minting of can be done off-chain (i.e., outside the DLN). In some implementations, by using a homogenous token commitment calculation method And based on the public identifier of the transferor of the homogenous token and the amount or value of the transferred token, the zero-knowledge proof method can be used for any transfer of the homogenous token within a set of cascaded intermediate communication devices.

[0069] After receiving the first set of homogeneous token groups, each communication device in the first set of communication devices retrieves data associated with the second set of communication devices' holdings of the first set of homogeneous token groups from the distributed ledger database. For example, a fourth communication device in the second set of communication devices, a fifth communication device in the second set of communication devices, and a sixth communication device in the second set of communication devices receive 40%, 30%, and 30% shares of the homogeneous tokens (e.g., 500,000 tokens) received by the first communication device in the first set of communication devices, respectively. The first communication device transfers 200,000 tokens, 150,000 tokens, and 150,000 tokens to the fourth communication device, the fifth communication device, and the sixth communication device, respectively. The second communication device in the first set of communication devices sends 100% of its tokens to the seventh communication device in the second set of communication devices. Therefore, the seventh communication device receives 100,000 tokens. The third communication device in the first set of communication devices (e.g., Figure 2A 201c) is also in the last set of communication devices, so the third communication device will retain its 400,000 tokens and record the transaction destination (e.g., Figure 2A 291l) is entitled to 400,000 tokens. When transferring tokens (or recording the destination of a transaction), each communication device stores the number of tokens transferred, the identifier of the communication device that sent the tokens, and the identifier of the communication device that received the tokens.

[0070] In some implementations, a set of cascaded intermediate communication devices may be configured to communicate with each other via a peer-to-peer connection of a DLN. The set of cascaded intermediate communication devices may be spread across various geographic locations and need not be hierarchical in the network topology (or physical connection). In some implementations, the set of cascaded intermediate communication devices may be hierarchical in the order of data transmission. In other words, the set of cascaded intermediate communication devices may be at different levels in the order in which data is transmitted between the set of cascaded intermediate communication devices. This hierarchical structure of the set of cascaded intermediate communication devices may be dynamic and change over time. In other words, the communication devices in the set of cascaded intermediate communication devices may be at a first level at a first time and at a second level at a second time. This hierarchical structure of the set of cascaded intermediate communication devices may be implicit in (or inferred from) the pattern of distribution and segmentation of homogenous tokens, which may include, for example, lateral transfers (i.e., transfers of homogenous tokens within communication devices at the same level) or bypassing communication devices in the set of cascaded intermediate communication devices. In the above example, the first communication device and the second communication device are at a different level (in order of data transmission) from the fourth communication device, the fifth communication device, the sixth communication device, and the seventh communication device.

[0071] The third communication device is at both the first level and the last level.

[0072] At step 307, a processor at the transaction initiating communication device or a processor at a designated recipient communication device receives a set of non-fungible tokens for each of the second set of fungible token groups from a second set of communication devices. Each of the plurality of non-fungible tokens is indivisible and is associated with (1) a transaction destination in the set of transaction destinations and (2) an identifier from the set of identifiers. The second plurality of communication devices does not include the transaction initiating communication device. In some implementations, when all fungible tokens are distributed to intermediate communication devices that have a direct account relationship with the transaction destination, these intermediate communication devices (i.e., the last set of communication devices) convert the fungible tokens into non-fungible tokens by incorporating identification characteristics or information of the transaction destination (or end entity). In some implementations, instead of converting the fungible tokens into non-fungible tokens, these intermediate communication devices (i.e., the last set of communication devices) generate new non-fungible tokens that include identification characteristics or information. The information associated with a non-fungible token includes (1) an identifier of the transaction destination, (2) an identifier of a communication device (among the intermediate communication devices) that generated (or converted from) the non-fungible token, (3) an identifier of a communication device in a set of cascaded intermediate communication devices that transferred any fungible token from a set of fungible tokens associated with that non-fungible token, and / or (4) a "value" parameter representing the number of fungible tokens associated with that transaction destination. In other words, the number of fungible tokens can be represented as a "value" parameter of a non-fungible token, but the non-fungible token does not include the associated fungible token. Therefore, a chain of custody for each fungible token can be established based on the non-fungible token and the information contained in the non-fungible token. In some implementations, the non-fungible token may include other data fields associated with the transaction destination or characteristic information associated with the transaction destination (e.g., the name of the transaction destination, the location of the transaction destination, the country of residence, the entity type of the transaction destination (e.g., company, pension fund, natural person, etc.), etc.). For example, the processors at the third communication device, the fourth communication device, the fifth communication device, the sixth communication device, and the seventh communication device each generate a non-fungible token and send it to the transaction initiating communication device or the designated recipient communication device.

[0073] At step 309, a processor at the transaction initiating communication device or a processor at a designated recipient communication device stores data associated with the set of non-fungible tokens and the set of homogeneous tokens in a second instance of a distributed ledger database. The second instance of the distributed ledger database is transmittable between at least the first set of communication devices and the second set of communication devices. For each non-fungible token in the set of non-fungible tokens, the data associated with that non-fungible token may include (1) an identifier of the transaction destination, (2) an identifier of the communication device (of those intermediate communication devices) that generated (or converted from the homogeneous token) the non-fungible token, (3) an identifier of a communication device in the set of cascaded intermediate communication devices 20nm that transferred any homogeneous token in the set of homogeneous tokens associated with that non-fungible token, (4) a "value" parameter representing the number of homogeneous tokens associated with that transaction destination, and / or (5) a second value (or a derived value) calculated based on the value parameter of the non-fungible token. Based on the non-fungible token of the last set of communication devices in the set of cascaded intermediate communication devices, a processor at the transaction initiating communication device or the designated recipient communication device identifies or reveals the distinguishing characteristics of the homogenous asset and thereby establishes a chain of custody of the homogenous asset.

[0074] In some implementations, after receiving a non-fungible token, the transaction initiating communication device or the designated receiving communication device may be based on the information contained in each non-fungible token (e.g., the value parameter of the non-fungible token; or the first value) and the algorithm. Each non-fungible token in the non-fungible token set corresponds to a second value (or a derived value) in the value set (or a derived value set). The transaction initiating communication device or the designated receiving communication device may calculate the difference between the value parameter (or first value) of the non-fungible token and the second value associated with that non-fungible token, and record it as a third value associated with that non-fungible token. The third value associated with that non-fungible token corresponds to a subset of homogeneous tokens. The transaction initiating communication device or the designated receiving communication device may send the non-fungible token, the second value associated with that non-fungible token, and the third value to a communication device in (one or more) intermediate communication devices that have a direct account relationship with the transaction destination, so that the communication device can record these values ​​in the account of the transaction destination. In some implementations, the transaction initiating communication device or the designated recipient communication device may send a non-fungible token, a second value associated with that non-fungible token, and a third value to a communication device in one or more intermediate communication devices that has a direct account relationship with the transaction destination. The transaction initiating communication device or the designated recipient communication device may send the second value associated with that non-fungible token to a different entity on behalf of the transaction destination. In these implementations, the transaction destination is entitled to a number of homogenous tokens equal to the third value of the non-fungible token. The number of homogenous tokens equal to the third value of the non-fungible token is a subset of the homogenous tokens equal to the first value of the non-fungible token.

[0075] Applying Some Embodiments to Assets in Custody Accounts

[0076] Some embodiments include methods for tokenizing ownership of an asset (such as a financial instrument) at a specified point in time, or for tokenizing rights associated with a rights event at a specified point in time. The tokenized ownership rights or rights are distributed as homogeneous tokens that are subdivided through a network of financial intermediaries (or a network of cascaded communication devices) and mapped through any intermediate securities or investment vehicles. The token subdivision and distribution process of the transaction initiating communication device is cascaded through the network (or distributed ledger-based network (DLN)) until the ultimate owner (or transaction destination) is identified, ending with the exchange of distributed homogeneous tokens for non-homogeneous (e.g., uniquely identifiable) tokens that identify each ultimate owner (or transaction destination) and the number of homogeneous tokens exchanged when the non-homogeneous token was created.

[0077] Tokens represent ownership or rights at a specified point in time, which can be queried during the cascading process of subdividing and distributing fungible tokens (e.g., operations Figure 2B This is done by looking at the account structure of each financial institution (e.g., the transaction initiation communication device 290 in the transaction initiation communication device 290). This query can be sent to the transaction initiation communication device 290 or DLN. This is effectively a "snapshot" of each institution's accounts and their holdings as they relate to the relevant assets, entities, or events. Based on this "snapshot" of its accounts and holdings, (e.g., operations Figure 2B The financial institution (the one that initiates the transaction in the communication device 290) can determine how to subdivide its shares of the homogenous token into its accounts, resulting in cascading the subdivision and distribution process to the next level or exchanging part of its homogenous token for one or more non-homogeneous tokens when the account is determined to be the ultimate owner (transaction destination).

[0078] In one use case, the definition of the ultimate owner (or transaction destination) is related to identifying the beneficial ownership of an asset or entity for purposes such as Know Your Customer (KYC) or Anti-Money Laundering (AML) enforcement. In another use case, the ultimate owner (or transaction destination) is defined under tax laws that are intended to identify individuals or entities that are subject to taxes (such as withholding taxes calculated relative to rights such as dividends, interest payments, or capital gains).

[0079] In some implementations, the net result is the establishment of a “chain of custody” for each holding in an asset, entity, or financial instrument at a specified point in time, spanning financial intermediaries (a collection of cascaded intermediate communication devices) and ending at each ultimate owner (transaction destination). Each “chain of custody” is represented by blockchain transactions that subdivide and distribute fungible tokens and terminate at each ultimate owner (transaction destination) and exchange non-fungible tokens. In the use case of identifying owners and their ownership shares that are subject to withholding tax, non-fungible tokens identify the owner’s country of residence and tax treaty category to allow the calculation of appropriate withholding tax for each ultimate owner’s holding and its country of residence and tax treaty category.

[0080] In some embodiments, the identity of each ultimate owner (transaction destination) can be securely held by a transaction destination communication device (operated by a financial institution) that has a direct relationship with the owner (transaction destination), and for the purpose of calculating withholding taxes, only the owner's country of residence and tax treaty category are reported; while providing a means for tax authorities or other auditors to request a digital representation of the owner's identity and related legal documents (such as a Country of Residence (COR) statement) from a financial institution that has a direct relationship with the owner (transaction destination).

[0081] In some embodiments, the sequence of cascading fungible token distributions through blockchain transactions can be kept private by using zero-knowledge proof (ZKP) technology. The same ZKP technology can also be used to protect the privacy of blockchain transactions that exchange fungible tokens for non-fungible tokens that identify the ultimate owner (or transaction destination) subject to withholding tax. In addition, the calculation of withholding tax can be performed by the communication device distributing rights on each non-fungible token and recording the withholding tax as an attribute of that non-fungible token.

[0082] In some embodiments, the system disclosed herein can be integrated with an electronic payment system to distribute payments associated with rights as net amounts after deducting appropriate withholding taxes. Integration with an electronic payment system can also send withholding tax payments directly to the government or government agent. The electronic payment system itself can be a blockchain system in which payments are tokenized as legal digital currency.

[0083] For use cases that require identification of the ultimate owner (or destination of a transaction) within a complex network of financial intermediaries (or a collection of cascading intermediate communication devices), the disclosed embodiments offer major advantages in terms of efficiency and cost reduction compared to current paper-based alternatives. The current exchange of paper documents across a network of financial intermediaries (or a collection of cascading intermediate communication devices) is inefficient, with intermediate calculations typically completed on spreadsheets and then manually transcribed into paper documents and then forwarded to the next level in the chain of custody. Even if some degree of automation is achieved within or between financial institutions (e.g., SWIFT messages), significant gaps can still exist in the information required for different use cases, forcing parallel paper-based workflows. There are additional and considerable restrictions on the flow of information across a network of financial intermediaries (or a collection of cascading intermediate communication devices) due to business considerations and privacy requirements.

[0084] The introduction of a derivative or intermediate financial instrument or collective investment vehicle (“CIV”) into the chain of custody further complicates existing processes (whether paper-based or semi-automated). The relationship between the original asset and the derivative or intermediate instrument or CIV can be carefully tracked to identify the ultimate owner (or destination of the transaction) and its ownership share in the relevant original asset or entity.

[0085] In some embodiments, automated techniques, systems and / or components (e.g., without the use of human intervention) can establish each "chain of custody" as a series of immutable blockchain transactions, thereby significantly reducing the time and effort to determine each "chain of custody" while greatly increasing the trust and security of the results. The use of fungible and non-fungible tokens provides a clear demarcation between the discovery process of tracing ownership shares through a complex network of intermediaries (or a collection of cascading intermediate communication devices) and the ultimate identification of the ultimate owner (or transaction destination).

[0086] When blockchain transactions are implemented with ZKP technology, the segmentation and distribution of homogenous tokens by the transaction initiating communication device can preserve the privacy of the business relationship while still providing assurance that the process was correctly executed and that all tokens (and therefore all shares of an asset or entity) were accounted for throughout the process. In addition, the use of ZKP technology allows the key characteristics of the ultimate owner (or transaction destination) (e.g., country of residence, number of shares held, type of owner, etc.) to be shared without revealing the identity of the ultimate owner (or transaction destination), while ensuring that the information is available to legitimate institutions that have access to the details.

[0087] For the withholding tax use case, in some embodiments, the technology, systems and / or components can achieve the benefits of "source relief" in the context of the current financial system. The legal liability for withholding taxes remains unchanged, the relationship structure between financial intermediaries (or collections of cascaded intermediate communication devices) remains unchanged, the use of intermediate securities or collective investment vehicles as rights conduits remains unchanged, and the privacy of account relationships between complex networks of financial intermediaries remains unchanged. Some or all of the benefits of working within the current financial system are achieved while significantly simplifying the process of determining withholding taxes, automatically providing legitimate tax relief to eligible tax owners, reducing the risk of government withholding tax fraud, and providing a method for automatic redemption in situations where "source relief" is currently legally or practically impossible. In addition, the use of blockchain technology provides security and reliability benefits compared to processing through centralized infrastructure.

[0088] Using fungible tokens throughout the cascade of distributing dividends or other rights, and then exchanging non-fungible tokens at the “leaf nodes” of the processing grid, greatly reduces the required processing power and therefore the relative cost of using the blockchain network, compared to using non-fungible tokens throughout the process.

[0089] Entitlement and Withholding Use Cases

[0090] In some embodiments, the processing steps for the entitlement and withholding use case are as follows:

[0091] 1. In advance (usually once a year), the financial intermediary with whom the investor (individual or entity) has a direct relationship stores the following information in its own database (the "local database"): name, address, account unique identifier, country of residence for tax purposes, taxpayer identifier, digital representation of the investor's country of residence (COR) document issued by the government agency, etc. This can be done for each investor participating in this system.

[0092] 2. In advance, each financial intermediary participating in the system is registered on the blockchain network and can optionally host its own node on this network. The registration process allows participating financial intermediaries to process transactions with other intermediaries based on their existing account relationships.

[0093] 3. In advance, each financial institution that intends to distribute rights through the system registers the securities or other financial instruments that may be the basis of the rights, thereby providing a unique identifier for that security or other financial instrument. This allows each financial intermediary to identify which of its accounts hold securities or financial instruments when processing rights events.

[0094] 4. When the organization issuing the rights or its delegate in the blockchain network (the "sponsoring organization") announces future rights, the rights are registered through a transaction on the blockchain and have a unique identifier for the right, a unique identifier for the security or other financial instrument, a unique identifier for the sponsoring organization, the type of right (e.g., a stock dividend), the basis per unit of the right (e.g., per share), the terms of the right (e.g., $1 per share), the announcement date, the effective date, the record date (the date used to establish the record of the owner and his or her holdings that are eligible to obtain the right), the response date (the date on which a response identifying ownership must be reported back to the institution that issued the rights), the payment date (the date on which any payment associated with the right can be issued), etc.

[0095] 5. When the record date for the right is reached, a cascading set of transactions to distribute the right begins. Fungible tokens, one per unit of right, are created (minted) by the organization issuing the right (or its delegate) (the “sponsoring organization”). The sponsoring organization then divides the total supply of these tokens through blockchain transactions with each financial intermediary with which it has a direct account relationship with a given security or other financial instrument. Account information is queried from that organization’s existing account database, reflecting each account’s holdings as of the right’s record date. This process can be triggered either through a manual process or automatically based on the record date.

[0096] 6. When a financial intermediary receives and accepts a transaction for a fungible token associated with a Rights event, it checks its local accounts as of the record date to identify the accounts eligible for the Rights and the assets they hold. Since different financial intermediaries update their account information on different schedules, the query can be suspended until the account information is available, but no later than the "response" date defined by the Rights. Depending on the information retrieved from the local account database, one or more of the following actions will be performed:

[0097] 6a. If the account is held by another financial intermediary, issue a blockchain transaction that distributes the number of fungible tokens corresponding to the account's holdings as of the record date. This may result in the transfer of these fungible tokens to other financial intermediaries, which may respond by executing their own implementation of step 6.

[0098] 6b. If the account represents a security or other financial instrument that is eligible for the right, and this security or financial investment (a "downstream financial instrument") is not considered a taxable entity, then the financial intermediary maps the right to an equivalent share of this downstream security or financial instrument. The financial intermediary then queries its account database to find the account holding this downstream financial instrument. This results in one or more transactions that divide the homogenized tokens and transfer these tokens to these downstream accounts (based on their relative holdings of the original security or financial instrument and with reference to the original right). Note that the division process produces fractional tokens, and generally all transactions support fractional tokens.

[0099] 6c. If an account represents a security or other financial instrument that is eligible for rights, and such security or financial investment (a “downstream financial instrument”) is considered a taxable entity, then the financial intermediary issues a transaction to exchange a non-fungible token for a fungible token assigned to that account, the value of which is equal to the number of fungible tokens assigned to that account, the treaty classification based on the type of security or other financial instrument, the country of residence based on the tax residence claimed for that security or financial instrument, the unique network ID of the financial intermediary making the exchange, and a unique identifier for the account that only the financial intermediary can decode and map to the account (the “opaque identifier”). Tax authorities or other auditors with legal authority to request account information may request this detailed account information from the financial intermediary by referencing the opaque identifier.

[0100] 6d. If the account represents an ultimate owner who is eligible for the rights, and the ultimate owner is considered a taxable person or entity, and the ultimate owner has agreed to participate in the process, then the financial intermediary issues a transaction to exchange the fungible token assigned to the account for a non-fungible token with a value equal to the number of fungible tokens assigned to that account, the unique network ID of the financial intermediary making the exchange, and a unique identifier of the account that only the financial intermediary can decode and map to this account (the "opaque identifier"). For the withholding tax use case, the non-fungible token may also have the treaty category of the ultimate owner with respect to the rights, and the country of residence based on the tax residence claimed by which ultimate owner. A tax authority or other auditor with legal authority to request account information may request this detailed account information from the financial intermediary by referencing the opaque identifier. For the ultimate owner, the information collected in step (1) may be provided to that tax authority or other auditor by encrypted means.

[0101] 6e. If the account represents an ultimate owner who is not permitted to participate in the process, or the account is held by a financial intermediary that is not participating in the blockchain network, or the account cannot be otherwise identified within the scope of legal requirements or requirements to participate in the process, or the "response" date of the entitlement event has expired, then the financial intermediary issues a transaction to exchange the fungible tokens assigned to the account for a special type of placeholder non-fungible token ("grey token"), the value of which is equal to the number of fungible tokens assigned to that account. "Grey tokens" have an undefined treaty class, an undefined country of residence, the reason for the issuance of the token (e.g., non-participating account, non-participating financial intermediary, expired "response" date), a unique network ID of the financial intermediary making the exchange, and a unique identifier for the account that only the financial intermediary can decode and map to this account ("opaque identifier"). Tax authorities or other auditors with legal authority to request account information can request this detailed account information from the financial intermediary by referencing the opaque identifier. The purpose of “grey tokens” is to allow for the integrity of the process for converting all fungible tokens of an entitlement event into an equivalent amount of non-fungible token value, thereby supporting auditable coordination of the process used for each entitlement event. Since “grey tokens” do not provide any information to support a reduced withholding tax rate, the assumption in calculating withholding tax on “grey tokens” is to use the default tax rate applicable to that type of event and financial instrument.

[0102] 7. When each non-fungible token is created (minted) through the exchange defined in step (6), the originating organization or designated recipient organization will be notified by electronic means of the exchange. Upon receipt of notification of the creation (minting) of a non-fungible token, or at any time between the "Response Date" and the "Payment Date" specified for an Entitlement Event, based on information provided by the non-fungible token, such as the number of equivalent fungible tokens (e.g., the number of shares held in the account in the securities, the country of residence provided in the non-fungible token, the tax treaty category supplied in the non-fungible token, and any other information provided in the non-fungible token that is relevant to the calculation of the rights and any associated taxes (e.g., withholding taxes), the originating organization or, alternatively, the designated recipient organization, is able to calculate the amount of rights and (in the withholding tax use case) the applicable withholding taxes assigned to that non-fungible token.

[0103] For the withholding tax use case, as an additional step in the process after step (7), the originating organization, or alternatively, a designated recipient organization, may publish a blockchain transaction that updates each non-fungible token with the amount of withholding tax calculated for that non-fungible token. If a tax authority or other auditor with legal authority to obtain this information requires an audit of the information in the non-fungible token, a request may be made to the financial intermediary that minted the non-fungible token to access account information held by that financial intermediary as defined in step (1) of the process. In the audit request, the account's "opaque identifier" is used by the financial intermediary to map to its own local account information database. The requested information may then be encrypted and transmitted electronically to the authorized requesting tax authority or other auditor. By querying the transaction on the blockchain and generating one or more reports, it may be possible to create an audit trail of the transaction, thereby determining the ultimate owner (taxable individual or legal entity) and calculating any withholding tax.

[0104] Identify the end owner use case

[0105] In some embodiments, for the use case of identifying the ultimate owner (transaction destination), the processing steps are as follows:

[0106] 1. In advance (usually once a year), the financial intermediary with whom the investor (individual or entity) has a direct relationship stores the following information in its own database (the "local database"): name, address, account unique identifier, country of residence for tax purposes, taxpayer identifier, digital representation of the investor's country of residence (COR) document issued by the government agency, etc. This is done for each investor participating in the system.

[0107] 2. In advance, each financial intermediary participating in the system is registered on the blockchain network. And can optionally host its own node on this network. The registration process allows participating financial intermediaries to process transactions with other intermediaries based on their existing account relationships.

[0108] 3. In advance, each financial institution that intends to distribute rights through the system registers a unique identifier for the asset or entity that can serve as the basis for the rights, thereby providing a unique identifier for that asset or entity. This can allow each financial intermediary to identify which of its accounts hold that asset or entity when requesting a record of ownership.

[0109] 4. When an organization or its delegate in a blockchain network (the “sponsoring organization”) issues a request for an ownership record, the request is registered via a transaction on the blockchain with a unique identifier for the request, a unique identifier for the asset or entity, a unique identifier for the sponsoring organization, the type of request, the basis for each unit of ownership (e.g., per share of stock), the announcement date, the effective date, the record date (the date used to establish the owner of the record and the date on which their holdings are eligible to obtain the right), the response date (the date on which a response identifying the ownership must be reported back to the authority that issued the right), and any other information relevant to the request.

[0110] 5. When the requested record date is reached, a cascading set of transactions to distribute ownership shares begins. Fungible tokens, one per ownership unit, are created (minted) by the originating organization (or its delegate). The originating organization then divides the total supply of these tokens through blockchain transactions with each financial intermediary that has a direct account relationship with a given asset or entity. Account information is queried from that organization's existing account database, reflecting each account's holdings as of the record date. This process can be triggered either through a manual process or automatically based on the record date.

[0111] 6. When the Financial Intermediary receives and accepts the Fungible Token Transaction associated with the Request, it checks its local accounts as of the Record Date to identify the accounts and the associated assets or entities they hold. Since different Financial Intermediaries update their account information on different schedules, the query may be suspended until the account information is available, but no later than the “response” date defined by the Entitlement. Depending on the information retrieved from the local account database, one or more of the following actions will be performed:

[0112] 6a. If the account is held by another financial intermediary, issue a blockchain transaction that distributes the number of fungible tokens corresponding to the account's holdings as of the record date. This may result in the transfer of these fungible tokens to other financial intermediaries, which may respond by executing their own implementation of step 6.

[0113] 6b. If the account represents a security or other financial instrument that has an ownership stake in the associated original asset or entity, and this security or financial investment (a "downstream financial instrument") is not considered the ultimate owner of this request, then the financial intermediary maps the ownership share to an equivalent share of this downstream security or financial instrument. The financial intermediary then queries its account database to find the account holding this downstream financial instrument. This results in one or more transactions that divide the homogenous tokens and transfer these tokens to these downstream accounts (based on their relative holdings of the original asset or entity and with reference to the original asset or entity). In some implementations, the division process results in fractional tokens, and generally all transactions support fractional tokens.

[0114] 6c. If the account represents a security or other financial instrument that has an ownership stake in the original asset or entity, and this security or financial investment (“downstream financial instrument”) is considered the ultimate owner of this request, then the financial intermediary issues a transaction exchanging the fungible token assigned to the account for a non-fungible token with a value equal to the number of fungible tokens assigned to that account, additional information about the ultimate owner based on the type of request, the unique network ID of the financial intermediary making the exchange, and an account unique identifier that only the financial intermediary can decode and map to this account (“opaque identifier”). Tax authorities or other auditors with legal authority to request account information can request this detailed account information from the financial intermediary by referencing the opaque identifier.

[0115] 6d. If the account represents the ultimate owner of the request, and the ultimate owner has agreed to participate in the process, the financial intermediary issues a transaction exchanging the fungible token assigned to the account for a non-fungible token having a value equal to the number of fungible tokens assigned to that account, additional information about the ultimate owner based on the type of request, the unique network ID of the financial intermediary conducting the transaction, and a unique identifier of the account that only the financial intermediary can decode and map to this account (the "opaque identifier"). A tax authority or other auditor with legal authority to request account information can request this detailed account information from the financial intermediary by citing the opaque identifier. For the ultimate owner, the information collected in step (1) can be supplied to that tax authority or other auditor by encrypted means.

[0116] 6e. If the account represents an ultimate owner who is not permitted to participate in the process, or the account is held by a financial intermediary that is not participating in the blockchain network, or the account cannot be otherwise identified within the scope of legal requirements or requirements to participate in the process, or the "response" date of the entitlement event has expired, then the financial intermediary issues a transaction to exchange the fungible tokens assigned to the account for a special type of placeholder non-fungible token ("grey token"), the value of which is equal to the number of fungible tokens assigned to that account. The "grey token" has the reason for the issuance of the token (e.g., non-participating account, non-participating financial intermediary, expired "response" date), the unique network ID of the financial intermediary making the exchange, and the account unique identifier that only the financial intermediary can decode and map to this account ("opaque identifier"). Tax authorities or other auditors with legal authority to request account information can request this detailed account information from the financial intermediary by referencing the opaque identifier. The purpose of the "grey token" is to ensure the integrity of the process of converting all fungible tokens associated with this request into an equivalent amount of non-fungible tokens, thereby supporting auditable coordination of the process.

[0117] 7. When each non-fungible token is created (minted) through the exchange defined in step (6), the originating organization or the designated recipient organization will be notified by electronic means of the exchange. Upon receipt of notification of the creation (minting) of a non-fungible token, or at any time between the "Response Date" and "Payment Date" specified for the Entitlement Event, the originating organization or, alternatively, the designated recipient organization, will be able to calculate the ownership stake of each ultimate owner based on the information provided by each non-fungible token.

[0118] Although various embodiments have been described and illustrated herein, it will be easy to think of various other devices and / or structures for performing the functions described herein and / or obtaining one or more of the results and / or advantages described herein, and each of these changes and / or modifications is considered to be within the scope of the embodiments described herein. More generally, it will be easy to recognize that all parameters and configurations described herein are intended to be exemplary, and the actual parameters and configurations will depend on one or more specific applications for which this teaching is used. It will be recognized that, or it is possible to determine many equivalents of the specific embodiments described herein using only routine experiments. Therefore, it should be understood that the aforementioned embodiments are only given as examples, and within the scope of the present disclosure (including the attached claims and their equivalents), the disclosed embodiments can be practiced in a manner different from that specifically described and claimed. The embodiments of the present disclosure relate to each individual feature, system, tool, element, assembly and / or method described herein. In addition, if such features, systems, tools, elements, assemblies and / or methods are not mutually contradictory, any combination of two or more such features, systems, tools, elements, assemblies and / or methods is included within the inventive scope of the present disclosure.

[0119] The above embodiments may be implemented in any of a variety of ways. For example, the embodiments may be implemented using hardware, software, or a combination thereof. When implemented in software, the software code may be stored (e.g., in a non-transitory memory) and executed on any suitable processor or set of processors, whether provided in a single computer or distributed between multiple computers.

[0120] In addition, it should be appreciated that the computer may be embodied in any of a variety of forms, such as a rack-mounted computer, a desktop computer, a laptop computer, a notebook computer, or a tablet computer. In addition, the computer may be embedded in a device that is not generally regarded as a computer but has suitable processing capabilities (including a smart phone, a smart device, or any other suitable portable or fixed electronic device).

[0121] Moreover, the computer can have one or more input and output devices. These devices can be used to present the user interface, etc. The example of the output device that can be used to provide the user interface comprises a printer or display screen for visual output presentation or a loudspeaker and other sound generating devices for audible output presentation. The example of the input device that can be used for the user interface comprises a keyboard and a pointing device (such as a mouse, a touch pad and a digitized tablet). As another example, the computer can receive input information by speech recognition or other audible formats.

[0122] Such computers may be interconnected by one or more networks of any suitable form, including local or wide area networks (such as enterprise networks and intelligent networks (IN) or the Internet). Such networks may be based on any suitable technology and may operate according to any suitable protocol, and may include wireless networks, wired networks, or fiber optic networks.

[0123] The various methods or processes outlined herein may be encoded as software that can be executed on one or more processors using any of a variety of operating systems or platforms. In addition, such software may be written using any of a variety of suitable programming languages ​​and / or programming or scripting tools, and may also be compiled into executable machine language code or intermediate code that is executed on a framework or virtual machine.

[0124] In this regard, the concepts of the various disclosures may be embodied as a computer-readable storage medium (or multiple computer-readable storage media) (e.g., computer memory, one or more floppy disks, compact disks, optical disks, tapes, flash memory, circuit configurations in field programmable gate arrays or other semiconductor devices, or other non-transitory media or tangible computer storage media) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the present disclosure discussed above. The computer-readable medium(s) may be portable, such that the program(s) stored thereon may be loaded onto one or more different computers or other processors to implement the various aspects of the present disclosure as discussed above.

[0125] The term "program" or "software" as used herein refers in a general sense to any type of computer code or processor executable instruction set that can be used to program a computer or other processor to implement various aspects of the embodiments as discussed above. In addition, it should be recognized that, according to one aspect, one or more computer programs that perform the methods of the present disclosure when executed need not reside on a single computer or processor, but can be distributed in a modular manner among multiple different computers or processors to implement various aspects of the present disclosure.

[0126] Computer executable instructions can have many forms, such as program modules that are executed by one or more computers or other devices. Generally speaking, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. Typically, the functionality of the program modules can be combined or distributed as desired in various embodiments.

[0127] Moreover, the data structure can be stored in a computer-readable medium in any suitable form. To simplify the description, the data structure can be shown as having fields that are related by position in the data structure. This relationship can also be achieved by assigning a position in a computer-readable medium that conveys the relationship between the fields for the storage of the fields. However, any suitable mechanism can be used to establish the relationship between the information in the fields of the data structure, including by using pointers, tags or other mechanisms that establish relationships between data elements.

[0128] Moreover, various concepts can be embodied as one or more methods for which examples have been provided. The actions performed as part of the method can be ordered in any suitable manner. Therefore, embodiments can be constructed such that the actions are performed in an order different from that shown, which may include performing some actions simultaneously, although they are shown as sequential actions in the illustrative embodiments. All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety.

[0129] As defined and used herein, all definitions should be understood to control over dictionary definitions in documents incorporated by reference and / or ordinary meanings of the defined terms.

[0130] As used herein in the specification and in the claims, unless explicitly indicated to the contrary, the indefinite articles "a" and "an" should be understood to mean "at least one".

[0131] As used herein in the specification and in the claims, the phrase "and / or" should be understood to mean "either or both" of the elements so connected, i.e., elements that are present in combination in some cases and separately in other cases. Multiple elements listed with "and / or" should be interpreted in the same manner, i.e., "one or more" of the elements so combined. In addition to the elements specifically identified by the "and / or" clause, other elements may optionally be present, whether related or unrelated to those specifically identified elements. Thus, as a non-limiting example, when used in conjunction with open language such as "comprising," a reference to "A and / or B" may, in one embodiment, refer only to A (optionally including elements other than B); in another embodiment, refer only to B (optionally including elements other than A); in yet another embodiment, refer to both A and B (optionally including other elements); and so on.

[0132] As used herein, "or" should be understood to have the same meaning as "and / or" as defined above. For example, when separating items in a list, "or" or "and / or" should be interpreted as inclusive, that is, including at least one of a plurality of elements or lists of elements, but also including more than one, and optionally, including additional unlisted items. Only terms that clearly indicate the opposite, such as "only one of..." or "exactly one of...", or "consisting of..." when used in the claims, will refer to including exactly one element among a plurality of elements or lists of elements. In general, as used herein, when preceded by an exclusive term (such as "any one", "one of...", "only one of..." or "exactly one of..."), the term "or" as used herein will only be interpreted as indicating an exclusive alternative (i.e., "one or the other but not both"). When used in the claims, "consisting essentially of..." will have its ordinary meaning as used in the field of patent law.

[0133] As used herein, the phrase "at least one" when referring to a list of one or more elements should be understood to mean at least one element selected from any one or more elements in the list of elements, but not necessarily including at least one element of each element specifically listed in the list of elements and not excluding any combination of elements in the list of elements. This definition also allows that there may be optionally elements other than the elements specifically identified in the list of elements referenced by the phrase "at least one", whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, "at least one of A and B" (or equivalently, "at least one of A or B", or equivalently, "at least one of A and / or B") may, in one embodiment, refer to at least one, optionally including more than one A, where B is not present (and optionally including elements other than B); in another embodiment, refer to at least one, optionally including more than one B, where A is not present (and optionally including elements other than A); in yet another embodiment, refer to at least one, optionally including more than one A, and at least one, optionally including more than one B (and optionally including other elements); and so on.

[0134] All transitional phrases (such as "comprising," "including," "carrying," "having," "containing," "involving," "holding," "having," etc.) are understood to be open-ended, i.e., meaning including, but not limited to. Only the transitional phrases "consisting of" and "consisting essentially of" shall be closed or semi-closed transitional phrases, respectively, as set forth in the United States Patent Office Manual of Patent Examining Procedures Section 2111.03.

Claims

1. A device comprising: Memory; as well as A processor operably coupled to the memory, the processor configured to: Generating a plurality of fungible tokens associated with a plurality of fungible assets, a first fungible token in the plurality of fungible tokens being of the same type as a second fungible token in the plurality of fungible tokens, the plurality of fungible tokens collectively representing the plurality of fungible assets on a distributed ledger-based network; Dividing the plurality of fungible tokens into a first plurality of fungible token groups; sending, via a distributed ledger-based network, each of a first plurality of homogenous token groups to (1) a communication device associated with the homogenous token group and (2) from a first plurality of communication devices, the first plurality of homogenous token groups being divided into a second plurality of homogenous token groups and received at a second plurality of communication devices, the second plurality of communication devices being at a different level in a data transmission order than the first plurality of communication devices; as well as receiving a plurality of non-fungible tokens from a second plurality of communication devices, each non-fungible token including (1) a transaction destination uniquely identifying the plurality of transaction destinations and (2) an identifier from the plurality of identifiers, each non-fungible token being associated with a group of fungible tokens from the second plurality of groups of fungible tokens, in: The plurality of non-fungible tokens are generated by a second plurality of communication devices and do not include a second plurality of homogenous token groups.

2. A device comprising: Memory; as well as A processor operably coupled to the memory, the processor configured to: Generating a plurality of fungible tokens associated with a plurality of fungible assets, a first fungible token in the plurality of fungible tokens being of the same type as a second fungible token in the plurality of fungible tokens, the plurality of fungible tokens collectively representing the plurality of fungible assets on a distributed ledger-based network; Dividing the plurality of fungible tokens into a first plurality of fungible token groups; sending, via a distributed ledger-based network, each of a first plurality of homogenous token groups to (1) a communication device associated with the homogenous token group and (2) from a first plurality of communication devices, the first plurality of homogenous token groups being divided into a second plurality of homogenous token groups and received at a second plurality of communication devices, the second plurality of communication devices being at a different level in a data transmission order than the first plurality of communication devices; as well as receiving a plurality of non-fungible tokens from a second plurality of communication devices, each non-fungible token including (1) a transaction destination uniquely identifying the plurality of transaction destinations and (2) an identifier from the plurality of identifiers, each non-fungible token being associated with a group of fungible tokens from the second plurality of groups of fungible tokens, in: A communication device in the first plurality of communication devices is at a first tier at a first time and is at a second tier at a second time.

3. A device comprising: Memory; as well as A processor operably coupled to the memory, the processor configured to: Generating a plurality of fungible tokens associated with a plurality of fungible assets, a first fungible token in the plurality of fungible tokens being of the same type as a second fungible token in the plurality of fungible tokens, the plurality of fungible tokens collectively representing the plurality of fungible assets on a distributed ledger-based network; Dividing the plurality of fungible tokens into a first plurality of fungible token groups; sending, via a distributed ledger-based network, each of a first plurality of homogenous token groups to (1) a communication device associated with the homogenous token group and (2) from a first plurality of communication devices, the first plurality of homogenous token groups being divided into a second plurality of homogenous token groups and received at a second plurality of communication devices, the second plurality of communication devices being at a different level in a data transmission order than the first plurality of communication devices; as well as receiving a plurality of non-fungible tokens from a second plurality of communication devices, each non-fungible token including (1) a transaction destination uniquely identifying the plurality of transaction destinations and (2) an identifier from the plurality of identifiers, each non-fungible token being associated with a group of fungible tokens from the second plurality of groups of fungible tokens, in: The hierarchy of the communication devices in the first plurality of communication devices is not associated with a physical connection or a geographic region of the communication devices.

4. A method comprising: Generating a plurality of fungible tokens associated with a plurality of fungible assets, a first fungible token in the plurality of fungible tokens being of the same type as a second fungible token in the plurality of fungible tokens, the plurality of fungible tokens collectively representing the plurality of fungible assets on a distributed ledger-based network; Dividing the plurality of fungible tokens into a first plurality of fungible token groups; sending, via a distributed ledger-based network, each of a first plurality of homogenous token groups to (1) a communication device associated with the homogenous token group and (2) from a first plurality of communication devices, the first plurality of homogenous token groups being divided into a second plurality of homogenous token groups and received at a second plurality of communication devices, the second plurality of communication devices being at a different level in a data transmission order than the first plurality of communication devices; as well as A plurality of non-fungible tokens are received from a second plurality of communication devices, each non-fungible token comprising (1) a transaction destination uniquely identifying one of a plurality of transaction destinations and (2) an identifier from a plurality of identifiers, each non-fungible token being associated with a group of homogeneous tokens in a second plurality of groups of homogeneous tokens.

5. The method of claim 4, wherein: Each communication device of the second plurality of communication devices is configured to store an account identifier associated with at least one transaction destination of the plurality of transaction destinations.

6. The method of claim 4, wherein: The plurality of non-fungible tokens are converted based on a second plurality of fungible token groups and include information of the second plurality of fungible token groups.

7. The method of claim 4, wherein: Sending each of the first plurality of fungible token groups via the distributed ledger-based network includes using a zero-knowledge proof protocol.

8. The method of claim 4, wherein: Sending each of the first plurality of fungible token groups via the distributed ledger-based network includes using a zero-knowledge proof protocol; Protocols using zero-knowledge proofs include: For each fungible token group in the first plurality of fungible token groups: Calculating a fungible token commitment based on (1) the fungible token set, (2) a public key of an asymmetric encryption key pair associated with a transaction initiating communication device, (3) a random number, and (4) a hash function; and The fungible token group is sent by sending a fungible token commitment.

9. The method of claim 4, wherein: The plurality of fungible tokens do not include an identifier that uniquely identifies a transaction destination among the plurality of transaction destinations.

10. The method of claim 4, wherein: The first plurality of homogeneous token groups are invalidated based on a zero-knowledge proof protocol after being sent to the first plurality of communication devices.

11. The method of claim 4, wherein: Each non-fungible token in the plurality of non-fungible tokens includes a value representing a quantity of fungible tokens in that group of fungible tokens in the second plurality of groups of fungible tokens.

12. The method of claim 4, wherein: Each of the plurality of non-fungible tokens comprises: (1) a first value, representing the number of homogeneous tokens in the homogeneous token group of the second plurality of homogeneous token groups, (2) characteristic information associated with a transaction destination among the plurality of transaction destinations, and (3) A second value determined based on the first value and characteristic information associated with the transaction destination.

13. The method of claim 4, wherein: The plurality of transaction destinations do not operate communications devices that transmit data via a distributed ledger-based network.

14. A processor-readable non-transitory medium storing code representing instructions to be executed by a processor, the code comprising code causing the processor to: Generating a plurality of fungible tokens associated with a plurality of fungible assets, a first fungible token in the plurality of fungible tokens being of the same type as a second fungible token in the plurality of fungible tokens, the plurality of fungible tokens collectively representing the plurality of fungible assets on a distributed ledger-based network; Dividing the plurality of fungible tokens into a first plurality of fungible token groups; sending, via a distributed ledger-based network, each of a first plurality of homogenous token groups to (1) a communication device associated with the homogenous token group and (2) from a first plurality of communication devices, the first plurality of homogenous token groups being divided into a second plurality of homogenous token groups and received at a second plurality of communication devices, the second plurality of communication devices being at a different level in a data transmission order than the first plurality of communication devices; as well as A plurality of non-fungible tokens are received from a second plurality of communication devices, each non-fungible token comprising (1) a transaction destination uniquely identifying one of a plurality of transaction destinations and (2) an identifier from a plurality of identifiers, each non-fungible token being associated with a group of homogeneous tokens in a second plurality of groups of homogeneous tokens.

15. The processor-readable non-transitory medium of claim 14, wherein: Each communication device of the second plurality of communication devices is configured to store an account identifier associated with at least one transaction destination of the plurality of transaction destinations.

16. The processor-readable non-transitory medium of claim 14, wherein: The plurality of non-fungible tokens are converted based on a second plurality of fungible token groups and include information of the second plurality of fungible token groups.

17. The processor-readable non-transitory medium of claim 14, wherein: The code causing the processor to send each of the first plurality of fungible token groups via the distributed ledger-based network includes code causing the processor to use a zero-knowledge proof protocol.

18. The processor-readable non-transitory medium of claim 14, wherein: The code causing the processor to send each fungible token group in the first plurality of fungible token groups via the distributed ledger-based network includes code causing the processor to use a zero-knowledge proof protocol; The code causing the processor to use the zero-knowledge proof protocol includes code causing the processor to: For each fungible token group in the first plurality of fungible token groups: Calculating a fungible token commitment based on (1) the fungible token set, (2) a public key of an asymmetric encryption key pair associated with a transaction initiating communication device, (3) a random number, and (4) a hash function; and The fungible token group is sent by sending a fungible token commitment.

19. The processor-readable non-transitory medium of claim 14, wherein: The plurality of fungible tokens do not include an identifier that uniquely identifies a transaction destination among the plurality of transaction destinations.

20. The processor-readable non-transitory medium of claim 14, wherein: The first plurality of homogeneous token groups are invalidated based on a zero-knowledge proof protocol after being sent to the first plurality of communication devices.

21. The processor-readable non-transitory medium of claim 14, wherein: Each of the plurality of fungible tokens is associated with a unit of the plurality of fungible assets.

22. The processor-readable non-transitory medium of claim 14, wherein: Each non-fungible token of the plurality of non-fungible tokens includes ownership information associated with a transaction destination, wherein the transaction destination is (1) associated with the non-fungible token and (2) from the plurality of transaction destinations.

23. The processor-readable non-transitory medium of claim 14, wherein: Each communication device of the second plurality of communication devices has a direct account relationship with at least one transaction destination of the plurality of transaction destinations.

24. An apparatus comprising: Memory; as well as A processor operably coupled to the memory, the processor configured to: Generating a plurality of fungible tokens associated with a plurality of fungible assets, a first fungible token in the plurality of fungible tokens being of the same type as a second fungible token in the plurality of fungible tokens, the plurality of fungible tokens collectively representing the plurality of fungible assets on a distributed ledger-based network; Dividing the plurality of fungible tokens into a first plurality of fungible token groups; sending, via a distributed ledger-based network, each of a first plurality of homogenous token groups to (1) a communication device associated with the homogenous token group and (2) from a first plurality of communication devices, the first plurality of homogenous token groups being divided into a second plurality of homogenous token groups and received at a second plurality of communication devices, the second plurality of communication devices being at a different level in a data transmission order than the first plurality of communication devices; as well as receiving a plurality of non-fungible tokens from a second plurality of communication devices, each non-fungible token including (1) a transaction destination uniquely identifying the plurality of transaction destinations and (2) an identifier from the plurality of identifiers, each non-fungible token being associated with a group of fungible tokens from the second plurality of groups of fungible tokens, in: For each of the first plurality of fungible token groups, the processor is configured to calculate a fungible token commitment by using the fungible token group, a public key of an asymmetric encryption key pair associated with a transaction initiating communication device, and a random number as inputs to a hash function.

25. The method of claim 4, wherein: For each fungible token group in the first plurality of fungible token groups, computing a fungible token commitment includes using the fungible token group, a public key of an asymmetric encryption key pair associated with a transaction initiating communication device, and a random number as inputs to a hash function.

26. The processor-readable non-transitory medium of claim 14, wherein: The code causing the processor to calculate a fungible token commitment includes code causing the processor to perform the following operations: for each fungible token group in the first plurality of fungible token groups, use the fungible token group, a public key of an asymmetric encryption key pair associated with a transaction initiating communication device, and a random number as inputs to a hash function.

27. An apparatus comprising: Memory; as well as A processor operably coupled to the memory, the processor configured to: Generating a plurality of fungible tokens associated with a plurality of fungible assets, a first fungible token in the plurality of fungible tokens being of the same type as a second fungible token in the plurality of fungible tokens, the plurality of fungible tokens collectively representing the plurality of fungible assets on a distributed ledger-based network; Dividing the plurality of fungible tokens into a first plurality of fungible token groups; sending, via a distributed ledger-based network, each of a first plurality of homogenous token groups to (1) a communication device associated with the homogenous token group and (2) from a first plurality of communication devices, the first plurality of homogenous token groups being divided into a second plurality of homogenous token groups and received at a second plurality of communication devices, the second plurality of communication devices being at a different level in a data transmission order than the first plurality of communication devices; as well as receiving a plurality of non-fungible tokens from a second plurality of communication devices, each non-fungible token including (1) a transaction destination uniquely identifying the plurality of transaction destinations and (2) an identifier from the plurality of identifiers, each non-fungible token being associated with a group of fungible tokens from the second plurality of groups of fungible tokens, in: For each of the first plurality of fungible token groups, the processor is configured to calculate a fungible token commitment by using the fungible token group, a public key of an asymmetric encryption key pair associated with a transaction initiating communication device, and a random number as inputs to a hash function.

28. The method of claim 4, wherein: For each fungible token group in the first plurality of fungible token groups, computing a fungible token commitment includes using the fungible token group, a public key of an asymmetric encryption key pair associated with a transaction initiating communication device, and a random number as inputs to a hash function.

29. The processor-readable non-transitory medium of claim 14, wherein: The code causing the processor to calculate a fungible token commitment includes code causing the processor to perform the following operations: for each fungible token group in the first plurality of fungible token groups, use the fungible token group, a public key of an asymmetric encryption key pair associated with a transaction initiating communication device, and a random number as inputs to a hash function.

30. A processor-readable medium storing code representing instructions to be executed by a processor, the code comprising code causing the processor to: storing, at a transaction initiating communication device, data associated with a plurality of asset shares from a plurality of fungible assets; At a processor of the transaction initiating communication device, dividing a plurality of homogeneous tokens into a first plurality of homogeneous token groups based on the data, each asset share in the plurality of asset shares being associated with a communication device in the first plurality of communication devices, the plurality of homogeneous tokens collectively representing the plurality of homogeneous assets on a distributed ledger-based network; From a transaction initiating communication device and via a distributed ledger-based network, each of a first plurality of homogeneous token groups is sent to a communication device (1) associated with the homogeneous token group and (2) from the first plurality of communication devices, the first plurality of homogeneous token groups are divided into a second plurality of homogeneous token groups and received at the second plurality of communication devices, so that the second plurality of communication devices send a plurality of non-homogeneous tokens of each of the second plurality of homogeneous token groups to a designated recipient communication device, the second plurality of communication devices being at a different level than the first plurality of communication devices in terms of the order of data transmission, the second plurality of communication devices not including the transaction initiating communication device.

31. The processor readable medium of claim 30, wherein: Each non-fungible token of the plurality of non-fungible tokens includes ownership information associated with a transaction destination, wherein the transaction destination is (1) associated with the non-fungible token and (2) from the plurality of transaction destinations.

32. The processor readable medium of claim 30, wherein: Each communication device of the second plurality of communication devices has a direct account relationship with at least one transaction destination of the plurality of transaction destinations.

33. The processor readable medium of claim 30, wherein: The code sent includes code sent using a zero-knowledge proof protocol by performing the following operations for each fungible token group in the first plurality of fungible token groups: Determining a fungible token commitment based on (1) the fungible token set, (2) a public key of an asymmetric encryption key pair associated with a transaction initiating communication device, (3) a random number, and (4) a hash function; and The fungible token group is sent by sending a fungible token commitment.

34. The processor readable medium of claim 30, wherein: The transaction initiation communication device is associated with the issuer of the financial instrument; Each transaction destination of the plurality of transaction destinations is associated with an owner of a subset of financial instruments who is entitled to receive the subset of financial instruments at a specified point in time.

35. The processor readable medium of claim 30, wherein: The designated recipient communication device is the transaction initiating communication device; The code also includes code that causes the processor to: A chain of custody for the plurality of homogenous assets is determined based on the plurality of non-homogeneous tokens, the chain of custody starting at a transaction initiating communication device and ending at a second plurality of communication devices, the chain of custody for each homogenous token group in the second plurality of homogenous token groups being stored in an instance of a distributed ledger database associated with a distributed ledger-based network.

36. A processor-readable medium storing code representing instructions to be executed by a processor, the code comprising code causing the processor to: Generating a plurality of fungible tokens associated with a plurality of fungible assets, the plurality of fungible tokens collectively representing the plurality of fungible assets on a distributed ledger-based network; Dividing the plurality of fungible tokens into a first plurality of fungible token groups; sending, via a distributed ledger-based network, each of a first plurality of homogenous token groups to (1) a communication device associated with the homogenous token group and (2) from a first plurality of communication devices, the first plurality of homogenous token groups being divided into a second plurality of homogenous token groups and received at a second plurality of communication devices that differ in a data transmission order from the first plurality of communication devices; as well as A plurality of non-fungible tokens are received from a second plurality of communication devices, each non-fungible token comprising (1) a transaction destination uniquely identifying one of a plurality of transaction destinations and (2) an identifier from a plurality of identifiers, each non-fungible token in the plurality of non-fungible tokens being associated with a group of homogeneous tokens in a second plurality of groups of homogeneous tokens.

37. The processor readable medium of claim 36, wherein: The plurality of non-fungible tokens are generated based on a second plurality of homogenous token groups and include information of the second plurality of homogenous token groups.

38. The processor readable medium of claim 36, wherein: The processor is configured to send code including code for sending each of the first plurality of fungible token groups via a distributed ledger-based network using a zero-knowledge proof protocol.

39. A processor-readable medium storing code representing instructions to be executed by a processor, the code comprising code causing the processor to: receiving, at a processor of a communication device, a plurality of fungible tokens, the communication device storing account identifiers associated with transaction destinations of a plurality of transaction destinations; generating, at a processor of the communication device and based on the plurality of fungible tokens, a non-fungible token having (1) an account identifier that uniquely identifies a transaction destination, (2) a value representing a quantity of the plurality of fungible tokens, and (3) characteristic information associated with the transaction destination; and Sending a non-fungible token to a processor of a designated recipient communication device via a distributed ledger-based network to establish a chain of custody of the plurality of fungible tokens, the chain of custody starting from a transaction initiating communication device and ending at a plurality of communication devices including the communication device, the plurality of communication devices not including the transaction initiating communication device or the transaction destination.

Images