HK40000504A - Digital property management on a distributed transaction consensus network - Google Patents

Description

Digital property management for distributed transaction consensus networks

RELATED APPLICATIONS

This application claims the benefit of provisional application No. 62/366,119 entitled "blockchain alliance-based multi-currency clearing and settlement" filed on 25/7/2016, which is hereby incorporated by reference in its entirety.

Technical Field

The present invention relates generally to systems, apparatuses, computer-readable media and methods for digital property management, including clearing and settling transactions using encryption techniques in a distributed transaction consensus network.

Background

Clearing and settling of financial transactions is time consuming and expensive, particularly in relation to international transactions. Traditionally, financial institutions rely on a central clearing house to handle clearing and settlement. In recent years after the introduction of bitcoin in 2009, relatively fast clearing and settlement using cryptocurrency in decentralized, distributed and peer-to-peer networks became available, but has not yet been widely adopted. Since then, many cryptocurrencies have become available, such as Leide, New Star, Domain, Multi-gigabit, Point, Ethernet, and Rebo.

Digital currency, such as bitcoin, is generated computationally by the issuer (coinage). The digital currency may be stored in a virtual wallet that may employ software and/or hardware technology. The owner needs a private key (usually stored separately) to spend digital currency. For different currencies or cryptocurrencies, one may purchase (e.g., purchase dollars at an ATM or exchange), sell (e.g., for goods and/or services), trade, or exchange digital currency. Transactions using digital currency, such as money transfers, are typically conducted by: (1) the sender redeems dollars for bitcoins, (2) transfers bitcoins from the sender's virtual wallet to the receiver's virtual wallet, and (3) the receiver redeems bitcoins back to dollars. However, the exchange rate of digital currency, such as bitcoins, can fluctuate widely and cause unexpected losses. Additional fees may also be incurred per redemption. Furthermore, the fact that the private key of the virtual wallet may be stolen or lost will seriously threaten transactions that rely on this digital currency.

Disclosure of Invention

The present invention is directed to a method and related apparatus and computer-readable medium for digital property management, including clearing and settling transactions of digital properties using encryption techniques in a distributed transaction consensus network.

It is an object of the present invention to immediately clear and settle transactions between two virtual wallets, a first virtual wallet owned by a customer of a first digital property issuer and a second virtual wallet owned by a customer of a second digital property issuer. Each digital property issuer may issue its own digital property. However, each virtual wallet can only store digital property issued by the digital property issuer associated with the virtual wallet. Thus, no additional action is required for clearing and settlement between the virtual wallet owner (the customer who is the sender or recipient) and its associated digital property issuer when the transaction is completed. Once the transaction is completed, the virtual wallet owner can immediately spend his/her digital property or convert it to substantive property at his or her discretion without waiting for clearing and settlement.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure and method particularly pointed out in the written description and claims hereof as well as the appended drawings.

To achieve these and/or other objects, as embodied and broadly described, the present invention provides a method applied in a distributed transaction consensus network. The method comprises the following steps: (a) receiving a transaction request over a distributed transaction consensus network to transfer a first type of digital property issued by a first digital property issuer from a first virtual wallet associated with the first digital property issuer to a second virtual wallet associated with a second digital property issuer, (b) causing the second virtual wallet to receive a second type of digital property issued by the second digital property issuer; and (c) recording the requested transaction in the distributed account-splitting account. The first type of digital property may be the same as the second type of digital property.

Additionally, the present invention provides 3 sub-transaction flows to complete a transaction between two virtual wallets, which includes (b1) transferring a first type of digital property issued by a first digital property issuer from a first virtual wallet owned by a first subscriber to a first virtual fund vault owned by the first digital property issuer; (b2) transferring a first type of digital property issued by a first digital property issuer or a second digital property issuer from a first virtual fund vault to a second virtual fund vault owned by a second digital property issuer; and (b3) transferring the second type of digital property issued by the second digital property issuer from the second virtual fund vault to a second virtual wallet owned by the second subscriber.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed

Drawings

Fig. 1 is a schematic diagram illustrating a distributed transaction consensus network.

Fig. 2 is a block diagram illustrating an exemplary node of the network described above.

Fig. 3 is a block diagram showing a digital property issuer, a virtual fund vault, a subscriber, and a virtual wallet.

Fig. 4 is a schematic diagram illustrating an exemplary network device.

FIG. 5 is a table illustrating an example of a coinage transaction.

Fig. 6A to 6C are tables showing examples of data structures for coinage transactions.

FIG. 7 is a table illustrating an example of a deposit transaction.

Fig. 8 is a table illustrating an example of a money transfer transaction between two virtual wallets.

Fig. 9A-9C are tables illustrating examples of data structures for money transfer transactions between two virtual wallets.

Fig. 10 is a table illustrating an alternative manner of money transfer transactions described in fig. 8.

Fig. 11 is a table illustrating another alternative to the money transfer transaction depicted in fig. 8.

Fig. 12 is a table illustrating another example of a money transfer transaction between two virtual wallets.

FIG. 13 is a table showing an example of risk limits set in some digital property issuers.

FIG. 14 is a table showing 4 examples of sub-transactions between two digital property issuers with risk limits.

FIG. 15 is a table showing an example of setting all risk limits for a particular type of digital property held by a particular digital funds repository issuer to zero.

Detailed Description

The terminology used in the description presented below is intended to be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific embodiments of the technology. Certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be specifically defined in this detailed description section.

The embodiments described below may be implemented by programmable circuitry programmed or configured by software and/or firmware, or by dedicated circuitry entirely, or by a combination of these forms. Such application-specific circuitry, if present, may be in the form of, for example, one or more application-specific integrated circuits (ASICs), Programmable Logic Devices (PLDs), field-programmable gate arrays (FPGAs), or the like.

The described embodiments relate to one or more methods, systems, apparatus, and computer-readable media storing processor-executable process steps for managing digital properties, including immediately clearing and settling a transaction for digital properties between two virtual wallets based on encryption techniques in a distributed transaction consensus network to eliminate the risk, complexity, and time consumption associated with conventional clearing and settling procedures. Various encryption algorithms known to those of ordinary skill in the art may be used.

In one embodiment, as shown in fig. 1, a distributed transaction consensus network 100, referred to in this disclosure as a TBCA (B1ockChain Alliance) network, is implemented using encryption techniques to manage digital property, in particular, to greatly simplify the clearing and settlement flow of transactions. TBCA network 100 includes a plurality of nodes, including administrator 110, digital property issuers 120, 130, 140, 150, miners 130, 140, 160, 170, and other nodes 180, 190. As shown in FIG. 2, each node generally includes a processor that performs computations and executes programs; a memory for storing software, programs and data; a display for communicating with a user; input/output components for communicating with users and other devices, and network components connected to a network via a wired or wireless channel.

An administrator 110 (referred to as TBCA in this disclosure) sets rules and manages TBCA network 100. The administrator 110 may issue a digital fee token, referred to in this embodiment as a T-coin ($ T). The administrator 110 has a virtual fund repository (not shown) to store digital expense tokens issued by itself or digital property issued by other digital fund repository issuers 120 to 150. The administrator 110 may allow nodes to join the distributed transaction consensus network 100(TBCA network) and become members of the network. In addition, administrator 110(TBCA) may authorize digital property issuers 120 to 150 to issue various digital properties, such as digital currency, digital securities, digital bonds, digital futures, and digital precious metals.

A digital property issuer, e.g., 120, 150, may issue its own digital property. In one embodiment, the digital property issuer may be a bank, such as a U.S. Bank ("BOA") or a general bank; investment/trade institutions, such as fuda or prosperous; or a telecommunications operator, such as AT & TInc (ATT), soft silver consortium (SBT), or china telecom. In one embodiment, the digital property may be any of digital currency, digital securities, digital bonds, digital futures, digital precious metals, and digital expense tokens. As shown in FIG. 3, digital property issuers 120, 150 may each have a virtual fund store 121, 151 to store various digital properties issued by themselves, other digital property issuers, or administrators 110. Each virtual fund vault has a virtual fund vault ID, which in some embodiments may be a virtual fund vault address. In addition, each virtual fund vault has a public key and a private key. To spend the digital property stored in the virtual fund vault, the digital property issuer must sign the transaction using a private key associated with the virtual fund vault.

Miners 130, 140, 160, 170 may record verified transactions (open to the TBCA network 100 members/nodes) in a distributed branch account. In exchange for the services provided by the miners, the miners may receive rewards, such as T coins issued by the administrator 110(TBCA) and/or digital property issued by the digital property issuer, which may be stored in the miners' virtual fund banks (not shown). Distributed account-splitting is essentially a digital property database or data structure that can be shared across a distributed consensus network of multiple nodes at various sites, geographic locations, or institutions. All nodes within the network may have their own copies of the account-book. Any changes to the account book are reflected in all copies in a few minutes (or in some cases a few seconds). The security and accuracy of the digital property stored in the ledger is maintained cryptographically by using keys and signatures to control who can perform what operations in the distributed ledger. In an embodiment, a blockchain data structure is used for distributed account-splitting. Miners may create new blocks to record verified transactions and then propagate the new blocks to other nodes of the network. However, the distributed account-splitting may use any other data structure known to those of ordinary skill in the art.

To maximize the throughput of new block generation so that TBCA network 100 may complete a large number of transactions instantaneously, administrator 110 may manage the number of miners and/or set rules for miners to compete with each other and/or support and/or designate one or more miners to generate new blocks for recording transactions. Digital property issuers 130, 140 may also be miners. Other nodes 180, 190 may be allowed to join TBCA network 100 for other functions. For example, they may be verifiers to verify transactions and blocks, and then store a full or partial copy of the distributed account book.

A customer of a digital property issuer (referred to as a "subscriber") may open and own one or more virtual wallets associated with the digital property issuer. Each virtual wallet has a virtual wallet ID, which may be a virtual wallet address in some embodiments. In addition, each virtual wallet has a public key and a private key. To spend the digital property stored in his or her virtual wallet, the subscriber must sign the transaction using a private key associated with the virtual wallet. A subscriber may open and own a virtual wallet at one or more digital property issuers. In one embodiment as shown in fig. 3, a subscriber (e.g., an individual, investor, and/or trader) is provided with a virtual wallet 122, 152 to store, transmit, receive, and manage digital property, including various types of digital assets, credits, and liabilities, such as digital currency, digital securities, digital bonds, digital futures, digital precious metals, and digital expense tokens. In one embodiment, the virtual wallet may be an electronically maintained data file that may include authentication information, usage rules, sub-wallets (e.g., for separately maintaining digital currency related information, digital security related information, digital bond related information, and digital futures related information). Further, the subscriber may establish rules for the virtual wallet to facilitate electronic transactions.

Each virtual wallet 122, 152 is associated with a digital property issuer 120, 150 and may be identified by a virtual wallet ID (or address in some embodiments, e.g., 1F1tAaz5 xlhuxcntcnlbtmdqw 6o5GNn4xq and 16ULZUJwv1HZJkFrs8aa9c3 xhtjaytns). In one embodiment, virtual wallet 122 can only store, transmit, receive, and manage various digital properties issued by digital property issuer 120 associated with virtual wallet 122, but not digital properties issued by other digital property issuers.

Each transaction is recorded by the miners in a distributed account which is open to other nodes within TBCA network 100. In one embodiment, the distributed account-splitting includes blocks in a chain. Each block is identified by a block hash (block hash) formed by hashing (hash) the block header twice by the SHA256 cryptographic algorithm. In addition, each block is referenced back to the previous block (called the parent block) by a "previous block hash" field in the block header. Thus, the hash sequence links each chunk to its parent chunk to create a chain that returns all the way to the first chunk created. When these blocks are stacked on top of each other, reverse trading becomes exponentially more difficult. Thus, the transactions recorded in the block become more and more trusted over time. Depending on the size of the block and the transactions, an average block may contain hundreds of transactions. The complete and up-to-date distributed sub-accounts are stored in a database (or file) of nodes allowed by administrators, digital property issuers, miners and other administrators 110 to store such sub-accounts ("(whole node).

As shown in fig. 3, a customer of a digital property issuer may request transactions processed and recorded by TBCA network 100 via a network device (connected to any internet connection via a mobile, WiFi, or wired channel), such as a server, desktop computer, laptop computer, tablet computer, cell phone, landline phone, and PDA. In one embodiment, the basic building block for digital property transactions is the unspent transaction output ("UTXO"). UTXO is an indivisible piece of digital property that is locked by a private key to a particular virtual wallet or vault and may be any value. The customer's virtual wallet may include many UTXOs from hundreds of previous transactions recorded in the block. The customer may request a transaction to transfer the digital property of a particular value to a restaurant, for example, for a meal fee. The transaction may include one or more transaction inputs from the customer's virtual wallet (input UTXO) and one or more transaction outputs to the receiving virtual wallet (output UTXO), such as meal values paid to the restaurant and change to the customer). The transaction inputs are pointers to the UTXO that were generated from previous transactions and have never been spent before. The transaction output is a UTXO that is locked to receive the virtual wallet, which may be spent by its owner in the future. As a general rule, the sum of the transaction input values should be equal to the sum of the transaction output values. No value should be generated or lost in a conventional digital property transaction. Exceptions include, but are not limited to, coinage transactions by digital property issuers to issue new digital properties, and risk limit transactions by digital property issuers to set risk limits for holding certain types of digital properties issued by other digital property issuers.

In one embodiment, the customer's transaction request is sent to a wallet server, which collects all necessary information and sends it to the middleware. The middleware constructs the original transaction and sends it back to the wallet server, which then sends it to the key server using the private key of his or her virtual wallet for customer signing. The wallet server passes the signed transaction back to the middleware, which propagates the transaction to TBCA network 100. The wallet server, key server, and middleware are software that facilitates the transaction. Upon receiving the transaction, nodes on TBCA network 100 (including digital property issuers and miners) will independently verify and validate the transaction and then add the validated transaction to the transaction repository. Each node verifies each transaction independently using the same criteria before propagating further. The miners will create new blocks that extract the transactions from the transaction repository. After the new block is verified and validated, the miners then propagate the new block to other nodes. After receiving the new block, the nodes on TBCA network 100 will independently verify and validate the new block using the same criteria. Once the node verifies the new block, the node connects the new block to the existing blockchain. The new owner may then spend the UTXO output from these transactions. Eventually, unless TBCA network 100 is attacked, disconnected, or fails, each complete node on TBCA network 100 will have a copy of the same split account or blockchain. The consensus that multiple nodes (each independently validating the same transaction and/or block using the same criteria) are required to agree on a distributed account is a mechanism to enhance transaction security. The more nodes a distributed transaction consensus network needs to achieve consensus, the more secure the network. Whether consensus is achieved may be determined by various rules and/or algorithms known to those skilled in the art. In one embodiment, when a bifurcation occurs, consensus may be achieved by comparing the length (or depth) of the blocks in the chain with the bifurcation wins with longer chains, such as by an algorithm employed in bitcoin networks. The more computationally intensive a miner or a group of miners has, the more blocks they can generate under the working demonstration methodology. In other words, blocks that are commonly accepted by miners or miners with most computing power will become a consensus that is adopted later by other nodes. In another embodiment, a consensus may be reached by most miners. Thus, blocks verified by most miners will be propagated to other nodes for verification and logging. As a distributed transaction consensus network, TBCA network 100 needs to agree on each transaction and then record each transaction separately in a distributed account stored in a plurality of nodes.

As previously mentioned, each virtual wallet is associated with a particular digital property issuer, which may be a bank, financial institution, stock exchange, investment company, telecommunications carrier, or the like. Each virtual wallet has a unique virtual wallet ID in TBCA network 100. For example, as a subscriber, Mary may have multiple virtual wallets, each identified by a virtual wallet ID, and associated with the united states banking ("BOA"), fuda, or prosperous, respectively, via an account number, or AT & time (ATT), soft silver group (SBT), or chinese telecommunications via a telephone number. In one embodiment, each virtual wallet can only store digital property issued by the digital property issuer associated with the virtual wallet. For example, Mary's U.S. bank-related virtual wallet can only store digital property issued by the U.S. bank; mary's ATT-related virtual wallet can only store digital property issued by ATT.

Each digital property issuer may issue various different types of digital properties, such as digital currencies, e.g., digital dollars, digital yen, digital euro, and digital new taiwan currency; digital securities, such as digital Apple stock, digital Google stock, and digital mutual funds; digital precious metals such as digital gold, digital platinum, and digital silver; and digital futures, such as digital futures for coffee beans, soybeans, and corn. Each digital property is characterized by a combination of the type of digital property and its issuer. In one embodiment, the combination may be a symbol of the type of digital property followed by a symbol of the issuer of the digital property with an English period separating the two symbols. In one example, a U.S. bank (labeled "BOA") may issue a digital dollar (labeled "$ USD") and a digital yen (labeled "$ JPY"), which in this embodiment may be identified as $ USD. BOA (in this embodiment, 1$ USD. BOA is worth $ 1) and $ JPY. BOA (in this embodiment, 1$ JPY. BOA is worth $ 1 yen). In another example, fuda (which is labeled "FDT") may release digital Apple and digital Google stocks, which in this embodiment may be identified as aapl.fdt (in this embodiment, 1aapl.fdt has a value of 1 Apple stock) and goog.fdt (in this embodiment, 1goog.fdt has a value of 1 Google stock). High prosperity ("GMS") may issue digital gold with 24 carat purity (denoted "GLD 999") and digital platinum with 999 purity (denoted "PTN 999"), which in this example may be identified as GLD999.GMS (in this example, 1 gram of gold with 24 carat purity is worth 1 gram of gold) and PTN999.GMS (in this example, 1 gram of platinum with 999 purity is worth 1 gram of platinum).

In one embodiment, a Fun Coin (FC) field is used to indicate the type of digital property and its issuer. For example, FC equals 10 to indicate a numerical dollar ($usd.sbt) issued by SBT; FC equals 11 to indicate the digital yen issued by SBT ($ jpy. FC equals 20 to indicate the number dollar ($ usd. ATT) issued by ATT; FC equals 21 to indicate the digital yen ($ jpy. In addition to the value (or amount or unit of the digital property), each output UTXO also includes an FC field indicating the type of digital property and its issuer.

The digital property issuer can determine the actual financial value of the digital property issued thereby. In one embodiment, the financial value of the digital property is only recognizable by its issuer. Thus, the owner of the digital property can only ask its issuer for its financial value. In such embodiments, the digital property functions similarly to a digital property issuer's credit (referred to as "encrypted credit") to an owner or other digital property issuer who receives the digital property.

Each digital property issuer may have a virtual fund vault to store digital properties issued by itself, other digital property issuers, and administrator 110, including various types of digital assets and liabilities, such as digital currency, digital securities, digital bonds, digital futures, digital precious metals, and digital expense tokens. For example, the U.S. bank's virtual fund vault may store digital dollars issued by itself ($ usd.boa) and digital yen issued by the tokyo mitsubishi UFJ bank ("BTMU") ($ jpy.btmu).

The described embodiments can greatly reduce the effort of clearing and settlement in transactions between two virtual wallets. Because each virtual wallet can only store digital property issued by the digital property issuer associated with the virtual wallet, no additional operations are required for clearing and settlement between the virtual wallet owner (sender or recipient) and its associated digital property issuer when the transaction is completed. Thus, the virtual wallet owner need not wait for clearing and settlement when he/she wants to spend his/her digital property or convert it to a substantive property. Further, because the amount of the digital property issued by the first digital property issuer and stored in the virtual fund vault of the second digital property issuer is only reflective of the liability of the first digital property issuer to the second digital property issuer and vice versa, no additional action is required for clearing between digital property issuers. And the first digital property issuer can redeem the digital property (issued by the first digital property issuer) from the second digital property issuer at any time to settle the liability (if any) therebetween. In the event that the virtual fund vault of the second digital property issuer needs to transfer the digital property to the virtual fund vault of the first digital property issuer, the virtual fund vault of the second digital property issuer will preferentially transfer (offset) the digital property issued by the first digital property issuer, if possible; and then transfers the remaining amount/value of the digital property issued by itself (the second digital property issuer). Thus, the credit or debt, if any, between the first digital property issuer and the second digital property issuer will be kept at a minimum amount. In this way, digital property issuers can minimize the digital property they own that is issued by other digital property issuers.

In a first embodiment (coinage transaction), shown in FIG. 5, ATT issues (coinage) 3,100 units of digital dollars (3,100$ USD. ATT) and 31,000 units of digital yen (31,000$ JPY. ATT) stored in the ATT virtual funding library with the administrator's permission; SBT issues 4,200 units of digital dollars (4,200$ usd. SBT) and 42,000 units of digital yen (42,000$ jpy. SBT).

To cast a digital property, first, a digital property issuer must grant permission to cast a particular type of digital property. In some cases, the coinage permit may limit the amount (value) of the type of digital property to be cast. In one embodiment, the administrator 110 must create an administrator token UTXO that can be used as an input UTXO in special license transactions. In this license transaction, the output UTXO is created as a virtual fund vault to the recipient digital property issuer, where the FC field indicates the particular type of digital property that it is permitted to cast. After the approval transaction is built and signed, the middleware sends it to TBCA network 100, and miners of network 100 record the approval transaction into new blocks. The digital property issuer may then send a coinage request to the wallet server, which then sends the necessary information to the middleware to generate the original transaction. The original transaction is then sent to the wallet server, which passes the original transaction to the key server for signing with the private key of the virtual funding vault. After the original transaction returns, the middleware sends it to TBCA network 100. If the digital property issuer has the appropriate coinage permit, the mineworker records the new coinage transaction in a block. Otherwise, the miners of TBCA network 100 will refuse the coinage transaction. Fig. 6A-6C illustrate embodiments of data structures for coinage transactions and transaction inputs and outputs thereof. The coinage transaction has a free entry UTXO list because a new digital property is being created. However, the transaction input has an unlock script that contains a signature and public key of a virtual fund vault of a digital property issuer that can cast the new digital property. The output UTXO of the coinage transaction has a value and FC indicative of the amount and type of digital property to be coined and contains a script that locks the output UTXO to a virtual fund vault of an issuer of the digital property of the coinage. In the above embodiment, the ATT issues 3,100 units of digital dollars (3,100$ usd. ATT) and 31,000 units of digital yen (31,000$ jpy. ATT) stored in the ATT's virtual fund repository. ATT requires two coinage licenses to complete the two coinage transactions of digital dollars and digital yen, respectively. After TBCA network 100 records two coinage transactions in a new block (or two blocks), the ATT's virtual fund vault has two outputs UTXO, a first output value of 3,100 and FC of 20, and a second output value of 31,000 and FC of 21.

In a second embodiment (deposit transaction), Mary purchases 100$ usd. ATT and 1,000$ jpy. ATT from ATT, and then stores them in her virtual wallet 122 (associated with ATT), where the ID # (address) is 1F1tAaz5 xlhuxrcnlbttmdqcw 6o5GNn4 xq; joe purchases 200$ usd.sbt and 2,000$ jpy.sbt from SBT and then stores them in his virtual wallet 152 (associated with SBT), where the ID # (address) is 16ULZUJwv1HZJkFrs8aa9c3 xhtjiaytns. As shown in fig. 7, after the transfer, the virtual fund repository of the ATT stores 3,000 digital dollars (3,000$ usd. ATT) issued by the ATT and 30,000 digital yens (30,000$ jpy. ATT) issued by the ATT. The SBT's virtual fund repository stores 4,000 digital dollars issued by SBTs (4,000$ usd.sbts) and 40,000 digital yens issued by SBTs (40,000$ jpy.sbts). Mary's virtual wallet contains 100 digital dollars (100$ usd. ATT) issued by ATT and 1,000 digital yen (1,000$ jpy. ATT) issued by ATT. Joe's virtual wallet contains 200 digital dollars (200$ usd. SBT) issued by SBT and 2,000 digital yen (2,000$ jpy. SBT) issued by SBT.

In the above deposit transaction, Mary purchases 100$ usd. ATT and 1,000$ jpy. ATT from ATT, which are deposited into her virtual wallet 122 (associated with ATT). To complete the deposit transaction, Mary's wallet sends two deposit requests to the wallet server, including a first deposit request of 100$ usd. The first credit request (including information for the value 100, FC 20, and Mary's virtual wallet ID) is sent to the middleware, which then builds the original transaction and sends it back to the wallet server. The wallet server passes the original transaction to the key server to sign its private key to the ATT's virtual funds repository, and then sends the signed transaction back to the middleware. The middleware propagates the signed deposit transaction to TBCA network 100, which miners of network 100 verify and record the deposit transaction into new blocks. The input UTXO for the first deposit transaction is the output UTXO for the ATT coinage transaction. The first deposit transaction has two outputs UTXO. The first output UTXO for the first deposit transaction has a value of 100, FC of 20 and has a script that locks the UTXO to Mary's virtual wallet. The second output UTXO has a value of 3000, FC of 20 and has a script that locks the UTXO to the virtual fund library of the ATT. The second credit request (including information for the virtual wallet ID with value 1000, FC 21, and Mary) is sent to the middleware, which then builds the original transaction and sends it back to the wallet server. Through a similar process, the miners of TBCA network 100 record a second deposit transaction into a new block. The input UTXO for the second deposit transaction is another output UTXO from the ATT coinage transaction. The second deposit transaction also has two outputs UTXO. The first output UTXO for the second deposit transaction has a value of 1000, FC of 21 and has a script that locks the UTXO to Mary's virtual wallet. The second output UTXO has a value of 30000, FC of 21 and has a script that locks the UTXO to the virtual fund library of the ATT. Upon completion of the deposit transaction, Mary can spend these output UTXOs immediately.

In one embodiment, Mary wants to send Joe some money. Mary may specify the type and amount of digital property she wants to send to Joe from her virtual wallet. In addition, Mary may specify the type of digital property Joe will receive. In a third embodiment (money transfer transaction), Mary may request (1) transfer of 50 digital dollars (50$ usd. ATT) issued by ATT from her own virtual wallet to Joe, and (2) Joe receive digital dollars issued by SBT. (the amount of digital yen stored in each virtual wallet and virtual fund vault will be omitted in the following description since only digital dollars are involved in the transaction). To complete the transaction, a 3-step (3 sub-transaction) flow is implemented, as shown in fig. 8, so that Joe will receive the number dollar ($ usd. The 3 sub-transactions that complete the money transfer transaction are collectively referred to as the transaction set. (note that TBCA network 100 may treat each sub-transaction as a transaction in some cases). The first step (first sub-transaction) is to transfer the 50-digit dollar (50$ usd. ATT) issued by ATT at Mary's virtual wallet to ATT's virtual fund vault. Thus, Mary's virtual wallet contains 50$ usd.att, while ATT's virtual fund vault contains 3,050$ usd.att. The second step (second sub-transaction) is that the ATT's virtual fund vault transfers the 50-digit dollar (50$ usd. ATT) issued by the ATT to the SBT. ATT's virtual funds therefore comprise 3,000$ usd. The virtual wallet of SBT contains 50$ usd.att and 4,000$ usd.sbt. The third step (third sub-transaction) is that the SBT's virtual funder transfers the 50-digit dollar (50$ usd. SBT) issued by the SBT to Joe's virtual wallet. Thus, the SBT's virtual fund vault contains 50$ usd.att and 3,950$ usd.sbt. Joe's virtual wallet contains 250$ usd.

In the money transfer transaction described above, Mary transfers its 50$ usd. ATT in its ATT-related virtual wallet to Joe's virtual wallet related to SBT. To complete the money transfer transaction, three sub-transactions (transaction sets) must be validated and confirmed in their entirety. If one sub-transaction is rejected, all three sub-transactions must be rejected. Fig. 9A-9C illustrate embodiments of data structures and transaction inputs and outputs for money transfer transactions. The first sub-transaction has an input UTXO from Mary's virtual wallet with a value of 100 and FC of 20, and two output UTXOs, the first output UTXO having a value of 50 and FC of 20, locked to ATT's virtual fund library, and the second output UTXO (change back to Mary) having a value of 50 and FC of 20, locked to Mary's virtual wallet. The second sub-transaction has an input UTXO from the virtual fund pool of the ATT (where the value is 3000 and FC is 20) and two output UTXOs, the first output UTXO having a value of 50 and FC is 20, locked to the virtual fund pool of the SBT, and the second output UTXO (modified back to ATT) having a value of 2,500 and FC is 20, locked to the virtual fund pool of the ATT. The third sub-transaction has an input UTXO from the SBT virtual fund vault (where the value is 4,000 and FC is 10), and two output UTXOs, the first output UTXO having a value of 50 and FC is 10, locked to Joe's virtual wallet, and the second output UTXO (changed back to SBT) having a value of 3,500 and FC is 10, locked to SBT's virtual fund vault. With all necessary information, the middleware builds 3 original sub-transactions and sends them to the wallet server, which further passes them to the key server to obtain the appropriate signature. The wallet server sends the 3 signed sub-transactions back to the middleware, which propagates them to TBCA network 100. The miners will verify and validate the 3 sub-transactions and only write a new block if all three sub-transactions are validated. The new block will then propagate to other nodes, which will cause those nodes to independently validate the new block with the same criteria. Ultimately, the account of each node will include a new block to record the money transfer transaction. Joe can immediately spend the newly received 50 digit dollars.

In a fourth embodiment, ATT may charge Mary a transaction fee that may be deducted from the 50$ usd. ATT taken from Mary's virtual wallet (Joe will receive less money) or charged additionally and separately to Mary's virtual wallet. Similarly, the SBT may charge Joe a transaction fee, which may be deducted from the amount of digital dollars received by Mary (Joe will receive less money), or a separate and additional charge for Joe's virtual wallet. Further, the administrator 110(TBCA) may charge the ATT and SBT a transaction fee, which may be paid by the T-currency issued by the administrator 110 in this embodiment. In addition, miners creating new blocks for recording transactions may be rewarded with T coins issued by the administrator 110. Several measures may be taken to complete the transaction, with the transaction fees paid to the ATT, SBT, miners, and/or administrators. First, the value of the input UTXO or the output UTXO may be adjusted accordingly to reflect the transaction fee. Second, one or more output UTXOs with transaction fee values may be added to the appropriate sub-transactions. Still further, if an individual miner or administrator 110 also charges a transaction fee, one or more sub-transactions may be added to the transaction set.

In a fifth embodiment, Mary may request (1) transfer of 50 digital dollars (50$ usd. ATT) issued by ATT to Joe from her own virtual wallet, and (2) Joe receive digital yen. To complete the transaction, Mary may redeem her digital dollars for digital yen at the ATT's virtual fund vault. Assuming that the exchange rate of 105 digital yen is 1 digital dollar, the virtual fund vault of ATT will extract 50$ usd. Mary may then request (1) transfer of 5,250 digital yens issued by ATT (5,250$ jpy. ATT) to Joe from her own virtual wallet, and (2) Joe receives the digital yens. The money transfer transaction may be completed according to a similar process as described in the third embodiment. Alternatively, as shown in FIG. 10, a 3-step (3-sub-trade) flow is implemented so that Joe will receive the digital yen ($ JPY. SBT) issued by the SBT without prior exchange. The first two steps may be the same as those in the third embodiment. In the third step (third sub-transaction), the SBT's virtual fund vault transfers the 5,250 digital yen (5,250$ jpy. SBT) issued by the SBT to Joe's virtual wallet (using the above-mentioned exchange rate). As another alternative, as shown in fig. 11, in the second step (second sub-transaction), the ATT's virtual fund library may transfer 5,250 digital yen (5,250$ jpy. ATT) issued by the ATT, instead of 50 digital dollars (50$ usd. ATT), to the SBT's virtual fund library. In fact, the ATT may pay the SBT any other type of digital property equivalent to 5,250 digital yen, as long as the SBT agrees to receive.

In a sixth embodiment after completing the transaction in the third embodiment (see fig. 8), Joe requests (1) transfer of 75-digit dollars issued by SBT (75$ usd. SBT) to Mary from his own virtual wallet, and (2) receipt of the digit dollars by Mary. (since only digital dollars are involved in the transaction, the amount of digital yen stored in each virtual wallet and virtual fund vault will be omitted in the following description). To complete the money transfer transaction, a 3-step (3 sub-transaction) process is implemented, as shown in fig. 12, so that Mary will receive the digital dollar ($ usd. The first step (first sub-transaction) is to transfer the 75-digit dollar (75$ usd. SBT) issued by the SBT in Joe's virtual wallet to the SBT's virtual fund vault. Thus, Joe's virtual wallet contains 175$ usd.sbt, while SBT's virtual funding library contains 4,025$ usd.sbt. The second step (second sub-transaction) is to return 50 digits dollars (50$ usd. ATT) issued by the ATT to the ATT for the SBT's virtual fund library and transfer 25 digits dollars (25$ usd. SBT) otherwise issued by the SBT to the ATT. Thus, the virtual fund vault of ATT contains 3,050$ usd. The virtual wallet of the SBT contains 4,000$ usd.sbt and zero $ usd.att. The third step (third sub-transaction) is that the ATT's virtual fund vault transfers the 75-digit dollar (75$ usd. ATT) issued by the ATT to Mary's virtual wallet. Thus, the virtual fund vault of ATT contains 2,975$ usd. Mary's virtual wallet contains 125$ USD.

At some time after several transactions, each virtual wallet still stores only the digital property issued by the digital property issuer associated with the virtual wallet. However, digital property issuers are likely to keep digital properties issued by other digital property issuers in their own virtual fund banks, e.g., SBT's virtual fund banks contain digital dollars ($ usd.att) issued by ATT; the virtual funds repository of the ATT contains the digital yen ($ jpy. In a next transaction, when a first digital property issuer (e.g., SBT) needs to transfer a first type of digital property (e.g., digital dollars) to a second digital property issuer (e.g., ATT), in one embodiment, the first digital property issuer (e.g., SBT) will preferentially transfer (return) the first type of digital property (e.g., $ usd. If this is not sufficient, then the first digital property issuer (e.g., SBT) transfers the remaining amount of the first type of digital property ($ USD. SBT) issued by itself to the second digital property issuer (e.g., ATT). Through this process, digital property issuers can minimize the digital property they own that is issued by other digital property issuers and minimize the risk of managing the large number of digital properties that are issued by other digital property issuers.

Additionally, in a seventh embodiment (risk limit trading), a digital property issuer may set a risk limit for a particular type of digital property issued by a particular digital property issuer. For example, SBT sets the risk limit for digital dollars issued by ATT to 1M units. Thus, when a transaction would cause a digital property issuer to hold an amount of a particular type of digital property issued by a particular digital property issuer that exceeds a risk limit, the transaction would be denied and cannot be recorded. For example, if the transaction would cause the SBT to hold $ usd. The risk limits of a digital property issuer to a particular type of digital property issued by other digital property issuers may be recorded in a distributed ledger (such as a blockchain). Thus, each complete node (including digital property issuers and miners) has a complete and up-to-date copy of the distributed account, and can independently verify whether a sub-transaction would cause the digital property issuer to exceed its risk limit. If this happens, the entire transaction set will be rejected.

FIG. 13 is an example of a risk limit array showing risk limits for various types of digital property by some digital property issuers issued by other digital property issuers. For example, SBT sets a risk limit of holding $ usd.att to 100,000 units; att set the risk limit for $ jpy to 500,000 units; ATT (digital canadian dollars issued by ATT) is set to 50,000 units of risk limit. NTT (digital dollars issued by the japanese telephone service provider NTT group) is also set to 10,000 units by SBT; ntt is set to 1M units; ntt risk limit is set to 5,000 units. Similarly, ATT sets its risk limit for holding $ usd.sbt to 500,000 units; set the risk limit for $ jpy.sbt to 1.5M units; sbt risk limit is set to 20,000 units. ATT also sets its risk limit for holding $ usd.ntt to 500,000 units; ntt is set to 1.2M units; ntt risk limit is set to 20,000 units.

In one embodiment, for a risk limit set by the digital property issuer, the digital property issuer may send a set-risk-limit request to the wallet server, which then sends the necessary information to the middleware to generate the original transaction. The original transaction is then sent to the wallet server, which passes the original transaction to the key server to sign the private key with the virtual vault. After the signed risk allowance transaction is returned, the intermediary device sends the signed risk allowance transaction to TBCA network 100 for recording into a new chunk. Like coinage transactions, risk limit transactions have a null-entry UTXO list because this setting should not use UTXO. However, the risk limit transaction enters an unlock script with a signature and public key that contains the virtual fund vault of the digital property issuer that set the risk limit. The output of the risk limit transaction UTXO has a value and FC that is indicative of the maximum dollar amount of the particular type of digital property issued by the particular digital property issuer that is to be accepted by the requesting digital property issuer. In the example where the SBT sets the risk limit holding $ USDATT to 100,000 units, the value of the risk limit transaction's output UTXO is 100,000 and FC is 20. The transaction must be signed with the private key of the SBT virtual fund vault.

FIG. 14 shows four transactions using the risk limit array described above, where two transactions have been completed and recorded and two other transactions are denied because these transactions would cause the digital property issuer to exceed the risk limit it holds for a particular type of digital property issued by another digital property issuer. In this embodiment, as shown in fig. 13, the SBT sets the risk limit for the digital dollar ($ usd. ATT) issued by the ATT to 100,000 units; the ATT sets the risk limit of the digital yen ($ jpy. SBT) issued by the SBT to 1.5M units. Before the first transaction, the ATT's virtual fund library has 1M $ USD.ATT, 3,000$ USD.SBT, 100,000$ JPY.ATT, and 1,450,000$ JPY.SBT; the virtual fund vault of the SBT has 98,000$ usd.att, 500,000$ usd.sbt, 20,000$ jpy.att, and 5M $ jpy.sbt. The first transaction request ATT transfers 4,000 digital dollars ($USD) to the SBT. ATT first transfers 3,000$ usd.sbt, and then transfers 1,000$ usd.att to SBT. Thus, the first transaction increases SBT holding $ usd.att by only 1,000 units to 99,000 units, which is still within the risk limit of 100,000$ usd.att. Thus, the first transaction is completed and recorded. The second transaction request, ATT, transfers 2,000$ USD to SBT. Since ATT does not return to SBT for $ usd. Thus, the second transaction is rejected because it will cause the SBT to hold 110,000$ usd. The third transaction request SBT transfers the 30,000 digit yen ($ JPN) to ATT. SBT first transferred 20,000$ jpy. ATT to ATT and then 10,000$ jpy. SBT to ATT. Thus, the third transaction only increases the $ jpy.sbt held by ATT by 10,000 units to 146,0000 units, still within the risk limit of 1,500,000$ jpy.att. Thus, the third transaction is completed and recorded. The fourth transaction request SBT transfers 50,000$ JPN to the ATT. Since SBT does not return ATT $ jpy. Thus, the fourth transaction is rejected because it will cause the ATT to hold 1,510,000$ jpy.sbt, which exceeds the ATT's risk limit of holding 1,500,000$ jpy.sbt.

When a particular type of digital property issued by a particular digital property issuer is compromised, e.g., the private key of the digital property is stolen or lost, the setting of the risk limit may also help manage the compromise and resolve the problem. As shown in fig. 15, in an eighth embodiment, where a particular type of digital property issued by a particular digital property issuer, e.g., a digital dollar ($ usd.att) issued by an ATT, is compromised, e.g., a private key that transfers some of the digital property is stolen, administrator 110 may set the risk limit for all digital property issuers of that type of digital property (e.g., $ usd.att) issued by that particular digital property issuer to zero, so that no digital property issuer thereafter receives the compromised digital property, e.g., $ usd.att. In the risk allowance transaction, the transaction enters an unlock script with a signature and public key containing the virtual fund vault of administrator 110; the transaction output has a UTXO with a value of zero and FC of 20. In this case, administrator 110 or the particular digital property issuer (e.g., ATT) may set the associated risk limit to zero to deny all transactions for a particular type of digital property (e.g., $ usd. The digital property issuer, e.g., ATT, may then cast a new version of the same type of digital property, such as $ usd2.ATT and credit, and, based on its subscriber information database, the appropriate amount of the new version of the digital property is transferred to its subscriber's virtual wallet to make up for any loss due to the private key being stolen or lost.

Also, the above-described digital property transaction method and related apparatus can be applied to all types of digital property, such as digital currencies, e.g., digital dollars, digital yen, digital euro, and digital new taiwan currency; digital securities, such as digital Apple stock, digital Google stock, and digital mutual funds; digital precious metals such as digital gold, digital platinum, and digital silver; and digital futures, e.g., digital futures of coffee beans, soybeans, and corn.

It will be apparent to those skilled in the art that various modifications and variations can be made in the digital property management method and related apparatus of the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims (64)

1. A method, comprising:

(a) receiving a transaction request over a distributed transaction consensus network to transfer a first type of digital property issued by a first digital property issuer from a first virtual wallet associated with the first digital property issuer to a second virtual wallet associated with a second digital property issuer;

(b) causing the second virtual wallet to receive a second type of digital property issued by the second digital property issuer; and

(c) the requested transaction is recorded in a distributed account book.

2. The method of claim 1, wherein the first type of digital property may be one of a type of digital currency, digital securities, digital bonds, digital futures, and digital precious metals; and the second type of digital property may be one of digital currency, digital securities, digital bonds, digital futures, and digital precious metals.

3. The method of claim 1, wherein the first type of digital property is the same as the second type of digital property.

4. The method of claim 1, step (b) further comprising:

(b1) transferring the first type of digital property issued by the first digital property issuer from the first virtual wallet owned by a first subscriber to a first virtual fund vault owned by the first digital property issuer;

(b2) transferring one or more selected types of digital property issued by the first digital property issuer or the second digital property issuer from the first virtual fund pool to a second virtual fund pool owned by the second digital property issuer;

(b3) transferring the second type of digital property issued by the issuer of the second digital property from the second virtual fund vault to the second virtual wallet owned by a second subscriber.

5. The method of claim 4, wherein in step (b2), the one or more selected types of digital property may be selected from any type of digital property included in the first virtual fund repository.

6. The method of claim 1, further comprising:

(b1) transferring the first type of digital property issued by the first digital property issuer from the first virtual wallet owned by a first subscriber to a first virtual fund vault owned by the first digital property issuer;

(b2) transferring the first type of digital property issued by the first digital property issuer or the second digital property issuer from the first virtual fund repository to a second virtual fund repository owned by the second digital property issuer;

(b3) transferring the second type of digital property issued by the issuer of the second digital property from the second virtual fund vault to the second virtual wallet owned by a second subscriber, wherein the second type of digital property is the same as the first type of digital property.

7. The method of claim 6, wherein, in step (b2), when the first virtual fund repository contains the first type of digital asset issued by the second digital asset issuer, the first digital asset issuer preferentially transfers the first type of digital asset issued by the second digital asset issuer from the first virtual fund repository to the second virtual fund repository; and when the first virtual fund vault does not contain the requested amount of the first type of digital property issued by the second digital property issuer, the first digital property issuer transfers from the first virtual fund vault the remaining amount of the first type of digital property issued by the first digital property issuer to the second virtual fund vault.

8. The method of claim 6 wherein the second digital property issuer sets a risk limit for holding the first type of digital property issued by the first digital property issuer.

9. The method of claim 8 wherein the transaction request is denied when the transaction will cause the second digital property issuer to hold an amount of the first type of digital property issued by the first digital property issuer that is greater than the risk limit set by the second digital property issuer.

10. The method of claim 8 wherein the risk limit of the second digital property issuer for holding the first type of digital property issued by the first digital property issuer is set to zero.

11. The method of claim 1, wherein the first virtual wallet is capable of storing one or more types of digital property issued by the first digital property issuer, but does not store any type of digital property issued by the second digital property issuer; and the second virtual wallet is capable of storing one or more types of digital property issued by the issuer of the second digital property but not any type of digital property issued by the issuer of the first digital property.

12. The method of claim 1, further comprising:

(d) charging, by the first digital property issuer, the first virtual wallet for a first transaction fee; and

(e) charging, by the issuer of the second digital property, a second transaction fee to the second virtual wallet.

13. The method of claim 1, further comprising: charging a third transaction fee to the first virtual fund repository or the second virtual fund repository by the miners generating the new block recording the transaction.

14. The method of claim 1, wherein the distributed transaction consensus network has an administrator.

15. The method of claim 14, wherein the administrator may issue the digital expense token.

16. The method of claim 15, further comprising: charging, by the administrator, a fourth transaction fee to the first virtual fund repository or the second virtual fund repository.

17. The method of claim 14, wherein the administrator can authorize the first digital property issuer or the second digital property issuer to issue one or more types of digital property.

18. The method of claim 14, wherein the administrator may authorize miners to generate new blocks of record transactions and set rules for each miner to compete with or support each other.

19. A computer program product comprising one or more computer-usable non-transitory media having computer-readable program code embodied therein for controlling a digital property management system, the computer-readable program code configured to cause the digital property management system to perform a transaction process, the process comprising:

(a) receiving a transaction request over a distributed transaction consensus network to transfer a first type of digital property issued by the first digital property issuer from a first virtual wallet associated with the first digital property issuer to a second virtual wallet associated with a second digital property issuer;

(b) causing the second virtual wallet to receive a second type of digital property issued by the second digital property issuer; and

(c) the requested transaction is recorded in a distributed account book.

20. The computer program product of claim 19, wherein the first type of digital property may be one of a type of digital currency, digital securities, digital bonds, digital futures, and digital precious metals; and the second type of digital property may be one of digital currency, digital securities, digital bonds, digital futures, and digital precious metals.

21. The computer program product of claim 19, wherein the first type of digital property is the same as the second type of digital property.

22. The computer program product of claim 19, wherein step (b) further comprises:

(b1) transferring the first type of digital property issued by the first digital property issuer from the first virtual wallet owned by a first subscriber to a first virtual fund vault owned by the first digital property issuer;

(b2) transferring one or more selected types of digital property issued by the first digital property issuer or the second digital property issuer from the first virtual fund pool to a second virtual fund pool owned by the second digital property issuer;

(b3) transferring the second type of digital property issued by the issuer of the second digital property from the second virtual fund vault to the second virtual wallet owned by a second subscriber.

23. The computer program product of claim 22, wherein in step (b2), the one or more selected types of digital property can be selected from any type of digital property contained in the first virtual fund library.

24. The computer program product of claim 19, wherein step (b) further comprises:

(b1) transferring the first type of digital property issued by the first digital property issuer from the first virtual wallet owned by a first subscriber to a first virtual fund vault owned by the first digital property issuer;

(b2) transferring the first type of digital property issued by the first digital property issuer or the second digital property issuer from the first virtual fund repository to a second virtual fund repository owned by the second digital property issuer;

(b3) transferring the second type of digital property issued by the issuer of the second digital property from the second virtual fund vault to the second virtual wallet owned by a second subscriber, wherein the second type of digital property is the same as the first type of digital property.

25. The computer program product of claim 24, wherein, in step (b2), when the first virtual funding vault includes the first type of digital property issued by the second digital property issuer, the first digital property issuer preferentially transfers the first type of digital property issued by the second digital property issuer from the first virtual funding vault to the second virtual funding vault; and when the first virtual fund vault does not contain the requested amount of the first type of digital property issued by the second digital property issuer, the first digital property issuer transfers from the first virtual fund vault the remaining amount of the first type of digital property issued by the first digital property issuer to the second virtual fund vault.

26. The computer program product of claim 24, wherein the second digital property issuer sets a risk limit for holding the first type of digital property issued by the first digital property issuer.

27. The computer program product of claim 26, wherein the transaction request is denied when the transaction will cause the second digital property issuer to hold an amount of the first type of digital property issued by the first digital property issuer that is greater than the risk limit set by the second digital property issuer.

28. The computer program product of claim 26, wherein a risk limit of said second digital property issuer for holding said first type of digital property issued by said first digital property issuer is set to zero.

29. The computer program product of claim 19, wherein the first virtual wallet is capable of storing one or more types of digital property issued by the first digital property issuer, but not any type of digital property issued by the second digital property issuer; and the second virtual wallet is capable of storing one or more types of digital property issued by the issuer of the second digital property but not any type of digital property issued by the issuer of the first digital property.

30. The computer program product of claim 19, wherein the process further comprises:

(d) charging, by the first digital property issuer, the first virtual wallet for a first transaction fee; and

(e) charging, by the issuer of the second digital property, a second transaction fee to the second virtual wallet.

31. The computer program product of claim 19, wherein the process further comprises: charging the first virtual fund repository or the second virtual fund repository a third transaction fee by a mineworker generating a new block to record the transaction.

32. The computer program product of claim 19, wherein the distributed transaction consensus network has an administrator.

33. The computer program product of claim 32, wherein the administrator can issue digital expense tokens.

34. The computer program product of claim 33, wherein the process further comprises: charging, by the administrator, a fourth transaction fee to the first virtual fund repository or the second virtual fund repository.

35. The computer program product of claim 32, wherein the administrator can authorize the first digital property issuer or the second digital property issuer to issue one or more types of digital property.

36. The computer program product of claim 32, wherein the administrator may authorize miners to generate new blocks to record the transactions and set rules for each miner to compete with or support each other.

37. A method, comprising:

(a) receiving a transaction request over a distributed transaction consensus network to transfer a first type of digital property issued by a first telecommunications carrier from a first virtual wallet corresponding to a first phone number associated with the first telecommunications carrier to a second virtual wallet corresponding to a second phone number associated with a second telecommunications carrier;

(b) causing the second virtual wallet to receive a second type of digital property issued by the second telecommunications carrier; and

(c) the requested transaction is recorded in a distributed account book.

38. The method of claim 37, step (b) further comprising:

(b1) transferring the first type of digital property issued by the first telecommunications carrier from the first virtual wallet owned by a first subscriber to a first virtual fund vault owned by the first telecommunications carrier;

(b2) transferring the first type of digital property issued by the first telecommunications carrier or the second telecommunications carrier from the first virtual fund repository to a second virtual fund repository owned by the second telecommunications carrier; and

(b3) transferring the second type of digital property issued by the second telecommunications carrier from the second virtual fund vault to the second virtual wallet owned by a second subscriber, wherein the second type of digital property is the same as the first type of digital property.

39. The method of claim 38, wherein, in step (b2), when the first virtual fund repository contains the first type of digital property issued by the second telecommunications carrier, the first telecommunications carrier preferentially transfers the first type of digital property issued by the second telecommunications carrier from the first virtual fund repository to the second virtual fund repository; and when the first virtual fund vault does not contain the requested amount of the first type of digital property issued by the second telecommunications carrier, the first telecommunications carrier transfers the remaining amount of the first type of digital property issued by the first telecommunications carrier from the first virtual fund vault to the second virtual fund vault.

40. The method of claim 38, wherein the second telecommunications carrier sets a risk limit for holding the first type of digital property issued by the first telecommunications carrier.

41. The method of claim 40, wherein the transaction request is denied when the transaction is to cause the second telecommunications carrier to hold an amount of the first type of digital property issued by the first telecommunications carrier that is greater than the risk limit set by the second telecommunications carrier.

42. The method of claim 40, wherein a risk limit for the second telecommunications carrier to hold the first type of digital property issued by the first telecommunications carrier is set to zero.

43. The method of claim 37, wherein the first virtual wallet is capable of storing one or more types of digital property issued by the first telecommunications carrier but not any type of digital property issued by the second telecommunications carrier; and the second virtual wallet is capable of storing one or more types of digital property issued by the second telecommunications carrier but not any type of digital property issued by the first telecommunications carrier.

44. The method of claim 37, further comprising:

(d) charging, by the first telecommunications carrier, the first virtual wallet for a first transaction fee; and

(e) charging, by the second telecommunications carrier, a second transaction fee to the second virtual wallet.

45. The method of claim 37, further comprising: charging the first virtual fund repository or the second virtual fund repository a third transaction fee by a mineworker generating a new block to record the transaction.

46. The method of claim 37, wherein the distributed transaction consensus network has an administrator.

47. The method of claim 46, wherein the administrator may issue digital expense tokens.

48. The method of claim 47, further comprising: charging, by the administrator, a fourth transaction fee to the first virtual fund repository or the second virtual fund repository.

49. The method of claim 46, wherein the administrator can authorize the first telecommunications carrier or the second telecommunications carrier to publish one or more types of digital property.

50. The method of claim 46, wherein the administrator may authorize miners to generate new blocks to record the transactions and set rules for each miner to compete with or support each other.

51. A computer program product comprising one or more computer usable non-transitory media having computer readable program code embodied therein for controlling a digital money management system, the computer readable program code configured to cause the digital money management system to perform a transaction process, the process comprising:

(a) receiving a transaction request over a distributed transaction consensus network to transfer a first type of digital property issued by a first telecommunications carrier from a first virtual wallet corresponding to a first phone number associated with the first telecommunications carrier to a second virtual wallet corresponding to a second phone number associated with a second telecommunications carrier;

(b) causing the second virtual wallet to receive a second type of digital property issued by the second telecommunications carrier; and

(c) the requested transaction is recorded in a distributed account book.

52. The computer program product of claim 51, wherein step (b) further comprises:

(b1) transferring the first type of digital property issued by the first telecommunications carrier from the first virtual wallet owned by a first subscriber to a first virtual fund vault owned by the first telecommunications carrier;

(b2) transferring the first type of digital property issued by the first telecommunications carrier or the second telecommunications carrier from the first virtual fund repository to a second virtual fund repository owned by the second telecommunications carrier;

(b3) transferring the second type of digital property issued by the second telecommunications carrier from the second virtual fund vault to the second virtual wallet owned by a second subscriber, wherein the second type of digital property is the same as the first type of digital property.

53. The computer program product of claim 52, wherein, in step (b2), when the first virtual fund repository contains the first type of digital property issued by the second telecommunications carrier, the first telecommunications carrier preferentially transfers the first type of digital property issued by the second telecommunications carrier from the first virtual fund repository to the second virtual fund repository; and when the first virtual fund vault does not contain the requested amount of the first type of digital property issued by the second telecommunications carrier, the first telecommunications carrier transfers the remaining amount of the first type of digital property issued by the first telecommunications carrier from the first virtual fund vault to the second virtual fund vault.

54. The computer program product of claim 52, wherein the second telecommunications carrier sets a risk limit for holding the first type of digital property issued by the first telecommunications carrier.

55. The computer program product of claim 54, wherein the transaction request is denied when the transaction will cause the second telecommunications carrier to hold an amount of the first type of digital property issued by the first telecommunications carrier that is greater than the risk limit set by the second telecommunications carrier.

56. The computer program product of claim 54, wherein a risk quota by which the second telecommunications carrier holds the first type of digital property issued by the first telecommunications carrier is set to zero.

57. The computer program product of claim 51, wherein the first virtual wallet is capable of storing one or more types of digital property issued by the first telecommunications carrier but not any type of digital property issued by the second telecommunications carrier; and the second virtual wallet is capable of storing one or more types of digital property issued by the second telecommunications carrier but not any type of digital property issued by the first telecommunications carrier.

58. The computer program product of claim 51, wherein the process further comprises:

(d) charging, by the first telecommunications carrier, the first virtual wallet for a first transaction fee; and

(e) charging, by the second telecommunications carrier, a second transaction fee to the second virtual wallet.

59. The computer program product of claim 51, wherein the process further comprises: charging the first virtual fund repository or the second virtual fund repository a third transaction fee by a mineworker generating a new block to record the transaction.

60. The computer program product of claim 51, wherein the distributed transaction consensus network has an administrator.

61. The computer program product of claim 60, wherein the administrator can issue digital expense tokens.

62. The computer program product of claim 61, wherein the process further comprises: charging, by the administrator, a fourth transaction fee to the first virtual fund repository or the second virtual fund repository.

63. The computer program product of claim 60, wherein the administrator can authorize the first digital property issuer or the second digital property issuer to issue one or more types of digital property.

64. The computer program product of claim 60, wherein the administrator may authorize miners to generate new blocks to record the transactions and set rules for each miner to compete with or support each other.