CN118891644A - Methods and systems for transaction settlement and smart contract access using security tokens - Google Patents

Abstract

A method for transaction settlement using a security token, comprising: receiving a transaction request from a first financial institution, the transaction request including a recipient digital address, a digital token issued by the first financial institution to the recipient digital address, a sender address, an asset network identifier and an asset identifier; generating a security token for the digital token; generating an asset request transaction including the security token, the recipient digital address, the sender digital address and the asset identifier; sending the asset request transaction to the asset network; receiving an asset transaction including an asset, a recipient digital address and a sender digital address from the asset network; generating an asset transfer transaction including the recipient digital address, the sender digital address and the asset identifier; and sending the asset transaction to the recipient digital address.

Description

Methods and systems for transaction settlement and smart contract access using security tokens

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application No. 63/330,432 filed on April 13, 2022 and U.S. Provisional Patent Application No. 63/424,242 filed on November 10, 2022, the entire contents of which are incorporated herein by reference for all purposes.

Technical Field

The present disclosure relates to transaction settlement and smart contract access using a security token or a combination of a security token and a payment status token. More particularly, the present disclosure relates to the settlement of digital token transactions of assets secured by one or more smart contracts.

Background Art

The cryptocurrency market has seen tremendous growth, with a market cap of over $1.5 trillion. To date, the market has primarily served cryptocurrency insiders without much upside in mainstream use cases. Stablecoins, which are primarily used to enter and exit cryptocurrency trade positions, are finding their way into mainstream use cases such as remittances, supplier B2B payments, and commercial payments. However, stablecoins continue to be plagued by several issues, including uncertain regulation, fraud, and unpredictable costs. Meanwhile, central banks are exploring central bank digital currencies (CBDCs), which could provide citizens with digital versions of fiat currencies. But the path toward CBDCs could take different paths in each country, take many years to be operational, and ultimately may not offer all of the potential features of stablecoins. While current solutions remain challenging, blockchain-based payments could have multiple benefits, including transparency (e.g., the ability of participants to view the status and details of a transaction), immutability (e.g., ensuring that transactions cannot be altered or deleted by other parties), speed (e.g., the potential for faster transactions, especially cross-border), cost efficiency (e.g., reducing manual tasks and streamlining costs associated with cross-border money flows), and programmability (e.g., digitally native payment tokens can be encoded to execute payments when conditions are met, opening up innovative use cases).

Currently, much of the innovation in cryptocurrency technology is focused on the opportunities presented by decentralized applications and services relative to centralized applications and services. However, the cryptocurrency market has focused little on innovation to create a flexible financial infrastructure that meets regulatory requirements and expectations and provides consumer protection while maintaining the stability of the current financial system. Therefore, there is a need for a novel solution for regulated payment services that enable the use of digital currencies (e.g., cryptocurrencies) that retains the security features and other benefits of cryptocurrency systems without the associated value volatility.

Summary of the invention

A method for transaction settlement and smart contract access using a guarantee token is disclosed. The method comprises: receiving a transaction request from a first financial institution by a receiving device of a processing server, the transaction request at least including a recipient digital address, a digital token issued by the first financial institution to the recipient digital address, a sender address, an asset network identifier and an asset identifier; generating a guarantee token for the digital token by a generating module of the processing server, the guarantee token being a tokenized guarantee of a digital token issued by the first financial institution; generating an asset request transaction by the generating module of the processing server, the asset request transaction at least including the guarantee token, the recipient digital address, the sender digital address and the asset identifier; sending the asset request transaction to an asset network by a sending device of the processing server; receiving an asset transaction from the asset network by the receiving device of the processing server, the asset transaction at least including an asset, a recipient digital address and a sender digital address; generating an asset transfer transaction by the generating module of the processing server, the asset transfer transaction at least including a recipient digital address, a sender digital address and an asset identifier; and sending the asset transfer transaction to the recipient digital address by the sending device of the processing server.

A system for transaction settlement and smart contract access using a security token is disclosed. The system includes: a receiving device of a processing server, the receiving device receives a transaction request from a first financial institution, the transaction request at least including a recipient digital address, a digital token issued by the first financial institution to the recipient digital address, a sender digital address, an asset network identifier and an asset identifier; a generating module of the processing server, the generating module generates a security token for the digital token, the security token is a tokenized security of the digital token issued by the first financial institution; the generating module of the processing server generates an asset request transaction, the asset request transaction at least including the security token, the recipient digital address, the sender digital address and the asset identifier; a sending device of the processing server, the sending device sends the asset request transaction to an asset network; the receiving device of the processing server receives an asset transaction from the asset network, the asset transaction at least including an asset, a recipient digital address and a sender digital address; the generating module of the processing server generates an asset transfer transaction, the asset transfer transaction at least including a recipient digital address, a sender digital address and an asset identifier; and the sending device of the processing server sends the asset transfer transaction to the recipient digital address.

A method for transaction settlement using a guarantee token and a payment status token is disclosed. The method comprises: a receiving device of a processing server receives a transaction request from a first financial institution, the transaction request at least including a recipient digital address, a digital token issued by the first financial institution to the recipient digital address, a sender address, an asset network identifier and an asset identifier; a generation module of the processing server generates a guarantee token for the digital token, the guarantee token is a tokenized guarantee of the digital token issued by the first financial institution; a generation module of the processing server generates a payment status token, the payment status token is a tokenized payment authorization message for the payment of the asset associated with the asset identifier; and a generation module of the processing server generates an asset request transaction, the asset request transaction at least including the A payment status token, a recipient digital address, a sender digital address and an asset identifier; the sending device of the processing server sends the asset request transaction to an asset network; the sending device of the processing server sends the guarantee token to a second financial institution associated with the sender address; the receiving device of the processing server receives an asset transaction from the asset network, the asset transaction at least including an asset, a recipient digital address and a sender digital address; the generating module of the processing server generates an asset transfer transaction, the asset transfer transaction at least including a recipient digital address, a sender digital address and an asset identifier; and the sending device of the processing server sends the asset transaction to the recipient digital address.

A system for transaction settlement using a guarantee token and a payment status token is disclosed. The system comprises: a receiving device of a processing server, the receiving device receives a transaction request from a first financial institution, the transaction request at least comprising a recipient digital address, a digital token issued by the first financial institution to the recipient digital address, a sender digital address, an asset network identifier and an asset identifier; a generating module of the processing server, the generating module generates a guarantee token for the digital token, the guarantee token is a tokenized guarantee of the digital token issued by the first financial institution; the generating module of the processing server generates a payment status token, the payment status token is a tokenized payment authorization message for the payment of the asset associated with the asset identifier; the generating module of the processing server generates an asset request transaction, the asset request transaction to The processing server includes at least the payment status token, the recipient digital address, the sender digital address and the asset identification; the sending device of the processing server, the sending device sends the asset request transaction to the asset network; the sending device of the processing server sends the guarantee token to a second financial institution associated with the sender address; the receiving device of the processing server receives an asset transaction from the asset network, the asset transaction includes at least the asset, the recipient digital address and the sender digital address; the generating module of the processing server generates an asset transfer transaction, the asset transfer transaction includes at least the recipient digital address, the sender digital address and the asset identification; and the sending device of the processing server sends the asset transaction to the recipient digital address.

BRIEF DESCRIPTION OF THE DRAWINGS

The scope of the present disclosure may be better understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings, which include the following figures:

1 is a block diagram illustrating a high-level system architecture for transaction settlement and smart contract access using security tokens, according to an exemplary embodiment.

2 is a block diagram illustrating a processing server of the system of FIG. 1 for transaction settlement and smart contract access using a security token, according to an exemplary embodiment.

3A-3E are flow diagrams illustrating a process of transaction settlement and smart contract access using a security token performed by a processing server ( FIG. 2 ) in the system of FIG. 1 , according to an exemplary embodiment.

4A-4B are flow diagrams illustrating an exemplary method for transaction settlement and smart contract access using a security token, according to an exemplary embodiment.

5A-5B are flow diagrams illustrating a process of transaction settlement and smart contract access using a guarantee token and a payment status token performed by a processing server (FIG. 2) in the system of FIG. 1 according to an exemplary embodiment.

6A-6B are flow diagrams illustrating an exemplary method for transaction settlement and smart contract access using a security token and a payment status token according to an exemplary embodiment.

FIG. 7 is a block diagram illustrating a computer system architecture in accordance with an exemplary embodiment.

Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter.It should be understood that the detailed description of the exemplary embodiments is only for illustration and thus, does not necessarily limit the scope of the present disclosure.

DETAILED DESCRIPTION

Glossary

Blockchain-a public ledger of all transactions of blockchain-based currencies. One or more computing devices may constitute a blockchain network, which may be configured to process transactions and record transactions as part of a block in the blockchain. Once a block is completed, the block is added to the blockchain, thereby updating the transaction record. In many cases, the blockchain may be a ledger of transactions in chronological order, or may be presented in any other order suitable for use by the blockchain network. In some configurations, transactions recorded in the blockchain may include a destination address and a currency amount, so that the blockchain records how much currency can be attributed to a specific address. In some cases, transactions are financial transactions, while others are not financial transactions, or may include additional or different information, such as source addresses, timestamps, etc. In some embodiments, the blockchain may also or alternatively include, in the form of transactions, almost any type of data that is to be or needs to be placed in a distributed database, which maintains a growing list of data records that are enhanced to prevent tampering and modification (even by its operators) and can be confirmed and verified by the blockchain network through proof of work and/or any other appropriate verification technology associated therewith. In some cases, data about a given transaction may also include additional data that is appended to the transaction data and is not directly part of the transaction. In some cases, including such data in a blockchain may constitute a transaction. In such cases, the blockchain may not be directly associated with a particular digital currency, virtual currency, legal currency, or other type of currency.

A system for transaction settlement and smart contract access using security tokens

FIG. 1 illustrates a system 100 for transaction settlement and smart contract access using security tokens, according to an exemplary embodiment.

System 100 includes a receiving computing device 102 , a first financial institution 104 , a processing server 106 , a second financial institution 108 , a sending computing device 110 , and an asset network 114 .

The receiving computing device 102 is a computing device associated with a user in the system 100. In an embodiment, the user of the receiving computing device 102 is a customer of the first financial institution 104 (e.g., has a transaction account at the first financial institution 102). For example, the user of the receiving computing device 102 has a digital address, e.g., a digital wallet, for trading deposit tokens issued by the first financial institution 104. In addition, the receiving computing device 102 operates on an asset network 114. For example, the user of the receiving computing device 102 may have an account with the asset network 114 or otherwise access the asset network 114 to purchase one or more assets (e.g., purchase an NFT on a non-fungible token or "NFT" marketplace). Transactions involving the receiving computing device 102 are described in more detail below with reference to Figures 3A-6B. The receiving computing device 102 may be a desktop computer, a notebook computer, a laptop computer, a tablet computer, a handheld device, a smart phone, a thin client, or any other electronic device or computing system capable of storing, compiling, and organizing audio, visual, or textual data and receiving and sending such data from and to other computing devices, such as the first financial institution 104, the processing server 106, the sending computing device 110, and/or one or more nodes of the asset network 114. For example, the receiving computing device 102 may be any type of electronic device or computing system specifically configured to perform the functions discussed herein, such as the computer system 700 illustrated in FIG7. Although only a single receiving computing device 102 is shown, it will be appreciated that the system 100 may include any number of receiving computing devices 102.

The first financial institution 104 is a financial institution such as an issuing bank or any other entity configured to issue a transaction account suitable for funding electronic payment transactions using legal tender or digital tokens. The first financial institution 104 is a financial entity that issues, but is not limited to, a central bank digital currency (CBDC), a regulated stablecoin, a digitized deposit token, or any other appropriate digital token representing a legal claim to the first financial institution 104. For example, the first financial institution 104 may be, but is not limited to, a bank, a central bank, an electronic currency issuer, a stablecoin issuer, or any other appropriate financial entity capable of issuing digital tokens. In an embodiment where the first financial institution 104 is a central bank, the digital token represents a central bank liability (e.g., CBDC). In an embodiment where the first financial institution 104 is a bank, the digital token represents a digitized deposit, which is a digitized form of a deposit liability. In an embodiment where the first financial institution 104 is an electronic currency issuer, the digital token represents an electronic currency liability. In an embodiment where the first financial institution 104 is a stablecoin issuer, the digital token represents a legal claim associated with a stablecoin holding. The digital token is a digital representation of a deposit obligation of the associated first financial institution 104, such as, but not limited to, a legal claim, a withdrawal claim, a depositor's claim, a deposit insurance claim, etc., against the first financial institution 104. The underlying deposit and associated characteristics represented by the digital token are not changed as a result of tokenization. The digital token issued by the first financial institution 104 includes, but is not limited to, one or more of the amount to be issued (e.g., the digital token legal tender equivalent), the currency (e.g., the legal tender in accordance with which the digital token is issued), the issue date (e.g., the date the digital token was created), and any other appropriate metadata (e.g., the identity of the first financial institution 104, the identity of the receiving computing device 102, the digital address of the receiving computing device 102, etc.).

The first financial institution 104 may be a licensed entity on the multi-token network 112 that interacts with the multi-token network 122 and provides customer-facing products such as digital wallets. The first financial institution 104 is permitted to create and manage wallets (e.g., digital addresses) for their customers (e.g., users of the receiving computing device 102), read transactions and balances from the multi-token network 112, and submit transactions on behalf of their customers (e.g., users of the receiving computing device 102). In addition, the first financial institution 104 may issue payment instruments such as physical payment cards, virtual payment cards, paper checks, virtual checks, etc. to the receiving computing device 102. The receiving computing device 102 may receive the digital wallet and/or other payment instruments to deliver payment credentials associated with a transaction account, thereby utilizing the transaction account to fund a payment transaction.

Processing server 106 may be a server, desktop computer, notebook computer, laptop computer, tablet computer, handheld device, smart phone, thin client, or any other electronic device or computing system capable of storing, compiling, and organizing audio, visual, or textual data and receiving and sending such data from and to other computing devices, such as receiving computing device 102, first financial institution 104, second financial institution 108, sending computing device 110, and/or asset network 114. For example, processing server 106 may be any type of electronic device or computing system specifically configured to perform the functions discussed herein, such as computer system 700 illustrated in FIG. 7 . In an exemplary embodiment, the processing server 106 is an operator node and/or management node on the multi-token network 112 that is capable of receiving and sending digital tokens from and to the first financial institution 104 and the second financial institution 108, generating collateral tokens for digital tokens, generating payment status tokens for unlocking one or more smart contracts on the asset network 114, receiving, generating and/or sending transaction messages and requests from and to the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, and/or the asset network 114, receiving and sending assets from and to the asset network 114, the receiving computing device 102, and the sending computing device 110, receiving collateral token redemption requests from the first financial institution 104 and the second financial institution 108, and generating and sending settlement transaction messages to the first financial institution 104 and the second financial institution 108. The processing server 106 is discussed in more detail with reference to FIG.

The second financial institution 108 is a financial institution such as a receiving bank or any other entity configured to issue a transaction account suitable for funding electronic payment transactions using legal tender or digital tokens. The second financial institution 108 is a financial entity that issues, but is not limited to, a central bank digital currency (CBDC), a regulated stablecoin, a digitized deposit token, or any other appropriate digital token representing a legal claim on the second financial institution 108. For example, the second financial institution 108 may be, but is not limited to, a bank, a central bank, an electronic currency issuer, a stablecoin issuer, or any other appropriate financial entity capable of issuing digital tokens. In an embodiment where the second financial institution 108 is a central bank, the digital token represents a central bank liability (e.g., CBDC). In an embodiment where the second financial institution 108 is a bank, the digital token represents a digitized deposit, which is a digitized form of a deposit liability. In an embodiment where the second financial institution 108 is an electronic currency issuer, the digital token represents an electronic currency liability. In an embodiment where the second financial institution 108 is a stablecoin issuer, the digital token represents a legal claim associated with a stablecoin holding. The digital token is a digital representation of a deposit obligation of the associated second financial institution 108, such as, but not limited to, a legal claim, a withdrawal claim, a depositor's claim, a deposit insurance claim, etc., against the second financial institution 108. The underlying deposit and associated characteristics represented by the digital token do not change as a result of tokenization. The digital token issued by the second financial institution 108 includes, but is not limited to, one or more of the amount to be issued (e.g., the digital token legal tender equivalent), the currency (e.g., the legal tender in accordance with which the digital token is issued), the issue date (e.g., the date the digital token was created), and any other appropriate metadata (e.g., the identity of the second financial institution 108, the identity of the sending computing device 110, the digital address of the sending computing device 110, etc.).

The second financial institution 108 may be a licensed entity on the multi-token network 112 that interacts with the multi-token network 122 and provides customer-facing products such as digital wallets. The second financial institution 108 is permitted to create and manage wallets (e.g., digital addresses) for their customers (e.g., users of the sending computing device 110), read transactions and balances from the multi-token network 112, and submit transactions on behalf of their customers (e.g., users of the sending computing device 100). In addition, the second financial institution 108 may issue payment instruments such as physical payment cards, virtual payment cards, paper checks, virtual checks, etc. to the sending computing device 110. The sending computing device 110 may receive the digital wallet and/or other payment instrument to deliver payment credentials associated with a transaction account, thereby utilizing the transaction account to fund a payment transaction.

The sending computing device 110 is a computing device associated with a user in the system 100. In an embodiment, the user of the sending computing device 110 is a customer of the second financial institution 108 (e.g., has a transaction account at the first financial institution 104). For example, the user of the sending computing device 110 has a digital address, such as a digital wallet, for trading deposit tokens issued by the second financial institution 108. In addition, the sending computing device 110 operates on an asset network 114. For example, the user of the sending computing device 110 can have an account with the asset network 114 or otherwise access the asset network 114, and the user of the sending computing device 110 sells one or more assets (e.g., NFTs on the NFT market) through the asset network 114. Transactions involving the sending computing device 110 are described in more detail below with reference to Figures 3A-6B. The sending computing device 110 may be a desktop computer, a notebook computer, a laptop computer, a tablet computer, a handheld device, a smart phone, a thin client, or any other electronic device or computing system capable of storing, compiling, and organizing audio, visual, or textual data and receiving and transmitting the data from and to other computing devices, such as the receiving computing device 102, the processing server 106, the second financial institution 108, and/or one or more nodes of the asset network 114. For example, the sending computing device 110 may be any type of electronic device or computing system specifically configured to perform the functions discussed herein, such as the computer system 700 illustrated in FIG7. Although only a single sending computing device 110 is shown, it will be appreciated that the system 100 may include any number of sending computing devices 100.

The asset network 114 is a network or platform that enables the exchange (e.g., purchase and sale) of assets (e.g., products or services) between users using digital tokens. The asset network 114 is capable of storing, compiling, and organizing audio, visual, or textual data, and receiving and sending data from other computing devices (e.g., receiving computing device 102 and/or processing server 106, sending computing device 110). For example, the asset network 114 can be operated or supported by one or more electronic devices or computing systems of any type specifically configured to perform the functions discussed herein, such as the computer system 700 illustrated in FIG. 7. The asset network 114 can include multiple user nodes (e.g., receiving computing device 102 and sending computing device 110) that sell and/or purchase assets on the asset network 114. For example, the asset network 114 can be, but is not limited to, a retail payment network, a business-to-business payment network, a supply chain payment network, a cross-border person-to-person payment network (e.g., remittent flows), a public crypto-economy (e.g., an NFT marketplace, a decentralized finance (DeFi) network, etc.), or any other appropriate network that is apparent to one skilled in the art for facilitating the exchange of assets and digital tokens. In the example of the NFT marketplace, the asset network 114 facilitates the sale and purchase of digital artworks (e.g., NFTs) between the receiving computing device 102 and the sending computing device 110. In addition, the asset network 114 can include one or more smart contracts associated or linked to assets being bought and sold on the asset network 114, and one or more parameters for unlocking the smart contract and releasing the asset. In the example of the NFT marketplace (e.g., the asset network 114), the smart contract holds each NFT (e.g., asset) for sale and defines one or more parameters for unlocking the smart contract. For example, one or more parameters of the smart contract can define acceptable currencies for purchasing assets, etc.

In an embodiment of the system 100, the receiving computing device 102, the first financial institution 104, the processing server 106, the second financial institution 108, and the sending computing device 110 are part of a multi-token network 112. The multi-token network 112 facilitates transactions and communications between traditional fiat currency users and crypto-native users (e.g., the receiving computing device 102, the first financial institution 104, the second financial institution 108, and the sending computing device 110). The multi-token network 112 enables multiple entities (e.g., companies, governments, financial institutions, etc.) to issue and transfer digital tokens and leverage regulated cryptocurrencies (e.g., stablecoins, CBDCs, etc.) as a token form of transaction or as an asset to provide instant settlement on the multi-token network 112. The multi-token network 112 interacts and/or otherwise integrates with existing traditional payment rails, thereby providing additional consumer choices and benefits (e.g., utilizing digital tokens or fiat currencies for transactions). The multi-token network 112 is a private permissioned network system that maintains an access control layer to allow selected actions to be performed only by certain identifiable participants (e.g., the receiving computing device 102, the first financial institution 104, the second financial institution 108, and the sending computing device 110). For example, the multi-token network 112 is capable of receiving, storing, processing, and/or sending digital tokens directly from one address to another (e.g., a digital address associated with the receiving computing device 102 and a data address associated with the sending computing device 110). The multi-token network 112 is a programmable network that runs on a network operator infrastructure and is accessible to participants through one or more application programming interfaces (APIs). The API can be a private permissioned API such that a node of the multi-token network 112 requires a credential issued by the multi-token network 112 to access the multi-token network 122. For example, the multi-token network 112 includes an API that is compatible with each financial institution (e.g., the first financial institution 104 and the second financial institution 108) participating in the multi-token network 112. The multi-token network 112 is capable of communicating and transacting across multiple networks (e.g., the asset network 114 and the blockchain network 116). Although only a single blockchain network 116 and a single asset network 114 are shown in FIG1 , it can be appreciated that any number of blockchain networks 116 and/or asset networks 114 can be part of the multi-token network 112. In addition, the multi-token network 112 is capable of communicating and transacting across various types of networks. For example, the blockchain network 116 and/or the asset network 114 can be a private, permissioned, or public blockchain network, and the first financial institution 104 and the second financial institution 108 can each be part of a separate payment network.

In an embodiment, the multi-token network 112 may include a blockchain network 116. The blockchain network 116 may be composed of a plurality of blockchain nodes, including but not limited to the first financial institution 104, the processing server 106, and the second financial institution 108. Each blockchain node of the blockchain network 116 may be a computing system such as illustrated in FIG. 7 , discussed in more detail below, configured to perform functions related to the processing and management of a blockchain, including generation of blockchain data values, verification of proposed blockchain transactions, verification of digital signatures, generation of new blocks, validation of new blocks, and maintenance of copies of the blockchain.

The blockchain of the blockchain network 116 may be a distributed ledger consisting of at least a plurality of blocks. Each block may include at least a block header and one or more data values. Each block header may include at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time when the block header is generated, and may be represented using any appropriate method (e.g., UNIX timestamp, DateTime, etc.). The block reference value may be a value that references an earlier block in the blockchain (e.g., based on a timestamp). In some embodiments, the block reference value in the block header may be a reference to the block header of the most recently added block before the corresponding block. In an exemplary embodiment, the block reference value may be a hash value generated by hashing the block header of the most recently added block. The data reference value may similarly be a reference to one or more data values stored in a block including the block header. In an exemplary embodiment, the data reference value may be a hash value generated by hashing one or more data values. For example, the block reference value may be the root of a Merkle tree generated using one or more data values.

The use of block reference values and data reference values in each block header may result in the blockchain being immutable. Any attempted modification of a data value requires the generation of a new data reference value for that block, which will therefore require the generation of a new block reference value for subsequent blocks, further requiring the generation of a new block reference value in each subsequent block. This operation must be performed and updated in each individual node in the blockchain network 116 before a new block is generated and added to the blockchain in order to make the change permanent. Computational and communication limitations may make such modifications extremely difficult, if not impossible, thereby rendering the blockchain immutable.

In some embodiments, a blockchain may be used to store information about a blockchain transaction (e.g., a transaction request to purchase an asset on an asset network 114) conducted between two different blockchain wallets (e.g., a buyer digital address associated with a receiving computing device 102 and a seller digital address associated with a sending computing device 110). The blockchain wallet may include a private key of a cryptographic key pair for generating a digital signature that serves as an authorization of the payee to the blockchain transaction, wherein the digital signature may be verified by the blockchain network 116 using a public key in the cryptographic key pair. In some cases, the term "blockchain wallet" or "digital address" may specifically refer to a private key. In other cases, the term "blockchain wallet" or "digital address" may refer to a computing device (e.g., a receiving computing device 102 and a sending computing device 110, etc.) that stores a private key for use in a blockchain transaction. For example, each computing device may each have its own private key of a corresponding cryptographic key pair, and may each be a blockchain wallet for transactions with a blockchain associated with the blockchain network 116. The computing device may be any type of device suitable for storing and utilizing a blockchain wallet, such as a desktop computer, a laptop computer, a notebook computer, a tablet computer, a cellular phone, a smartphone, a smart watch, a smart television, a wearable computing device, an implantable computing device, etc.

Each blockchain data value stored in the blockchain may correspond to a blockchain transaction or other data store, as applicable. A blockchain transaction may consist of at least the following: a digital signature of the sender of the currency or digital token generated using the sender's private key (e.g., a digital address associated with the receiving computing device 102), a blockchain address of the recipient of the currency or digital token generated using the recipient's public key (e.g., a digital address associated with the sending computing device 110), and the amount of blockchain currency transferred or other data stored. In some blockchain transactions, the transaction may also include one or more blockchain addresses of the sender that currently store the blockchain currency or digital token (e.g., a digital signature proving that they have access to such currency or digital token), and an address generated using the sender's public key for any changes that the sender wants to keep. Addresses to which a cryptocurrency or digital token has been sent that can be used in future transactions are referred to as "output" addresses because each address was previously used to capture the output of a previous blockchain transaction, which is also referred to as an "unspent transaction" because there was currency or digital token sent to that address in a previous transaction that remains unspent. In some cases, a blockchain transaction may also include the sender's public key for use by entities when verifying the transaction. For traditional processing of blockchain transactions, such data may be provided by the sender or recipient to a blockchain node in the blockchain network 116 (e.g., the processing server 106, the first financial institution 104, and/or the second financial institution 108). The node may verify the digital signature using the public key of the cryptographic key pair of the sender's wallet, and may also verify the sender's access to the funds (e.g., the unspent transaction has not been spent and is sent to an address associated with the sender's wallet), a process known as "confirmation" of the transaction, and then include the blockchain transaction in a new block. In traditional blockchain implementations, new blocks may be verified by other nodes in the blockchain network 116 before being added to the blockchain and distributed to all blockchain nodes in the blockchain network 116. In cases where a blockchain data value may not be associated with a blockchain transaction, but rather with the storage of other types of data, the blockchain data value may still include or otherwise involve verification of the digital signature.

In the system 100, blockchain nodes that want to use digital tokens for transactions can submit these digital tokens to the processing server 106 to facilitate transactions through the blockchain network 116. When the receiving computing device 102 wants to use the digital token issued by the first financial institution 104 to purchase an asset on the asset network 114, the receiving computing device 104 can submit a new blockchain transaction request (e.g., an asset purchase request) to the blockchain network 116. The digital token issued by the first financial institution 104 will have a value equal to or greater than the purchase price of the asset on the asset network 114. In an exemplary embodiment, the receiving computing device 102 communicates with the blockchain network 116 via the first financial institution 104 (e.g., the financial institution that issued the digital token). The transaction request can include the digital address of the receiving computing device 102, the digital token issued by the first financial institution 104, the digital address of the sending computing device 110, the asset network 114 identification, and the asset identification. In some cases, the transaction request may include a digital signature generated using a private key of the digital address of the receiving computing device 102, which may be verified by the processing server 106 using a public key of the digital address of the receiving computing device 102, such as to verify that the receiving computing device 102 is authorized to use the digital address for which the transaction is being submitted. In an embodiment, the receiving computing device 102 and/or the first financial institution 104 may send the transaction request directly to the processing server 106 using a traditional payment rail network (e.g., without the blockchain network 116).

The processing server 106 may receive the transaction request and may then generate a security token for the digital token (e.g., generate a security token having a value equal to the value of the digital token). The security token is created by one or more digital addresses of the processing server 106. The security token may include one or more attributes, such as, but not limited to, a unique symbol, a circulating amount, and an exchange value, etc. In an embodiment, the processing server 106 stores the digital token in a database of the processing server 106. The processing server 106 may generate the transaction request in response to verifying the digital signature of the receiving computing device 102. The security token represents a tokenized security of the digital token issued by the first financial institution 104 (e.g., a security of the funds represented by the digital token). For example, the security token may be issued for a debt of the first financial institution 104 to the processing server 106, and in turn represents a debt of the processing server 106 to any subsequent holder of the security token (e.g., a second financial institution 108 and/or a sending computing device 110, etc.). The security token may be expressed in the same currency as the digital token for which the security token is issued. The security token is a fungible asset, so all security tokens issued of the same currency and value are indistinguishable from each other. The security token is minted and transferred only within the multi-token network 112 between registered participants in the multi-token network 112 (e.g., the receiving computing device 102, the first financial institution 104, the second financial institution 108, and the sending computing device 110, etc.). The processing server 106 may identify a smart contract on the asset network 114 (e.g., the asset network 114 and the asset identified in the transaction request) and determine one or more parameters for unlocking the smart contract. When generating the security token, the processing server 106 uses one or more parameters of the smart contract associated with the asset identified in the transaction request to generate a security token that will unlock the smart contract and release the asset. In an embodiment, the security token may not operate to unlock the smart contract on the asset network 114, but the processing server 106 may generate a payment status token for unlocking the smart contract on the asset network 114. In such an embodiment, the security token will not be sent to the asset network 114. The payment status token may be a tokenized payment authorization message for payment of the asset on the asset network 114 generated using one or more parameters of the smart contract associated with the asset identified in the transaction request. The payment status token may include asset transaction metadata, such as, but not limited to, a transaction reference, a transaction payment confirmation, an asset identifier, an indication of a transaction payment failure, and an indication of a transaction payment delay. The asset transaction metadata may be used by the asset network 114 or any other external entity as proof of payment, transaction verifiability, and/or reconciliation (e.g., if the asset network 114 wants to charge a commission to the processing server 106). The payment status token is any suitable cryptographically verifiable messaging token, such as, but not limited to, a non-fungible ERC 721 token, an ERC 20 token, etc. The processing server 106 may generate a payment status token on a private blockchain network (e.g., blockchain network 116), and the private blockchain network may include a smart contract for transferring the payment status token from the private blockchain network to the asset network 114. The processing server 106 generates an asset request transaction for an asset on behalf of the receiving computing device 102. The asset request transaction may include, but is not limited to, a collateral token, a recipient digital address of the receiving computing device 102, a sender digital address of the sender computing device 110, and an asset identifier. In some embodiments, the asset request transaction may include a digital address of the processing server 106. In some cases, the asset request transaction may include a digital signature generated using a private key of the digital address of the processing server 106 and/or the receiving computing device 102, which may be verified by the asset network 114 using a public key of the digital address of the processing server 106 and/or the receiving computing device 102, such as verifying that the processing server 106 and/or the receiving computing device 102 is authorized to use the digital address for which the transaction is being submitted. The processing server 106 may send the asset request to the blockchain network 116 for recording therein. In embodiments where the processing server 106 generates a payment status token, the asset request transaction includes the payment status token instead of the guarantee token, and the processing server 106 may send the guarantee token directly to the second financial institution 108.

The asset network 114 may receive an asset request transaction from the processing server 106 and generate an asset transaction. The asset network 114 may generate an asset transaction in response to verifying a digital signature of the processing server 106 and/or the receiving computing device 102. The asset transaction may include, but is not limited to, an asset, a recipient digital address of the receiving computing device 102, and a sender digital address of the sending computing device 110. The asset transaction may be generated by a node of the asset network 114 on behalf of the sending computing device 110, or directly by the sending computing device 110. In some embodiments, the asset transaction may include the digital address of the processing server 106. In some cases, the asset request transaction may include a digital signature generated using a private key of the digital address of the node of the asset network 114 and/or the sending computing device 110, which may be verified by the processing server 106 using a public key of the digital address of the node of the asset network 114 and/or the sending computing device 110, such as verifying that the node of the asset network 114 and/or the sending computing device 110 is authorized to use the digital address for which the transaction is submitted. The asset network 114 may send the collateral token received in the asset request transaction to the second financial institution 108 so that the second financial institution 108 may redeem the currency associated with the collateral token. In some embodiments, the collateral token may be sent to a digital address of the sending computing device 110, which may submit the digital token to the second financial institution 108. In embodiments where the asset network 114 receives a payment status token instead of a collateral token as part of the asset request transaction, the asset network 114 may send the payment status token to the second financial institution 108. Alternatively, the asset network 114 may send the payment status token back to the processing server 106, retain and store the payment status token, or retain and destroy the payment status token.

The processing server 106 may receive the asset transaction from the asset network 114 (e.g., via a node of the asset network 114 and/or a sending computing device 110). The processing server 106 verifies the digital signature of the node of the asset network 114 and/or the sending computing device 110 and sends the asset transaction and/or only the asset to the digital address of the receiving computing device 102.

Processing server 106 may receive a redemption request from second financial institution 108. The redemption request includes a collateral token generated by processing server 106 in response to the transaction request. The redemption request may also include a digital address of second financial institution 108. In some cases, the redemption request may include a digital signature generated using a private key of the digital address of second financial institution 108, which may be verified by processing server 106 using a public key of the digital address of second financial institution 108, such as verifying that second financial institution 108 is authorized to use the digital address for which transactions are submitted. Processing server 106 may generate and send a settlement transaction message to first financial institution 104. The settlement transaction message may include, but is not limited to, a digital token and instructions to send a fiat currency equivalent of the digital token from first financial institution 104 to second financial institution 108. The settlement transaction message may also include the digital address of processing server 106. In some cases, the settlement transaction message may include a digital signature generated using a private key of the digital address of processing server 106, which may be verified by first financial institution 104 using a public key of the digital address of second processing server 106, such as verifying that processing server 106 is authorized to use the digital address for which transactions are submitted.

The first financial institution 104 may receive the settlement transaction message from the processing server 106, unlock the fiat currency equivalent of the digital token, and send the fiat currency equivalent to the second financial institution 108. In some embodiments, the first financial institution 104 may unlock and send the fiat currency in response to verifying the digital signature of the processing server 106 in the settlement transaction message. The first financial institution 104 may send the fiat currency to the second financial institution 108, or otherwise settle the fiat currency owed to the second financial institution 108 using conventional payment rails and settlement methods that are apparent to those skilled in the art.

The methods and systems discussed herein provide a technical solution to the problem of unregulated digital currency transactions in digital currency networks that lack the characteristics and regulations of trusted traditional payment systems. By using digital tokens issued by financial institutions backed by legal currency, and issuing security tokens for these digital tokens for use in digital transactions, the parties to the transaction are enabled to use digital tokens to conduct transactions in a trusted and regulated system where the value of the digital tokens is guaranteed. For example, the methods and systems discussed herein provide a solution that supports multiple tokens on a licensed blockchain network, which enables the issuance and movement of digital deposit tokens from banks, non-bank-issued (but regulated) stablecoins, and CBDCs, all at the security and speed of cutting-edge payment networks. This will enable banks and other regulated institutions to take advantage of the advantages of blockchain and tokenized assets while still operating in a regulated and trusted ecosystem. Therefore, the methods and systems discussed herein provide a solution that combines elements of traditional payment and monetary settlement services with the use of digital currencies to produce a regulated and stable digital currency network.

Processing Server

FIG. 2 illustrates an embodiment of a processing server 106 in the system 100. It will be apparent to those skilled in the relevant art that the embodiment of the processing server 106 illustrated in FIG. 2 is provided only as an example and is not exhaustive of all possible configurations of the processing server 106 suitable for performing the functions discussed herein. For example, the computer system 700 illustrated in FIG. 7 and discussed in more detail below may be a suitable configuration of the processing server 106. In some embodiments, the blockchain nodes (e.g., the first financial institution 104 and the second financial institution 108) in the blockchain network (e.g., the blockchain network 116) illustrated in FIG. 1 may include the components illustrated in the processing server 106 of FIG. 2 and be configured to perform the functions discussed herein.

The processing server 106 may include a receiving device 202. The receiving device 202 may be configured to receive data through one or more networks via one or more network protocols. In some cases, the receiving device 202 may be configured to receive data from the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, the asset network 114, and other systems and entities via one or more communication methods, such as radio frequency, local area network, wireless local area network, cellular communication network, Bluetooth, the Internet, etc. In some embodiments, the receiving device 202 may be composed of multiple devices, such as different receiving devices for receiving data through different networks, such as a first receiving device for receiving data through a local area network and a second receiving device for receiving data through the Internet. The receiving device 202 may receive a data signal sent electronically, wherein the data may be superimposed or otherwise encoded on the data signal, and may be decoded, parsed, read, or otherwise obtained by receiving the data signal by the receiving device 202. In some cases, the receiving device 202 may include a parsing module for parsing the received data signal to obtain data superimposed on the data signal. For example, the receiving device 202 may include a parser program configured to receive data signals and transform the received data signals into usable inputs for functions performed by the processing server 106 in order to implement the methods and systems described herein.

The receiving device 202 may be configured to receive a data signal electronically transmitted by the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, the asset network 114, which may be superimposed with or otherwise encoded with a new transaction to be confirmed, a confirmed blockchain transaction, a new block to be confirmed, a confirmed block to be added to the blockchain, a message about block confirmation, blockchain network load data, etc. The receiving device 202 may also be configured to receive a data signal electronically transmitted by the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, the asset network 114, which may be superimposed with or otherwise encoded with a transaction request, a new blockchain transaction, a public key, a digital signature, a response message, a computational challenge response, etc. For example, the receiving device 202 may receive a transaction request, an asset transaction, and a redemption request as described above.

The processing server 106 may also include a communication module 204. The communication module 204 may be configured to send data between modules, engines, databases, memories, and other components of the processing server 106 for performing the functions discussed herein. The communication module 204 may be composed of one or more communication types and utilize various communication methods to communicate within the computing device. For example, the communication module 204 may be composed of a bus, a pin connector, a wire, etc. In some embodiments, the communication module 204 may also be configured to communicate between internal components of the processing server 106 and external components of the processing server 106, such as externally connected databases, display devices, input devices, etc. The processing server 106 may also include a processing device. It is obvious to those skilled in the relevant art that the processing device may be configured to perform the functions of the processing server 106 discussed herein. In some embodiments, the processing server 106 may include and/or be composed of multiple engines and/or modules specifically configured to perform one or more functions of the processing server 106, such as a query module 214, a generation module 216, a verification module 218, etc. The term "module" as used herein may be software or hardware that is specifically programmed to receive input, perform one or more processes using the input, and provide output. Based on this disclosure, the inputs, outputs, and processes performed by each module will be apparent to those skilled in the art.

The processing server 106 may also include a memory 208. The memory 208 may be configured to store data, such as public and private keys, symmetric keys, etc., for use by the processing server 106 in performing the functions discussed herein. The memory 208 may be configured to store data using appropriate data formatting methods and patterns, and may be any appropriate type of memory, such as read-only memory, random access memory, etc. It will be apparent to those skilled in the relevant art that the memory 208 may include, for example, encryption keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and applications of the processing server 106, and other data that may be suitable for use by the processing server 106 in performing the functions disclosed herein. In some embodiments, the memory 208 may consist of or otherwise include a relational database that utilizes a structured query language to store, identify, modify, update, access, etc., structured data sets stored therein. The memory 208 may be configured to store, for example, cryptographic keys, salts, one-time random numbers, address generation and verification algorithms, digital signature generation and verification methods, hash algorithms for generating reference values, rules regarding the generation of new blocks and block headers, a pool of pending transactions, blockchain network load information, blockchain wallet data, challenge difficulty data, etc. The memory 208 may also be configured to store communication information for the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, and the asset network 114. The memory 208 may also be configured to store digital coins received by the processing server 106 from the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, and the asset network 114.

The processing server 106 may also include blockchain data 206, which may be stored in a memory 208 of the processing server 106, or in a separate area within the processing server 106, or may be accessed by the processing server 106. The blockchain data 206 may include a blockchain, which may be composed of a plurality of blocks and associated with a blockchain network (e.g., blockchain network 116). In some cases, the blockchain data 206 may also include any other data associated with the blockchain and its management and performance, such as a block generation algorithm, a digital signature generation and confirmation algorithm, collected mining bids, mining bid weighting and selection rules, etc. In some cases, the blockchain data 206 may include communication data for the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, and the asset network 114. In some cases, the blockchain data 206 may include data associated with a blockchain wallet for use in buying and selling assets on the asset network 114.

The processing server 106 may include a query module 214. The query module 214 may be configured to perform a query on a database to identify information. The query module 214 may receive one or more data values or query strings and may perform a query string based thereon on an indicated database, such as the memory 208 of the processing server 106, to identify information stored in the memory. The query module 214 may then output the identified information to an appropriate engine or module of the processing server 106 as needed. For example, the query module 214 may perform a query on the memory 208 to identify digital coins received from the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, and the asset network 114. The query module 214 may, for example, query the asset network 114 to identify one or more assets and one or more smart contracts associated with the asset network 114 and/or the one or more assets.

The processing server 106 may also include a generation module 216. The generation module 216 may be configured to generate data for use by the processing server 106 in performing the functions discussed herein. The generation module 216 may receive instructions as input, may generate data based on the instructions, and may output the generated data to one or more modules of the processing server 106. For example, the generation module 216 may be configured to generate new blockchain data values, new block headers, Merkle roots, new blocks, and other data for the operation of the blockchain. The generation module 216 may also be configured to generate a security token for one or more digital coins received from the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, and the asset network 114. For example, the generation module 216 may generate a security token based on the value of the digital token. In addition, the generation module 216 may be configured to generate a payment status token for unlocking one or more smart contracts on the asset network 114.

The processing server 106 may also include a verification module 218. The verification module 218 may be configured to perform verification for the processing server 106 as part of the functionality discussed herein. The verification module 218 may receive an instruction as input, which may also include data to be used when performing verification, may perform verification upon request, and may output the results of the verification to other modules or engines of the processing server 106. For example, the verification module 218 may be configured to confirm a blockchain transaction by analyzing the blockchain data value in the blockchain to ensure that the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, and/or the asset network 114 are authorized to use the transaction output included in the new transaction submission, and that the transaction output has not been previously used to transfer currency in other transactions. The verification module 218 may also be configured to verify a digital signature using a public key and an appropriate signature generation algorithm. The verification module 218 may also be configured to verify digital tokens, guarantee tokens, payment status tokens, and/or assets traded in the system 100.

The processing server 106 may also include a sending device 220. The sending device 220 may be configured to send data through one or more networks via one or more network protocols. In some cases, the sending device 220 may be configured to send data to the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, the asset network 114, and other entities via one or more communication methods, local area network, wireless local area network, cellular communication, Bluetooth, radio frequency, the Internet, etc. In some embodiments, the sending device 220 may be composed of multiple devices, such as different sending devices for sending data through different networks, such as a first sending device for sending data through a local area network and a second sending device for sending data through the Internet. The sending device 220 may electronically send a data signal superimposed with data that can be parsed by the receiving device 202. In some cases, the sending device 220 may include one or more modules for superimposing, encoding, or otherwise formatting data into a data signal suitable for transmission.

The sending device 220 may be configured to electronically send a data signal to the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, and the asset network 114, the data signal superimposed with or otherwise encoded with new blockchain data values, new blocks to be confirmed, confirmed blocks, messages about block or transaction confirmations, and other data used for the operation and management of the blockchain. The sending device 220 may also be configured to electronically send a data signal to the receiving computing device 102, the first financial institution 104, the second financial institution 108, the sending computing device 110, and the asset network 114, the data signal may be superimposed with or otherwise encoded with asset request transactions, asset transfer transactions, and settlement transaction messages discussed in more detail above.

The process of transaction settlement and smart contract access using security tokens

3A-3G illustrate a process 300 for transaction settlement and smart contract access using a security token, according to an exemplary embodiment.

At step 302, the receiving computing device 102 selects an asset to be acquired on the asset network 114. For example, a user of the receiving computing device 102 may select an NFT sold by the sending computing device 110 on an NFT marketplace (e.g., the asset network 114). The receiving computing device 102 generates an asset purchase request at step 304 and sends the asset purchase request to the first financial institution 104 at step 306. The asset purchase request may include, but is not limited to, a sender address of the sending computing device 110, an asset network 114 identifier, an asset identifier, and a value of the asset.

At step 308, the first financial institution 104 receives the asset purchase request from the receiving computing device 102. The first financial institution 104 may check an account associated with the receiving computing device 102 to verify that the receiving computing device 103 has a sufficiently high balance to cover the value of the asset purchase. At step 310, the first financial institution 104 generates a transaction request, which includes at least a recipient digital address, a digital token issued by the first financial institution 104 to the recipient digital address, a sender address, an asset network identifier, an asset identifier, and sends the transaction request to the processing server 106 at step 312. The processing server 106 is part of a multi-token network 112, which may include a blockchain network (e.g., blockchain network 116), and at step 312, the first financial institution 104 may send the transaction request to the blockchain network 116.

At step 314, the processing server 106 receives a transaction request from the first financial institution 104, and generates a security token for the digital token at step 318. The security token includes at least a unique symbol, a circulating amount, and an exchange value. In an embodiment, the processing server 106 may generate a security token on a private blockchain network within the multi-token network 112. For example, the processing server 106 may be a node in a licensed private blockchain network for generating security tokens for use in the multi-token network 112. In an embodiment in which the security token is generated on a private blockchain network, a smart contract may be used to transfer the security token between the private blockchain network and a public blockchain network (e.g., the asset network 114). At step 316, the processing server 106 may receive the transaction request directly from the first financial institution 104, or the first financial institution 104 may send the transaction request to the blockchain network (e.g., the blockchain network 116), and the processing server 106 and any other nodes (e.g., the first financial institution 114 and the second financial institution 108) may receive the transaction request as nodes in the blockchain network (e.g., the blockchain network 116).

At step 320, the processing server 106 generates an asset request transaction. The asset request transaction includes, but is not limited to, a collateral token, a recipient digital address of the receiving computing device 102, a sender digital address of the sending computing device 110, and an asset identifier. At step 322, the processing server 106 sends the asset request transaction to the asset network 114.

At step 324, the asset network 114 (e.g., one or more nodes of the asset network 114) receives an asset request from the processing server 106. The asset request may be received by a smart contract of the asset network 114 and/or a smart contract associated with the asset. At step 326, the asset network 114 may process the asset request and generate an asset transaction. For example, the asset network 114 may verify that the security token included in the asset request is capable of unlocking the smart contract associated with the asset network 114 and/or the asset. The asset transaction includes, but is not limited to, a recipient digital address of the receiving computing device 102 and a sender digital address of the sending computing device 110. At step 327, the asset network 114 sends the asset transaction to the processing server 106 and/or the blockchain network 116.

At step 328, processing server 106 receives the asset transaction from asset network 114. Processing server 106 may receive the asset transaction directly from a node within asset network 114, or a node in asset network 114 may send the asset transaction to a blockchain network (e.g., blockchain network 116), and at step 330, processing server 106 and any other nodes (e.g., first financial institution 104 and second financial institution 108) may receive the transaction request as nodes in the blockchain network (e.g., blockchain network 116).

At step 332, the processing server 106 generates an asset transfer transaction. The asset transfer transaction includes, but is not limited to, a recipient digital address of the receiving computing device 102, a sender digital address of the sending computing device 110, and an asset identifier. At step 334, the processing server 106 sends the asset transfer transaction to a blockchain network (e.g., blockchain network 116) and/or the digital address of the receiving computing device 102.

At steps 336 and 337, the blockchain network 116 and the digital address of the receiving computing device 102 may receive the asset transfer transaction, respectively. Alternatively, at step 338, the processing server 106 may only send the asset to the digital address of the receiving computing device 102. For example, the receiving computing device 102 is not part of the blockchain network (e.g., blockchain network 116), and at step 340, the digital address of the receiving computing device 102 receives the asset.

Returning to step 326, process 300 may also proceed to step 342, where the asset network 114 sends the security token for the asset transaction to the second financial institution 108. In embodiments where the security token is generated on a private blockchain network within the multi-token network 112, the asset network 114 may first send the security token to the processing server 106 to release the security token from the private blockchain network. In embodiments where the security token is generated on a private blockchain network, the processing server 106 may perform step 342 after the security token has been released from the private blockchain network. At step 344, the second financial institution 108 receives the security token from the asset network 114 and generates a redemption request including the security token at step 346. At step 348, the second financial institution 108 sends the redemption request to the processing server 106.

At step 350, processing server 106 receives a redemption request including a security token from second financial institution 108. At step 352, processing server 106 generates a settlement transaction message. The settlement transaction message includes, but is not limited to, a digital token and instructions to send the legal currency equivalent of the digital token from first financial institution 104 to second financial institution 108. At step 354, processing server 106 sends the settlement transaction message to first financial institution 104.

At step 356, the first financial institution 104 receives the settlement transaction message from the processing server 106. The first financial institution 104 may verify the settlement transaction message (e.g., based on the digital token itself, or based on the digital signature of the processing server 106, etc.). In response to the settlement transaction message, at step 358, the first financial institution 104 may unlock the legal currency amount equivalent to the digital token included in the settlement transaction message, and send the legal currency to the second financial institution 108 at step 360.

At step 362, the second financial institution 108 receives the legal tender from the first financial institution 104. The second financial institution 108 may generate a notification to the processing server 106 confirming receipt of the legal tender at step 364 and transmit the notification at step 366. At step 368, the processing server 106 receives the notification from the second financial institution 108.

Exemplary Methods for Transaction Settlement and Smart Contract Access Using Security Tokens

4A-4B illustrate a method 400 for transaction settlement and smart contract access using a security token, according to an exemplary embodiment.

At step 402, a receiving device (e.g., receiving device 202) of a processing server (e.g., processing server 106) receives a transaction request from a first financial institution (e.g., first financial institution 104). The transaction request includes at least, but is not limited to, a recipient digital address, a digital token issued by the first financial institution (e.g., first financial institution 104) to the recipient digital address, a sender address, an asset network identifier (e.g., an identifier of asset network 114), and an asset identifier. The digital token may be, but is not limited to, a digitized deposit token, a CBDC, or any other appropriate digital coin for conducting transactions in system 100. The recipient digital address, the asset network identifier, the sender digital address, and the asset identifier may constitute a digital asset contract (e.g., a contract to purchase or otherwise procure an asset from asset network 114). Asset network 114 may be a non-fungible token (NFT) market, and the asset may be an NFT.

At step 404, a generation module (e.g., generation module 216) of a processing server (e.g., processing server 106) generates a security token for a digital token, the security token including a processing device digital address. The security token is a tokenized security of a digital token issued by a first financial institution (e.g., first financial institution 104). For example, processing server 106 generates the security token based on the value of the digital token. The security token represents a legal claim to processing server 106 for the value of the digital token. Processing server 106 may (e.g., using query module 214) identify an asset smart contract associated with an asset on asset network 114. The asset smart contract may include one or more asset purchase requirements for the asset. When generating the security token, processing server 106 may utilize one or more requirements of the smart contract so that the security token unlocks the asset from asset network 114.

At step 406, a generation module (e.g., generation module 216) of a processing server (e.g., processing server 106) generates an asset request transaction. The asset request transaction includes at least, but is not limited to, a collateral token, a recipient digital address (e.g., a digital address of a receiving computing device 102), a sender digital address (e.g., a digital address of a sending computing device 110), and an asset identifier. At step 408, a sending device (e.g., sending device 220) of a processing server (e.g., processing server 106) sends the asset request transaction to an asset network (e.g., asset network 114). Processing server 106 may send the asset request transaction directly to asset network 114, or processing server 106 may send the asset request transaction to a blockchain network (e.g., blockchain network 116), and nodes in asset network 114 and any other nodes of blockchain network 116 may receive the asset request transaction as nodes in blockchain network 116.

At step 410, a receiving device (e.g., receiving device 202) of a processing server (e.g., processing server 106) receives an asset transaction from an asset network (e.g., a node of asset network 114 and/or a sending computing device 110). The asset transaction includes at least, but is not limited to, a receiving party digital address (e.g., a digital address of receiving computing device 102) and a sending party digital address (e.g., a digital address of sending computing device 110). In some embodiments, the asset transaction can be received on processing server 106 via a smart contract.

At step 412, a generation module (e.g., generation module 216) of a processing server (e.g., processing server 106) generates an asset transfer transaction. The asset transfer transaction includes at least, but is not limited to, a recipient digital address (e.g., a digital address of a receiving computing device 102), a sender digital address (e.g., a digital address of a sending computing device 110), and an asset identifier. At step 414, a sending device (e.g., sending device 220) of a processing server (e.g., processing server 106) sends the asset transfer transaction to the recipient digital address (e.g., a digital address of a receiving computing device 102). In an embodiment, processing server 106 may only send the asset, rather than the entire asset transfer transaction. In some embodiments, the asset transfer transaction may be generated on processing server 106 via a smart contract.

At step 416, a receiving device (e.g., receiving device 202) of a processing server (e.g., processing server 106) receives a redemption request from a second financial institution (e.g., second financial institution 108). The redemption request includes at least a security token (e.g., the security token generated by processing server 106 at step 404). In response to receiving the security token, at step 418, a generation module (e.g., generation module 216) of a processing server (e.g., processing server 106) generates a settlement transaction message. The settlement transaction message includes at least, but is not limited to, a digitized deposit token (e.g., a digital token issued by first financial institution 104) and an instruction to send the legal currency equivalent of the digitized deposit token from the first financial institution (e.g., first financial institution 104) to the second financial institution (e.g., second financial institution 108).

At step 420, a sending device (e.g., sending device 220) of a processing server (e.g., processing server 106) sends a settlement transaction message to a first financial institution (e.g., first financial institution 104). Processing server 106 may use a smart contract to receive and send settlement transaction messages.

The process of transaction settlement and smart contract access using security tokens and payment status tokens

5A-5B illustrate a process 500 for transaction settlement and smart contract access using a security token and a payment status token according to an exemplary embodiment. Process 500 shares steps 302-318 of process 300 and proceeds from step 318 to step 502. Process 500 decouples the tokenized security of a digital token issued by a first financial institution from the smart contract functionality of the security token. In process 500, the security token functions as a tokenized security of a digital token issued by a first financial institution, and the payment status token is used to unlock a smart contract associated with one or more assets on the asset network 114. In process 500, the security token is not sent to the asset network 114.

At step 502, the processing server 106 generates a payment status token. The payment status token includes asset transaction metadata. The asset transaction metadata includes, but is not limited to, one or more of a transaction reference, a transaction payment confirmation, an asset identification, an indication of a transaction payment failure, and an indication of a transaction payment delay. The asset transaction metadata can be used by the asset network 114 or any other external entity as proof of payment, transaction verifiability, and/or reconciliation (e.g., if the asset network 114 wants to charge a commission to the processing server 106). The payment status token is any suitable cryptographically verifiable messaging token, such as, but not limited to, a non-fungible ERC 721 token, an ERC 20 token, etc.

At step 504, processing server 106 sends a guarantee token (e.g., the guarantee token generated at step 318) to second financial institution 108. At step 506, second financial institution 108 receives the guarantee token from processing server 106. From step 506, process 500 proceeds to steps 346-368 of process 300.

At step 508, the processing server 106 generates an asset request transaction. The asset request transaction includes, but is not limited to, a payment status token, a recipient digital address of the receiving computing device 102, a sender digital address of the sending computing device 110, and an asset identifier. At step 510, the processing server 106 sends the asset request transaction to the asset network 114.

At step 512, the asset network 114 (e.g., one or more nodes of the asset network 114) receives an asset request from the processing server 106. The asset request may be received by a smart contract of the asset network 114 and/or a smart contract associated with the asset. The asset network 114 may receive the asset request directly from the processing server 106, or at step 511, the processing server 106 may send the asset request to a blockchain network (e.g., blockchain network 116), and at step 512, the nodes in the asset network 114 and any other nodes of the blockchain network 116 may receive the asset request as nodes in the blockchain network 116.

At step 514, the asset network 114 may process the asset request and generate an asset transaction. For example, the asset network 114 may verify that the payment status token included in the asset request is capable of unlocking a smart contract associated with the asset network 114 and/or the asset. The asset transaction includes, but is not limited to, a recipient digital address of the receiving computing device 102 and a sender digital address of the sending computing device 110. At step 516, the asset network 114 sends the asset transaction to the processing server 106 and/or the blockchain network 116. At step 518, the blockchain network 116 receives the asset transaction from the asset network 114. From step 516, the process 500 proceeds to steps 328-340 of the process 300.

From step 514, process 500 may proceed to step 520, where asset network 114 sends the payment status token to second financial institution 108 (at step 522) and/or processing server 106 (at step 524). Second financial institution 108 and/or processing server 106 may receive the payment status token directly from asset network 114, or asset network 114 may send the payment status token to a blockchain network (e.g., blockchain network 116), and second financial institution 108 and/or processing server 106 and any other nodes of blockchain network 116 may receive the payment status token as nodes in blockchain network 116. Steps 520-524 are optional in process 500, and asset network 114 may retain the payment status token. In an embodiment, steps 520-524 may occur simultaneously or sequentially with steps 504-368.

Exemplary methods for transaction settlement and smart contract access using security tokens and payment status tokens

6A-6B illustrate a method 600 for transaction settlement and smart contract access using a security token and a payment status token, according to an exemplary embodiment.

At step 602, a receiving device (e.g., receiving device 202) of a processing server (e.g., processing server 106) receives a transaction request from a first financial institution (e.g., first financial institution 104). The transaction request includes at least, but is not limited to, a recipient digital address, a digital token issued by the first financial institution (e.g., first financial institution 104) to the recipient digital address, a sender address, an asset network identifier (e.g., an identifier of asset network 114), and an asset identifier. The digital token may be, but is not limited to, a digitized deposit token, a CBDC, or any other appropriate digital coin for conducting transactions in system 100. The recipient digital address, the asset network identifier, the sender digital address, and the asset identifier may constitute a digital asset contract (e.g., a contract to purchase or otherwise procure an asset from asset network 114). Asset network 114 may be a non-fungible token (NFT) market, and the asset may be an NFT.

At step 604, a generation module (e.g., generation module 216) of a processing server (e.g., processing server 106) generates a security token for a digital token, the security token including a processing device digital address. The security token is a tokenized security of a digital token issued by a first financial institution (e.g., first financial institution 104). For example, processing server 106 generates the security token based on the value of the digital token. The security token represents a legal claim to processing server 106 for the value of the digital token. Processing server 106 may (e.g., using query module 214) identify an asset smart contract associated with an asset on asset network 114. The asset smart contract may include one or more asset purchase requirements for the asset. When generating the security token, processing server 106 may utilize one or more requirements of the smart contract so that the security token unlocks the asset from asset network 114.

At step 606, a generation module (e.g., generation module 216) of a processing server (e.g., processing server 106) generates a payment status token. The payment status token is a tokenized payment authorization message for payment of an asset associated with an asset identifier (e.g., the asset identifier of a transaction request). The payment status token includes asset transaction metadata. The asset transaction metadata includes, but is not limited to, one or more of a transaction reference, a transaction payment confirmation, an asset identifier, an indication of a transaction payment failure, and an indication of a transaction payment delay. The asset transaction metadata can be used by the asset network 114 or any other external entity as proof of payment, transaction verifiability, and/or reconciliation (e.g., if the asset network 114 wants to charge a commission to the processing server 106). The payment status token is any suitable cryptographically verifiable messaging token, such as, but not limited to, a non-fungible ERC 721 token, an ERC 20 token, etc. The processing server 106 can generate the payment status token on a private blockchain network (e.g., blockchain network 116), and the private blockchain network can include a smart contract for transferring the payment status token from the private blockchain network to the asset network 114 as described below in step 610.

At step 608, a generation module (e.g., generation module 216) of a processing server (e.g., processing server 106) generates an asset request transaction. The asset request transaction includes at least, but is not limited to, a payment status token, a recipient digital address (e.g., a digital address of receiving computing device 102), a sender digital address (e.g., a digital address of sending computing device 110), and an asset identifier.

At step 610, a sending device (e.g., sending device 220) of a processing server (e.g., processing server 106) sends the asset request transaction to an asset network (e.g., asset network 114). Processing server 106 may send the asset request transaction directly to asset network 114, or processing server 106 may send the asset request transaction to a blockchain network (e.g., blockchain network 116), and a node in asset network 114 and any other node of blockchain network 116 may receive the asset request transaction as a node in blockchain network 116.

At step 612, a sending device (e.g., sending device 220) of a processing server (e.g., processing server 106) sends the security token to a second financial institution (e.g., second financial institution 108) associated with the sender address (e.g., the digital address of sending computing device 110).

At step 614, a receiving device (e.g., receiving device 202) of a processing server (e.g., processing server 106) receives an asset transaction from an asset network (e.g., a node of asset network 114 and/or a sending computing device 110). The asset transaction includes at least, but is not limited to, an asset, a recipient digital address (e.g., a digital address of receiving computing device 102), and a sender digital address (e.g., a digital address of sending computing device 110). In some embodiments, the asset transaction may be received by a smart contract on processing server 106. In some embodiments, the asset transaction may include a payment status token. For example, once the asset network 114 has used the payment status token to confirm that a payment has been made for an asset on the asset network 114, the asset network 114 returns the payment status token to the processing server 106. Alternatively, the asset network 114 may send the payment status token to the second financial institution 108, or the asset network 114 may retain and store or retain and destroy the payment status token.

At step 616, a generation module (e.g., generation module 216) of a processing server (e.g., processing server 106) generates an asset transfer transaction. The asset transfer transaction includes at least, but is not limited to, a recipient digital address (e.g., a digital address of a receiving computing device 102), a sender digital address (e.g., a digital address of a sending computing device 110), and an asset identifier. At step 618, a sending device (e.g., sending device 220) of a processing server (e.g., processing server 106) sends the asset transfer transaction to the recipient digital address (e.g., a digital address of a receiving computing device 102). In an embodiment, processing server 106 may only send the asset, rather than sending the entire asset transfer transaction. In some embodiments, the asset transfer transaction may be generated on processing server 106 via a smart contract.

From step 618 , process 600 may proceed to steps 416 - 420 of process 400 .

Computer system architecture

FIG7 illustrates a computer system 700 in which embodiments of the present disclosure or portions thereof may be implemented as computer readable code. For example, the processing server 106 and blockchain nodes within the blockchain network 116 of FIG1 and the processing server 106 of FIG2 may be implemented in the computer system 700 using hardware, a non-transitory computer readable medium having instructions stored thereon, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The hardware may embody the modules and components for implementing the methods of FIG3A-FIG6B.

If programmable logic is used, such logic can be executed on a commercially available processing platform that is configured by executable software code to become a special-purpose computer or special-purpose device (e.g., a programmable logic array, an application-specific integrated circuit, etc.). It will be appreciated by those of ordinary skill in the art that various embodiments of the disclosed subject matter can be practiced using a variety of computer system configurations, including multi-core multi-processor systems, minicomputers, mainframe computers, linked or clustered computers with distributed functions, and ubiquitous or microcomputers that can be embedded in almost any device. For example, the above embodiments can be implemented using at least one processor device and a memory.

The processor unit or device described herein may be a single processor, multiple processors, or a combination thereof. A processor device may have one or more processor "cores". The terms "computer program medium", "non-transitory computer readable medium", and "computer usable medium" described herein are used to generally refer to tangible media such as removable storage unit 718, removable storage unit 722, and a hard disk installed in hard disk drive 712.

Various embodiments of the present disclosure are described using this example computer system 700. After reading this description, it will become apparent to those skilled in the relevant art how to implement the present disclosure using other computer systems and/or computer architectures. Although operations may be described as being processed sequentially, some operations may in fact be performed in parallel, simultaneously, and/or in a distributed environment, with program code being stored locally or remotely for access by a single processor or a multi-processor machine. Additionally, in some embodiments, the order of the various operations may be rearranged without departing from the spirit of the disclosed subject matter.

Processor device 704 can be a dedicated or general processor device specially configured to perform the functions discussed herein. Processor device 704 can be connected to communication infrastructure 706, such as bus, message queue, network, multi-core message delivery scheme, etc. The network can be any network suitable for performing the functions disclosed herein, and can include local area network (LAN), wide area network (WAN), wireless network (e.g., WiFi), mobile communication network, satellite network, Internet, optical fiber, coaxial cable, infrared, radio frequency (RF) or any combination thereof. Other suitable network types and formations will be obvious to those skilled in the relevant art. Computer system 700 can also include main memory 708 (e.g., random access memory, read-only memory, etc.), and can also include auxiliary memory 710. Auxiliary memory 710 can include hard disk drive 712 and removable storage drive 714, such as floppy disk drive, tape drive, optical disk drive, flash memory, etc.

The removable storage drive 714 can read and/or write to the removable storage unit 718 in a known manner. The removable storage unit 718 may include a removable storage medium that can be read and written by the removable storage drive 714. For example, if the removable storage drive 714 is a floppy disk drive or a universal serial bus port, the removable storage unit 718 may be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage unit 718 may be a non-transitory computer-readable recording medium.

In some embodiments, the secondary memory 710 may include an alternative, for example, removable storage unit 722 and interface 720, for allowing computer programs or other instructions to be loaded into the computer system 700. Examples of such devices may include program cartridges and cartridge interfaces (e.g., as found in video game systems), removable storage chips (e.g., EEPROM, PROM, etc.) and associated sockets, as well as other removable storage units 722 and interfaces 720, as will be apparent to those skilled in the relevant art.

Data stored in the computer system 700 (e.g., in the main memory 708 and/or the secondary memory 710) may be stored on any type of suitable computer-readable medium, such as optical storage (e.g., compact disks, digital versatile disks, Blu-ray disks, etc.) or tape storage devices (e.g., hard drives). The data may be configured in any type of suitable database configuration, such as a relational database, a structured query language (SQL) database, a distributed database, an object database, etc. Suitable configurations and types of storage devices will be apparent to those skilled in the relevant art.

The computer system 700 may also include a communication interface 724. The communication interface 724 may be configured to allow software and data to be transferred between the computer system 700 and external devices. Exemplary communication interfaces 724 may include a modem, a network interface (e.g., an Ethernet card), a communication port, a PCMCIA slot and card, etc. The software and data transferred via the communication interface 724 may be in the form of a signal, which may be an electronic signal, an electromagnetic signal, an optical signal, or other signal, as will be apparent to those skilled in the relevant art. The signal may be propagated via a communication path 726, which may be configured to carry the signal, which may be implemented using a wire, cable, optical fiber, telephone line, cellular phone link, radio frequency link, etc.

The computer system 700 may also include a display interface 702. The display interface 702 may be configured to allow data to be transferred between the computer system 700 and an external display 730. Exemplary display interfaces 702 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics array (VGA), etc. The display 730 may be any suitable type of display for displaying data transferred via the display interface 702 of the computer system 700, including a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light emitting diode (LED) display, a capacitive touch display, a thin film transistor (TFT) display, etc.

Computer program media and computer usable media may refer to memory, such as main memory 708 and auxiliary memory 710, which may be semiconductor memory (e.g., DRAM, etc.). These computer program products may be tools for providing software to computer system 700. Computer programs (e.g., computer control logic) may be stored in main memory 708 and/or auxiliary memory 710. Computer programs may also be received via communication interface 724. Such computer programs, when executed, may enable computer system 700 to implement methods as described herein. In particular, computer programs, when executed, may enable processor device 704 to implement methods as illustrated in FIG. 3A-FIG. 6B as described herein. Thus, such computer programs may represent controllers of computer system 700. In the case of implementing the present disclosure using software, the software may be stored in a computer program product and loaded into computer system 700 using removable storage drive 714, interface 720 and hard disk drive 712, or communication interface 724.

The processor device 704 may include one or more modules or engines configured to perform the functions of the computer system 700. Each module or engine may be implemented using hardware, and in some cases, software may also be used, such as software corresponding to program code and/or programs stored in the main memory 708 or the auxiliary memory 710. In such cases, the program code may be compiled by the processor device 704 (e.g., by a compilation module or engine) before being executed by the hardware of the computer system 700. For example, the program code may be a source code written in a programming language, which is translated into a low-level language, such as an assembly language or machine code, so as to be executed by the processor device 704 and/or any other hardware component of the computer system 700. The compilation process may include lexical analysis, preprocessing, syntactic analysis, semantic analysis, syntax-directed translation, code generation, code optimization, and the use of any other technology that may be suitable for translating the program code into a low-level language suitable for controlling the computer system 700 to perform the functions disclosed herein. It is obvious to those skilled in the relevant art that such processing results in the computer system 700 being a specially configured computer system 700 that is uniquely programmed to perform the above-mentioned functions.

Among other features, the technology consistent with the present disclosure provides a system and method for generating a digital three-dimensional representation of a dental object during scanning with a dental imaging device. Although various exemplary embodiments of the disclosed system and method are described above, it should be understood that they are provided for the purpose of illustration only and not limitation. The above description is not exhaustive and does not limit the present disclosure to the specific form disclosed. In view of the above teachings, various modifications and changes are possible, or various modifications and changes can be obtained from the practice of the present disclosure without departing from the breadth or scope. Although the operations can be described as sequential processing, some operations can actually be performed in parallel, simultaneously and/or in a distributed environment, while the program code is stored locally or remotely for access by a single processor or a multi-processor machine. In addition, in some embodiments, the order of the various operations can be rearranged without departing from the spirit of the disclosed subject matter. It will be appreciated by those skilled in the art that the present disclosure can be embodied in other specific forms without departing from its spirit or basic characteristics. Therefore, the embodiments disclosed at present are considered to be illustrative and not restrictive in all aspects. The scope of the present disclosure is indicated by the appended claims rather than the above description, and all changes within its meaning, scope and equivalents are intended to be included therein.

Claims (34)

1. A method for transaction settlement using a security token, the method comprising: Receiving, by a receiving device of the processing server, a transaction request from a first financial institution, the transaction request including at least a recipient digital address, a digital token issued by the first financial institution to the recipient digital address, a sender address, an asset network identifier, and an asset identifier; generating, by a generation module of the processing server, a guarantee token for the digital token, the guarantee token being a tokenized guarantee of the digital token issued by the first financial institution; The generating module of the processing server generates an asset request transaction, wherein the asset request transaction includes at least the security token, the digital address of the recipient, the digital address of the sender, and the asset identifier; The sending device of the processing server sends the asset request transaction to the asset network; Receiving an asset transaction from the asset network by a receiving device of the processing server, the asset transaction comprising at least an asset, a receiver digital address and a sender digital address; generating an asset transfer transaction by a generation module of the processing server, wherein the asset transfer transaction includes at least a receiver digital address, a sender digital address and an asset identifier; and The asset transaction is sent to the recipient digital address by the sending device of the processing server. 2. The method of claim 1, wherein the processing server, the first financial institution, and the second financial institution are part of a blockchain network, and wherein the transaction request, asset request transaction, asset transaction, and asset transfer transaction are recorded on a blockchain of the blockchain network. 3. The method according to claim 1, further comprising: receiving, by a receiving device of the processing server, a redemption request from a second financial institution, the redemption request including the security token; generating, by a generation module of the processing server, a settlement transaction message, the settlement transaction message including at least the digital token and an instruction to send the legal tender equivalent of the digital token from the first financial institution to the second financial institution; and The sending device of the processing server sends the settlement transaction message to the first financial institution. 4. The method of claim 3, wherein the digital token is a digitized deposit token. 5. The method of claim 1 , wherein the processing server generates the security token on a private blockchain network, and wherein the private blockchain network includes a smart contract for transferring the security token from the private blockchain network to the asset network. 6. A method according to claim 1, wherein the recipient digital address, asset network identifier, sender digital address and asset identifier constitute a digital asset contract. 7. The method of claim 1 , wherein sending the asset request transaction to the asset network comprises sending the asset request transaction to a smart contract on the asset network. 8. The method of claim 1, wherein the asset network is a non-fungible token (NFT) marketplace, and wherein the assets are NFTs. 9. The method of claim 1, wherein receiving the asset from the asset network and sending the asset to the recipient digital address is performed by the processing server using a smart contract. 10. The method according to claim 1, further comprising: identifying, by the processing server, an asset smart contract on the asset network, the asset smart contract having one or more asset purchase requirements; and The security token is generated to unlock the asset smart contract. 11. A system for transaction settlement using a security token, the method comprising: The receiving device of the processing server receives a transaction request from a first financial institution, the transaction request including at least a recipient digital address, a digital token issued by the first financial institution to the recipient digital address, a sender digital address, an asset network identifier, and an asset identifier; The generation module of the processing server generates a guarantee token for the digital token, the guarantee token being a tokenized guarantee of the digital token issued by the first financial institution; The generation module of the processing server generates an asset request transaction, wherein the asset request transaction includes at least the security token, the digital address of the recipient, the digital address of the sender, and the asset identifier; The sending device of the processing server sends the asset request transaction to the asset network; The receiving device of the processing server receives an asset transaction from the asset network, the asset transaction comprising at least an asset, a receiver digital address and a sender digital address; The generating module of the processing server generates an asset transfer transaction, wherein the asset transfer transaction includes at least a receiver digital address, a sender digital address and an asset identifier; and The sending device of the processing server sends the asset transaction to the recipient digital address. 12. The system of claim 11, wherein the processing server, the first financial institution, and the second financial institution are part of a blockchain network, and wherein the transaction request, asset request transaction, asset transaction, and asset transfer transaction are recorded on a blockchain of the blockchain network. 13. The system of claim 11, further comprising: The receiving device of the processing server receives a redemption request from a second financial institution, the redemption request including the security token; The generation module of the processing server generates a settlement transaction message, the settlement transaction message including at least the digital token and an instruction to send the legal tender equivalent of the digital token from the first financial institution to the second financial institution; and The sending device of the processing server sends the settlement transaction message to the first financial institution. 14. The system of claim 13, wherein the digital token is a digitized deposit token. 15. The system of claim 11, wherein the processing server generates the security token on a private blockchain network, and wherein the private blockchain network includes a smart contract for transferring the security token from the private blockchain network to the asset network. 16. A system according to claim 11, wherein the recipient digital address, asset network identifier, sender digital address and asset identifier constitute a digital asset contract. 17. The system of claim 11, wherein sending the asset request transaction to the asset network comprises sending the asset request transaction to a smart contract on the asset network. 18. The system of claim 11, wherein the asset network is a non-fungible token (NFT) marketplace, and wherein the assets are NFTs. 19. The system of claim 11, wherein receiving the asset from the asset network and sending the asset to the recipient digital address is performed by the processing server using a smart contract. 20. The system of claim 11, further comprising: The processing server identifies an asset smart contract on the asset network, the asset smart contract having one or more asset purchase requirements; and The security token is generated to unlock the asset smart contract. 21. A method for transaction settlement using a guarantee token and a payment status token, the method comprising: Receiving, by a receiving device of the processing server, a transaction request from a first financial institution, the transaction request including at least a recipient digital address, a digital token issued by the first financial institution to the recipient digital address, a sender address, an asset network identifier, and an asset identifier; generating, by a generation module of the processing server, a guarantee token for the digital token, the guarantee token being a tokenized guarantee of the digital token issued by the first financial institution; generating, by a generation module of the processing server, a payment status token, the payment status token being a tokenized payment authorization message for payment of an asset associated with the asset identifier; The generating module of the processing server generates an asset request transaction, wherein the asset request transaction includes at least the payment status token, the digital address of the recipient, the digital address of the sender, and the asset identifier; The sending device of the processing server sends the asset request transaction to the asset network; sending, by a sending device of the processing server, the security token to a second financial institution associated with the sender address; Receiving an asset transaction from the asset network by a receiving device of the processing server, the asset transaction comprising at least an asset, a receiver digital address and a sender digital address; generating an asset transfer transaction by a generation module of the processing server, wherein the asset transfer transaction includes at least a receiver digital address, a sender digital address and an asset identifier; and The asset transaction is sent to the recipient digital address by the sending device of the processing server. 22. The method of claim 21, wherein the asset transaction further includes the payment status token. 23. A method according to claim 21, wherein the processing server, the first financial institution and the second financial institution are part of a blockchain network, and wherein the transaction request, asset request transaction, asset transaction and asset transfer transaction are recorded on a blockchain of the blockchain network. 24. The method of claim 21, wherein the processing server generates the payment status token on a private blockchain network, and wherein the private blockchain network includes a smart contract for transferring the payment status token from the private blockchain network to the asset network. 25. The method of claim 21, wherein sending the asset request transaction to the asset network comprises sending the asset request transaction to a smart contract on the asset network, and the payment status token unlocks the smart contract on the asset network. 26. A method according to claim 21, wherein the payment status token includes asset transaction metadata, and the asset transaction metadata includes one or more of a transaction reference, a transaction payment confirmation, an asset identification, an indication of a transaction payment failure, and an indication of a transaction payment delay. 27. The method of claim 21, wherein the payment state token is a non-fungible ERC-721 token. 28. A system for transaction settlement using a guarantee token and a payment status token, the method comprising: The receiving device of the processing server receives a transaction request from a first financial institution, the transaction request including at least a recipient digital address, a digital token issued by the first financial institution to the recipient digital address, a sender digital address, an asset network identifier, and an asset identifier; The generation module of the processing server generates a guarantee token for the digital token, the guarantee token being a tokenized guarantee of the digital token issued by the first financial institution; The generation module of the processing server generates a payment status token, the payment status token being a tokenized payment authorization message for payment of the asset associated with the asset identifier; The generation module of the processing server generates an asset request transaction, wherein the asset request transaction includes at least the payment status token, the recipient digital address, the sender digital address and the asset identifier; The sending device of the processing server sends the asset request transaction to the asset network; The sending device of the processing server sends the security token to a second financial institution associated with the sender address; The receiving device of the processing server receives an asset transaction from the asset network, the asset transaction comprising at least an asset, a receiver digital address and a sender digital address; The generating module of the processing server generates an asset transfer transaction, wherein the asset transfer transaction includes at least a receiver digital address, a sender digital address and an asset identifier; and The sending device of the processing server sends the asset transaction to the recipient digital address. 29. The system of claim 28, wherein the asset transaction further includes the payment status token. 30. The system of claim 28, wherein the processing server, the first financial institution, and the second financial institution are part of a blockchain network, and wherein the transaction request, asset request transaction, asset transaction, and asset transfer transaction are recorded on a blockchain of the blockchain network. 31. The system of claim 28, wherein the processing server generates the payment status token on a private blockchain network, and wherein the private blockchain network includes a smart contract for transferring the payment status token from the private blockchain network to the asset network. 32. The system of claim 28, wherein sending the asset request transaction to the asset network comprises sending the asset request transaction to a smart contract on the asset network, and the payment status token unlocks the smart contract on the asset network. 33. A system according to claim 28, wherein the payment status token includes asset transaction metadata, and the asset transaction metadata includes one or more of a transaction reference, a transaction payment confirmation, an asset identification, an indication of a transaction payment failure, and an indication of a transaction payment delay. 34. The system of claim 28, wherein the payment status token is a non-fungible ERC-721 token.