Method and system for transaction settlement and access to smart contracts using endorsement tokens

Abstract

A method for settling a transaction using an assurance token includes receiving a transaction request from a financial institution, the transaction request including a receiving party digital address, a digital token, a sending party address, an asset network identification, and an asset identification; generating an assurance token for the digital token, generating an asset request transaction including the assurance token, the receiving party digital address, the sending party digital address, and an identification of the asset, sending the asset request transaction to the asset network, receiving an asset transaction from the asset network, the asset transaction including the asset, the receiving party digital address, and the sending party digital address, generating an asset transfer transaction including the receiving party digital address, the sending party digital address, and an identification of the asset, and sending the asset transaction to the receiving party digital address.

Description

[Technical field]

[0001] The present disclosure relates to transaction settlement and access to smart contracts using endorsement tokens or a combination of endorsement tokens and payment status tokens. In particular, the present disclosure relates to the settlement of digital token transactions for assets secured by one or more smart contracts.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 330,432 (filed April 13, 2022) and U.S. Provisional Patent Application No. 63 / 424,242 (filed November 10, 2022), the entire contents of which are incorporated by reference for all purposes. [Background technology]

[0003] The cryptocurrency market has shown tremendous growth, with a total market capitalization exceeding $1.5 trillion. To date, the market has mainly benefited cryptocurrency insiders and has not contributed much to mainstream use. Stablecoins, which have been primarily used to enter and exit cryptocurrency trading positions, are beginning to make inroads into mainstream use cases such as remittances, supplier B2B payments, and commercial payments. However, stablecoins still fall short in some areas, including opaque regulatory aspects, fraud, and unpredictable costs. At the same time, central banks are considering Central Bank Digital Currencies (CBDCs), which could provide citizens with a digital version of fiat currency. However, the path to CBDCs will likely be different for each country, will take years to deploy in a live environment, and may ultimately not provide all of the potential functionality of stablecoins. Despite challenges with current solutions, blockchain-based payments could offer several advantages, including transparency (e.g., the ability for participants to view the status and details of a transaction), immutability (e.g., ensuring that a transaction cannot be altered or deleted by other entities), speed (e.g., the potential to achieve faster processing of transactions, particularly those that are cross-border), cost-efficiency (e.g., reducing manual tasks and streamlining costs associated with cross-border fund movements), and programmability (e.g., digitally native payment tokens can be coded to execute payments upon the fulfillment of certain conditions, enabling creative use cases).

[0004] Currently, much of the development of cryptocurrency technology focuses on the opportunities presented by decentralized versus centralized uses and services. On the other hand, there has been little innovation in the cryptocurrency market focused on creating a flexible financial infrastructure that meets regulatory requirements and expectations and provides consumer protection while preserving the stability of the current financial system. Thus, there is a need for novel solutions for regulated payment services that enable the use of digital currencies (e.g., cryptocurrencies) in a manner that preserves the security features and other advantages of cryptocurrency systems without the associated volatility in value. Summary of the Invention

[0005] A method of transaction settlement and access to smart contracts using endorsement tokens is disclosed, the method comprising the steps of: receiving, by a receiving device of a processing server, a transaction request from a first financial institution, the transaction request including at least a receiving party digital address, a digital token issued by the first financial institution to the receiving party digital address, a sending party address, an identification of an asset network, and an identification of an asset; generating, by a generating module of the processing server, an endorsement token for the digital token, the endorsement token being a tokenized endorsement of the digital token issued by the first financial institution; and generating, by the generating module of the processing server, an asset request transaction, the asset request transaction including at least the endorsement token, the receiving party digital address, the sending party digital address, and an identification of an asset. and an identification of the asset; transmitting the asset request transaction to the asset network by a transmitting device of the processing server; receiving an asset transaction from the asset network by a receiving device of the processing server, the asset transaction including at least the asset, the receiving party digital address, and the sending party digital address; generating an asset transfer transaction by the generating module of the processing server, the asset transfer transaction including at least the receiving party digital address, the sending party digital address, and an identification of the asset; and transmitting the asset transfer transaction to the receiving party digital address by a transmitting device of the processing server.

[0006] A system for transaction settlement and access to smart contracts using endorsement tokens is disclosed, the system including: a receiving device of a processing server that receives a transaction request from a first financial institution, the transaction request including at least a receiving party digital address, a digital token issued by the first financial institution to the receiving party digital address, a sending party digital address, an identification of an asset network, and an identification of an asset; and a generating module of the processing server that generates an endorsement token for the digital token, the endorsement token being a tokenized endorsement of the digital token issued by the first financial institution, the generating module of the processing server generating an asset request transaction, the asset request transaction including the endorsement token, the receiving party digital address, and the sending party digital address. a generating module including at least an address and an identification of the asset; a transmitting device of the processing server that transmits 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 including at least the asset, the receiving party digital address, and the sending party digital address; the generating module of the processing server generates an asset transfer transaction, the asset transfer transaction including at least the receiving party digital address, the sending party digital address, and an identification of the asset; and the transmitting device of the processing server transmits the asset transfer transaction to the receiving party digital address.

[0007] A method of transaction settlement using an endorsement token and a payment status token is disclosed, the method including the steps of: receiving, by a receiving device of a processing server, a transaction request from a first financial institution, the transaction request including at least a receiving party digital address, a digital token issued by the first financial institution to the receiving party digital address, a sending party address, an identification of an asset network, and an identification of an asset; generating, by a generating module of the processing server, an endorsement token for the digital token, the endorsement token being a tokenized endorsement of the digital token issued by the first financial institution; generating, by the generating module of the processing server, a payment status token, the payment status token being a tokenized payment acknowledgement message for a payment for an asset associated with the identification of the asset; generating, by the generating module of the processing server, an asset request transaction, the asset request a transaction including at least the payment status token, the receiving party digital address, the sending party digital address, and an identification of the asset; transmitting the asset request transaction to the asset network by a sending device of the processing server; transmitting the assurance token to a second financial institution associated with the sending party address by the sending device of the processing server; receiving an asset transaction from the asset network by a receiving device of the processing server, the asset transaction including at least the asset, the receiving party digital address, and the sending party digital address; generating an asset transfer transaction by the generating module of the processing server, the asset transfer transaction including at least the receiving party digital address, the sending party digital address, and an identification of the asset;transmitting, by the transmitting device of the processing server, the asset transaction to the receiving party digital address;

[0008] A system for transaction settlement using an endorsement token and a payment status token is disclosed, the system including: a receiving device of a processing server for receiving a transaction request from a first financial institution, the transaction request including at least a receiving party digital address, a digital token issued by the first financial institution to the receiving party digital address, a sending party digital address, an identification of an asset network, and an identification of an asset; a generating module of the processing server for generating an endorsement token for the digital token, the endorsement token being a tokenized endorsement of the digital token issued by the first financial institution, the generating module of the processing server generating a payment status token, the payment status token being a tokenized payment acknowledgement message for a payment for an asset associated with the identification of the asset, and the generating module of the processing server generating an asset request transaction, the asset request transaction including the payment status token and the receiving party digital address; the sending party digital address, the sending party digital address, and an identification of the asset; a generating module of the processing server that transmits the asset request transaction to the asset network; the transmitting device of the processing server transmits the guarantee token to a second financial institution associated with the sending party address; the receiving device of the processing server receives an asset transaction from the asset network, the asset transaction including at least the asset, the receiving party digital address, and the sending party digital address; the generating module of the processing server generates an asset transfer transaction, the asset transfer transaction including at least the receiving party digital address, the sending party digital address, and an identification of the asset; and the transmitting device of the processing server transmits the asset transaction to the receiving party digital address. [Brief description of the drawings]

[0009] The scope of the present disclosure is best understood from the following detailed description of illustrative embodiments when taken in conjunction with the accompanying drawing figures, which include:

[0010] [Figure 1] FIG. 1 is a block diagram illustrating a high-level system architecture for transaction settlement and access to smart contracts using assurance tokens, according to an example embodiment. [Diagram 2] FIG. 2 is a block diagram illustrating a processing server of the system of FIG. 1 for transaction settlement using assurance tokens and access to smart contracts, according to an example embodiment. [Figure 3A] 2 is a flow diagram illustrating a process for transaction settlement and access to smart contracts using an assurance token performed by the processing server of FIG. 2 in the system of FIG. 1 according to an exemplary embodiment. [Figure 3B] 2 is a flow diagram illustrating a process for transaction settlement and access to smart contracts using an assurance token performed by the processing server of FIG. 2 in the system of FIG. 1 according to an exemplary embodiment. [Figure 3C] 2 is a flow diagram illustrating a process for transaction settlement and access to smart contracts using an assurance token performed by the processing server of FIG. 2 in the system of FIG. 1 according to an exemplary embodiment. [Figure 3D] 2 is a flow diagram illustrating a process for transaction settlement and access to smart contracts using an assurance token performed by the processing server of FIG. 2 in the system of FIG. 1 according to an exemplary embodiment. [Figure 3E] 2 is a flow diagram illustrating a process for transaction settlement and access to smart contracts using an assurance token performed by the processing server of FIG. 2 in the system of FIG. 1 according to an exemplary embodiment. [Figure 4A]1 is a flow diagram illustrating an example method for transaction settlement and access to smart contracts using assurance tokens, according to an example embodiment. [Figure 4B] 1 is a flow diagram illustrating an example method for transaction settlement and access to smart contracts using assurance tokens, according to an example embodiment. [Figure 5A] 2 in the system of FIG. 1 according to an exemplary embodiment. [Figure 5B] 2 in the system of FIG. 1 according to an exemplary embodiment. [Figure 6A] 1 is a flow diagram illustrating an example method for transaction settlement and access to smart contracts using assurance tokens and payment status tokens, according to an example embodiment. [Figure 6B] 1 is a flow diagram illustrating an example method for transaction settlement and access to smart contracts using assurance tokens and payment status tokens, according to an example embodiment. [Figure 7] FIG. 1 is a block diagram illustrating a computer system architecture in accordance with an exemplary embodiment.

[0011] Further areas of applicability of the present disclosure will become apparent from the following detailed description. The detailed description of the exemplary embodiments is intended for purposes of illustration only and is not intended to necessarily limit the scope of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Glossary Blockchain: A public ledger of all transactions of a blockchain-based currency. One or more computing devices may include a blockchain network, which may be configured to process and record transactions as part of a block in the blockchain. Once a block is complete, it is added to the blockchain, thereby updating the transaction record. In many embodiments, the blockchain may be a chronological ledger of transactions, or may be presented in any other order suitable for use by the blockchain network. In some embodiments, a transaction recorded in the blockchain may include a destination address and a currency amount. The blockchain then records how much currency is attributed to a particular address. In some embodiments, a transaction may or may not be financial-related, and may include additional or different information (e.g., source address, timestamp, etc.). In some embodiments, the blockchain may additionally or alternatively include almost any type of data in the form of transactions that is or needs to be placed in a distributed database that maintains a continuously growing list of data records that are hardened against tampering or revision. Alternatively, the blockchain may be verified and validated by the blockchain network by proof-of-work (PoW) and / or any other suitable verification technique associated therewith. In some cases, the data about a given transaction may further include additional data that is not directly part of the transaction that is added to the transaction data. In some examples, the inclusion of such data in the blockchain may constitute a transaction. In some such examples, the blockchain may not be directly associated with a particular digital, virtual, fiat, or other type of currency.

[0013] A system for settling transactions and accessing smart contracts using endorsement tokens FIG. 1 illustrates an example system 100 for transaction settlement and access to smart contracts using assurance tokens, according to an example embodiment.

[0014] The 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 .

[0015] 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 with the first financial institution 104). For example, the user of the receiving computing device 102 has a digital address, such as a digital wallet, for transacting deposit tokens issued by the first financial institution 104. Additionally, 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 or access to the asset network 114 and may purchase one or more assets (e.g., purchasing a non-fungible token or "NFT" on an NFT marketplace). Transactions involving the receiving computing device 102 are described in more detail below and with reference to FIGS. 3A-6B. The receiving computing device 102 may be a desktop computer, a notebook, a laptop computer, a tablet computer, a handheld device, a smart phone, a thin client, or any other electronic device or computing system that stores, compiles, and organizes audio, visual, or textual data and receives / transmits such data 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 described functions, such as the computer system 700 shown in FIG. 7. It should be noted that while only a single receiving computing device 102 is illustrated, the system 100 may include any number of receiving computing devices 102.

[0016] The first financial institution 104 may be a financial institution such as an issuing bank or any other entity configured to issue a transaction account suitable for funding electronic payment transactions with fiat currency or digital tokens. The first financial institution 104 may be a financial entity that issues, including but not limited to, central bank digital currencies (CBDCs), regulated stable coins, digitized deposit tokens, or any suitable digital tokens that represent legal claims against 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 stable coin issuer, or any other suitable financial entity that may issue digital tokens. In an embodiment in which the first financial institution 104 is a central bank, the digital token represents a liability of the central bank (e.g., a CBDC). In an embodiment in which the first financial institution 104 is a bank, the digital token represents a digitized deposit, which is a digitized version of a deposit liability. In an embodiment in which the first financial institution 104 is an electronic currency issuer, the digital token represents an electronic currency liability. In embodiments where the first financial institution 104 is a stablecoin issuer, the digital token represents a legal claim associated with the stablecoin interest. The digital token is a digital representation of the corresponding first financial institution 104's deposit liability, including but not limited to legal claims against the first financial institution 104, withdrawal claims, depositor claims, deposit guarantee claims, etc. The underlying deposit and associated characteristics that the digital token represents do not change due to tokenization. Digital tokens issued by the first financial institution 104 include one or more of the following, but are not limited to: the amount issued (e.g., the fiat currency equivalent of the digital token), the currency (e.g., the fiat currency for which the digital token is issued), the issue date (e.g., the date the digital token was created), and any other suitable metadata (e.g., an identity of the first financial institution 104, an identity of the receiving computing device 102, a digital address of the receiving computing device 102, etc.).

[0017] The first financial institution 104 can be an authorized entity on the multi-token network 112 and can interact with the multi-token network 112 to provide customer products such as digital wallets. The first financial institution 104 can be authorized to create and manage wallets (e.g., digital addresses) for its 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 its customers (e.g., users of the receiving computing device 102). Additionally, the first financial institution 104 can issue payment instruments to the receiving computing device 102, which can be physical payment cards, virtual payment cards, paper checks, virtual checks, and the like. The receiving computing device 102 can accept digital wallets and / or other payment instruments and communicate payment authentication information associated with a transaction account to fund a payment transaction using the transaction account.

[0018] The processing server 106 may be a server, desktop computer, notebook computer, laptop computer, tablet computer, handheld device, smartphone, thin client, or any other electronic device or computing system that stores, compiles, and organizes audio, visual, or textual data and receives / transmits such data from / to other computing devices, such as 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. For example, the processing server 106 may be any type of electronic device or computing system specifically configured to perform the described functions, such as computer system 700 shown in FIG. In an exemplary embodiment, the processing server 106 is an operator and / or administrative node on the multi-token network 112 and may: send and receive digital tokens to and from the first financial institution 104 and the second financial institution 108; generate endorsement tokens for the digital tokens; generate payment state tokens for unlocking one or more smart contracts on the asset network 114; receive, generate, and / or send transaction messages and requests to and from 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; send and receive assets to and from the asset network 114, the receiving computing device 102, and the sending computing device 110; receive requests to redeem endorsement tokens from the first financial institution 104 and the second financial institution 108; and generate and send settlement transaction messages to the first financial institution 104 and the second financial institution 108. The processing server 106 is described in more detail with reference to FIG. 2.

[0019] The second financial institution 108 may be a financial institution such as an accepting bank or any other entity configured to issue a transaction account suitable for funding an electronic payment transaction with fiat currency or a digital token. The second financial institution 108 may be a financial entity that issues, including but not limited to, a central bank digital currency (CBDC), a regulated stable coin, a digitized deposit token, or any other suitable digital token that represents a legal claim against 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 stable coin issuer, or any other suitable financial entity that may issue a digital token. In an embodiment in which the second financial institution 108 is a central bank, the digital token represents a central bank liability (e.g., a CBDC). In an embodiment in which the second financial institution 108 is a bank, the digital token represents a digitized deposit, which is a digitized version of a deposit liability. In an embodiment in which the second financial institution 108 is an electronic currency issuer, the digital token represents an electronic currency liability. In embodiments where the second financial institution 108 is a stablecoin issuer, the digital token represents a legal claim associated with the stablecoin interest. The digital token is a digital representation of the deposit liability of the corresponding second financial institution 108, including but not limited to a legal claim against the second financial institution 108, a withdrawal claim, a depositor claim, a deposit guarantee claim, etc. The underlying deposit and associated characteristics that the digital token represents do not change due to tokenization. Digital tokens issued by the second financial institution 108 include one or more of the following, but are not limited to: the amount issued (e.g., the fiat currency equivalent of the digital token), the currency (e.g., the fiat currency for which the digital token is issued), the date of issue (e.g., the date the digital token was created), and any other suitable metadata (e.g., an identity of the second financial institution 108, an identity of the sending computing device 110, a digital address of the sending computing device 110, etc.).

[0020] The second financial institution 108 may be an authorized entity on the multi-token network 112 and may interact with the multi-token network 112 to provide customer products such as digital wallets. The second financial institution 108 may be authorized to create and manage wallets (e.g., digital addresses) for its 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 its customers (e.g., users of the sending computing device 110). Additionally, the second financial institution 108 may issue payment instruments to the sending computing device 110, which may be physical payment cards, virtual payment cards, paper checks, virtual checks, and the like. The sending computing device 110 may accept digital wallets and / or other payment instruments, communicate payment authentication information associated with a transaction account, and fund a payment transaction using the transaction account.

[0021] 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 with 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 transacting deposit tokens issued by the second financial institution 108. Additionally, the sending computing device 110 operates on an asset network 114. For example, the user of the sending computing device 110 may have an account or access to the asset network 114 through which the user of the sending computing device 110 may sell one or more assets (e.g., an NFT on an NFT marketplace). Transactions involving the sending computing device 110 are described in more detail below and with reference to FIGS. 3A-6B. The sending computing device 110 may be a desktop computer, a notebook, a laptop computer, a tablet computer, a handheld device, a smartphone, a thin client, or any other electronic device or computing system that stores, compiles, and organizes audio, visual, or textual data and receives / transmits such data 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 described functions, such as computer system 700 shown in FIG. 7. It should be noted that while only a single sending computing device 110 is illustrated, the system 100 may include any number of sending computing devices 110.

[0022] The asset network 114 is a network or platform that allows users to exchange (e.g., buy and sell) assets (e.g., products or services) between each other using digital tokens. The asset network 114 can store, compile, and organize audio, visual, or textual data and can receive / send such data to other computing devices, such as the receiving computing device 102 and / or processing server 106, the sending computing device 110, etc. For example, the asset network 114 can be operated or supported by any type of electronic device or computing system or systems specifically configured to perform the described functions, such as the computer system 700 shown in FIG. 7. The asset network 114 can include multiple user nodes (e.g., the receiving computing device 102 and the sending computing device 110) that buy and sell 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 (B2B) payment network, a supply chain payment network, a cross-border person-to-person payment network (e.g., remittance flows), a public crypto-economy (e.g., an NFT marketplace, a decentralized finance (DeFi) network, etc.), and any other suitable network for facilitating the exchange of assets for digital tokens as would be apparent to one skilled in the art. In an NFT marketplace example, the asset network 114 facilitates the buying and selling of digital art (e.g., NFTs) between the receiving computing device 102 and the sending computing device 110. Additionally, the asset network 114 can include one or more smart contracts associated with or linked to assets being bought and sold on the asset network 114, and one or more parameters for unlocking the smart contracts to release the assets.In the example of an NFT marketplace (e.g., asset network 114), a smart contract accompanies each NFT (e.g., asset) for sale and defines one or more parameters for unlocking the smart contract. For example, the one or more parameters of the smart contract may define the currencies that are acceptable for purchasing the asset, etc.

[0023] 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 allows multiple entities (e.g., businesses, governments, financial institutions, etc.) to issue and transfer digital tokens and can also leverage regulated cryptocurrencies (e.g., stablecoins, CBDCs, etc.) as a form of token or as an asset for transactions to provide instant settlements on the multi-token network 112. The multi-token network 112 interacts with and / or integrates with existing traditional payment rails to provide additional options and benefits to consumers (e.g., conducting transactions using digital tokens or fiat currency). 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 specific 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 may allow for the receipt, storage, processing, and / or transmission of digital tokens directly between addresses (e.g., a digital address associated with the receiving computing device 102 and a digital address associated with the sending computing device 110). The multi-token network 112 is a programmable network that operates on a network operator infrastructure and is accessible to participants via one or more application programming interfaces (APIs).The API may be a private, permissioned API, where nodes of the multi-token network 112 require credentials issued by the multi-token network 112 to gain access to the multi-token network 112. For example, the multi-token network 112 includes an API that is compatible with each financial institution participating in the multi-token network 112 (e.g., the first financial institution 104 and the second financial institution 108). The multi-token network 112 may communicate and transact with multiple networks (e.g., the asset network 114 and the blockchain network 116). It should be noted that while only a single blockchain network 116 and a single asset network 114 are shown in FIG. 1, any number of blockchain networks 116 and / or asset networks 114 may be part of the multi-token network 112. Additionally, the multi-token network 112 may communicate and transact with various types of networks. For example, the blockchain network 116 and / or the asset network 114 may be a private, permissioned, or public blockchain network, and the first financial institution 104 and the second financial institution 108 may each be part of a separate payment network.

[0024] In an embodiment, the multi-token network 112 may include a blockchain network 116. The blockchain network 116 may comprise a number of blockchain nodes, including, but not limited to, a first financial institution 104, a processing server 106, and a second financial institution 108. Each blockchain node of the blockchain network 116 may be a computing system configured to perform functions related to blockchain processing and management, such as those shown in FIG. 7 and described in more detail below, which may include, for example, the following: generating blockchain data values, verifying proposed blockchain transactions, verifying digital signatures, generating new blocks, validating new blocks, and maintaining a copy of the blockchain.

[0025] The blockchain of the blockchain network 116 may be a distributed ledger comprising at least a number 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 expressed using any suitable method (e.g., UNIX timestamp, DateTime notation, etc.). The block reference value may be a value that references (e.g., based on the timestamp) a preceding block in the blockchain. 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 preceding each 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. Similarly, the data reference value may be a reference to one or more data values ​​stored in the 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.

[0026] The use of block reference values ​​and data reference values ​​in each block header can result in immutability for the blockchain. Any attempted change to the data value requires the generation of a new data reference value for the block, which in turn requires the generation of a new block reference value for the subsequent block, which in turn requires the generation of a new block reference value for each subsequent block. To make the change permanent, the above must be performed and updated for every single node in the blockchain network 116 before a new block is created and added to the blockchain. Computing and communication limitations can make such changes extremely difficult or impossible, hence the blockchain achieves immutability.

[0027] In some embodiments, a blockchain can be used to store information about a blockchain transaction (e.g., a transaction request for the purchase of an asset on the asset network 114) made between two different blockchain wallets (e.g., a buyer digital address associated with the receiving computing device 102 and a seller digital address associated with the sending computing device 110). The blockchain wallet can contain a private key of a cryptographic key pair, which can be used to generate a digital signature that can serve as a payer's authorization for the blockchain transaction, which can be verified by the blockchain network 116 using the public key of the cryptographic key pair. In some cases, the term "blockchain wallet" or "digital address" can refer specifically to a private key. In other cases, the term "blockchain wallet" or "digital address" can refer to a computing device (e.g., the receiving computing device 102 and the sending computing device 110, etc.) that stores the private key for use in a blockchain transaction. For example, each computing device may have its own private key for each cryptographic key pair, and each may be a blockchain wallet for use in transactions with a blockchain associated with blockchain network 116. The computing devices 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 mobile phone, a smartphone, a smart watch, a smart television, a wearable computing device, an embeddable computing device, etc.

[0028] Each blockchain data value stored in the blockchain may correspond to a blockchain transaction or storage of other data, as appropriate. A blockchain transaction may comprise at least the following: a digital signature of the sender of the currency or digital token (e.g., a digital address associated with the receiving computing device 102) generated using the sender's private key, a blockchain address of the recipient of the currency or digital token (e.g., a digital address associated with the sending computing device 110) generated using the recipient's public key, and the amount of blockchain currency to be transferred or other data to be stored. In some blockchain transactions, the transaction may also include: one or more sender blockchain addresses where the blockchain currency or digital token is currently stored (e.g., if a digital signature establishes access to such currency or digital token); and an address generated using the sender public key for any changes to be held by the sender. Addresses to which cryptocurrency or digital tokens that can be used in future transactions are referred to as "output" addresses because they were previously used to capture the output of a prior blockchain transaction, and as "unspent transactions" because there is currency or digital tokens sent to the address in a prior transaction where the currency or digital token has not yet been spent. In some cases, blockchain transactions may also include a sender public key for use by entities in validating the transaction. For traditional processing of blockchain transactions, such data may be provided by either the sender or the 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 can verify the digital signature using the public key in the sender's wallet's cryptographic key pair and can verify access to the sender's funds (e.g., if an unspent transaction has not yet been spent and has been sent to an address associated with the sender's wallet), a process known as "confirming" the transaction, and the blockchain transaction is then included in a new block. In a traditional blockchain implementation, the new block may be validated 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. If the blockchain data value is not related to a blockchain transaction but instead to the storage of other types of data, the blockchain data value may still include or involve digital signature validation.

[0029] In the system 100, blockchain nodes that wish to perform transactions using digital tokens can submit those digital tokens to the processing server 106 to facilitate the transaction through the blockchain network 116. If the receiving computing device 102 wishes to purchase an asset on the asset network 114 using a digital token issued by the first financial institution 104, the receiving computing device 102 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 through the first financial institution 104 (e.g., the financial institution that issued the digital token). The transaction request can include the following: 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, an identification of the asset network 114, and an identification of the asset. In some embodiments, the transaction request may include a digital signature generated using the private key of the digital address of the receiving computing device 102, which may be validated by the processing server 106 using the public key of the digital address of the receiving computing device 102, e.g., the receiving computing device 102 may validate that it is authorized to use the digital address at which the transaction was submitted. In embodiments, 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., in the absence of a blockchain network 116).

[0030] The processing server 106 may receive the transaction request and may also generate an endorsement token for the digital token (e.g., the endorsement token may be generated with a value equal to the value of the digital token). The endorsement token is created with one or more digital addresses of the processing server 106. The endorsement token may include one or more attributes, including but not limited to a unique symbol, a circulation amount, and an exchange value. 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 endorsement token represents a tokenized endorsement for the digital token issued by the first financial institution 104 (e.g., an endorsement for the funds represented by the digital token). For example, the endorsement token may be issued for a liability of the first financial institution 104 to the processing server 106, which in turn represents a liability of the processing server 106 to any subsequent bearer of the endorsement token (e.g., the second financial institution 108 and / or the sending computing device 110, etc.). The endorsement token can be denominated in the same currency as the issued digital token. The endorsement token is a fungible asset, such that any previously issued endorsement tokens of the same currency and value are indistinguishable from one another. The endorsement token is issued and transferred within the multi-token network 112 only between registered participants within 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 can identify the smart contract on the asset network 114 (e.g., the asset network 114 and the asset identified in the transaction request) and can determine one or more parameters for unlocking the smart contract.In generating the guarantee token, the processing server 106 uses one or more parameters of a smart contract associated with the asset identified in the transaction request to generate a guarantee token that will unlock the smart contract and release the asset. In an embodiment, the guarantee token does not operate to unlock a smart contract on the asset network 114, but rather the processing server 106 may generate a payment status token to unlock a smart contract on the asset network 114. In such an embodiment, the guarantee token will not be sent to the asset network 114. The payment status token may be a tokenized payment approval message for a payment for an asset on the asset network 114 and may have been generated using one or more parameters of a smart contract associated with the asset identified in the transaction request. The payment status token may include metadata for the asset transaction, including but not limited to a transaction reference, a transaction payment confirmation, an identity of the asset, an indication of a transaction non-payment, and an indication of a transaction delinquent payment. 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 matching (e.g., if the asset network 114 wishes to claim commission against the processing server 106). The payment status token is any suitable cryptographically verifiable messaging token, including but not limited to non-fungible ERC 721 tokens, ERC 20 tokens, etc. The processing server 106 can generate the payment status token on a private blockchain network (e.g., blockchain network 116), which includes a smart contract to transfer the payment status token from the private blockchain network to the asset network 114. The processing server 106 generates an asset request transaction for the asset on behalf of the receiving computing device 102.The asset request transaction includes, but is not limited to, the endorsement token, the receiving party digital address of the receiving computing device 102, the sending party digital address of the sending party computing device 110, and an identification of the asset. In some embodiments, the asset request transaction can include the digital address of the processing server 106. In some embodiments, the asset request transaction can include a digital signature generated using the private key of the digital address of the processing server 106 and / or the receiving computing device 102, which can be verified by the asset network 114 using the public key of the digital address of the processing server 106 and / or the receiving computing device 102, e.g., the processing server 106 and / or the receiving computing device 102 can verify that the processing server 106 and / or the receiving computing device 102 are authorized to use the digital address at which the transaction was submitted. The processing server 106 can send the asset request to the blockchain network 116 for recording. In embodiments in which the processing server 106 generates a payment status token, the asset request transaction includes the payment status token instead of the endorsement token, and the processing server 106 can send the endorsement token directly to the second financial institution 108.

[0031] The asset network 114 receives asset request transactions from the processing server 106 and may generate asset transactions. The asset network 114 may generate asset transactions in response to verifying digital signatures 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 receiving party digital address of the receiving computing device 102, a sending party digital address of the sending party 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 embodiments, the asset request transaction may include a digital signature generated using a private key of a node of the asset network 114 and / or a digital address of the sending computing device 110, which may be verified by the processing server 106 using a public key of the node of the asset network 114 and / or a digital address of the sending computing device 110, e.g., the node of the asset network 114 and / or the sending computing device 110 may verify that the node is authorized to use the digital address at which the transaction was submitted. The asset network 114 may transmit the endorsement token received in the asset request transaction to the second financial institution 108 to enable the second financial institution 108 to redeem the currency associated with the endorsement token. In some embodiments, the endorsement token may be transmitted to a digital address of the sending computing device 110, which may be submitted to the second financial institution 108.In embodiments in which the asset network 114 receives a payment status token instead of a guarantee token as part of the asset request transaction, the asset network 114 may transmit the payment status token to the second financial institution 108. Alternatively, the asset network 114 may transmit the payment status token back to the processing server 106, retain and store the payment status token, or retain and discard the payment status token.

[0032] The processing server 106 can receive asset transactions from the asset network 114 (e.g., via nodes of the asset network 114 and / or the sending computing device 110). The processing server 106 verifies the digital signature of the nodes of the asset network 114 and / or the sending computing device 110 and transmits the asset transaction and / or simply the asset to the digital address of the receiving computing device 102.

[0033] The processing server 106 can receive a redemption request from the second financial institution 108. The redemption request includes a guarantee token generated by the processing server 106 in response to the transaction request. The redemption request can also include the digital address of the second financial institution 108. In some embodiments, the redemption request can include a digital signature generated using a private key of the digital address of the second financial institution 108, which can be verified by the processing server 106 using a public key of the digital address of the second financial institution 108, for example, to verify that the second financial institution 108 is authorized to use the digital address at which the transaction was submitted. The processing server 106 can generate and send a payment transaction message to the first financial institution 104. The payment transaction message can include, but is not limited to, the digital token and instructions to send a fiat currency equivalent for the digital token from the first financial institution 104 to the second financial institution 108. The payment transaction message can also include the digital address of the processing server 106. In some embodiments, the settlement transaction message may include a digital signature generated using the private key of the digital address of the processing server 106, which may be verified by the first financial institution 104 using the public key of the digital address of the second processing server 106, e.g., the processing server 106 may verify that it is authorized to use the digital address at which the transaction was submitted.

[0034] The first financial institution 104 may receive the payment transaction message from the processing server 106 to unlock the equivalent fiat currency for the digital token and may transmit the equivalent fiat currency to the second financial institution 108. In some embodiments, in response to verifying the processing server 106's digital signature in the payment transaction message, the first financial institution 104 may unlock and transmit the fiat currency. The first financial institution 104 may transmit the fiat currency to the second financial institution 108 or may effect a settlement for the fiat currency owed to the second financial institution 108 using traditional payment rails and settlement methods that would be apparent to one of ordinary skill in the art.

[0035] The described method and system provide a technical solution to the problem of unregulated digital currency transactions in a digital currency network that lacks the features and regulation of traditional payment systems with trust. By using digital tokens issued by financial institutions and collateralized by fiat currency, and issuing a guarantee token for those digital tokens for use in digital transactions, transacting parties can transact using digital tokens in a trusted and regulated system where the value of the digital tokens is guaranteed. For example, the described method and system provide a solution that supports multiple tokens in a permissioned blockchain network, allowing the issuance and transfer of digitized deposit tokens from banks, non-bank issued (but regulated) stable coins and CBDCs, all with the security and speed of modern payment networks. This allows banks and other regulated institutions to enjoy the benefits of blockchain and tokenized assets while operating within a regulated and trusted ecosystem. The described methods and systems therefore provide a solution that combines elements of traditional payment and currency settlement services with digital currency use cases, resulting in a regulated and stable digital currency network.

[0036] Processing Server FIG. 2 illustrates an embodiment of a processing server 106 in the system 100. It will be apparent to one of ordinary skill in the art that the embodiment of the processing server 106 illustrated in FIG. 2 is provided for illustrative purposes only and is not an exhaustive list of all possible configurations of the processing server 106 suitable for performing the functions of the present disclosure. For example, computer system 700 illustrated in FIG. 7 and described in more detail below may be a suitable configuration of the processing server 106. In some embodiments, blockchain nodes (e.g., first financial institution 104 and second financial institution 108) in the blockchain network (e.g., blockchain network 116) illustrated in FIG. 1 may include the components illustrated in the processing server 106 of FIG. 2 and may be configured to perform the functions described therein.

[0037] The processing server 106 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some examples, 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 area network, cellular communication network, Bluetooth, the Internet, etc. In some embodiments, the receiving device 202 may include multiple devices (e.g., different receiving devices receiving data over different networks, such as a first receiving device receiving data over a local area network and a second receiving device receiving data over the Internet). The receiving device 202 may receive a transmitted electronic data signal. Then, upon receipt of the data signal by the receiving device 202, data may be superimposed on the data signal and decoded, parsed, read, or otherwise obtained. In some embodiments, the receiving device 202 may include an analysis module for analyzing the received data signal to obtain data overlaid thereon. For example, the receiving device 202 may include an analysis program configured to receive and convert the received data signal into usable input for functions performed by the processing server 106 to implement the methods and systems of the present disclosure.

[0038] The receiving device 202 can be configured to receive data signals transmitted electronically by 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, which may be superimposed or encoded with new transactions for confirmation, confirmed blockchain transactions, new blocks for confirmation, confirmed blocks to be added to the blockchain, messages regarding block confirmations, blockchain network load data, etc. The receiving device 202 can also be configured to receive data signals transmitted electronically by 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, which may be superimposed or encoded with transaction requests, new blockchain transactions, public keys, digital signatures, response messages, computational challenge responses, etc. For example, the receiving device 202 can receive transaction requests, asset transactions, and exchange requests, as described above.

[0039] The processing server 106 may also include a communication module 204. The communication module 204 may be configured to transfer data between modules, engines, databases, memory, and other components of the processing server 106 for use in performing the functions of the present disclosure. The communication module 204 may include one or more communication types and may use various communication methods for communication within a computing device. For example, the communication module 204 may include a bus, a connection pin connector, wires, 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 (e.g., an externally connected database, a display device, an input device, etc.). The processing server 106 may also include a processing device. The processing device may be configured to perform the functions of the processing server 106 of the present disclosure. This will be apparent to one of ordinary skill in the art. In some embodiments, the processing server 106 may include multiple engines and / or modules (e.g., a query module 214, a generation module 216, a validation module 218, etc.) that are specifically configured to perform one or more functions of the processing server 106. As disclosed herein, the term "module" may refer to software or hardware that is specifically programmed to receive an input, perform one or more operations using the input, and provide an output. The inputs, outputs, and operations performed by the various modules will be apparent to one of ordinary skill in the art based on this disclosure.

[0040] The processing server 106 may also include a memory 208. The memory 208 may be configured to store data (e.g., public keys, private keys, symmetric keys, etc.) for use by the processing server 106 in performing the functions of the present disclosure. The memory 208 may be configured to store data using appropriate data formatting methods and schemas and may be any appropriate type of memory (e.g., read-only memory, random access memory, etc.). The memory 208 may include, for example, cryptographic keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and application programs of the processing server 106, and other appropriate data used by the processing server 106 in performing the functions of the present disclosure. This will be apparent to those of skill in the art upon reading this disclosure. In some embodiments, the memory 208 may include a relational database using Structured Query Language (SQL) to store, identify, modify, update, access, etc., stored structured data sets. The memory 208 may be configured to store, for example, cryptographic keys, salts, nonces, address generation and verification algorithms, digital signature generation and verification algorithms, hash algorithms for generating reference values, rules for generating new blocks and block headers, pools of pending transactions, blockchain network load information, blockchain wallet data, challenge difficulty data, etc. The memory 208 may be further configured to store communication information about 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 be further 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.

[0041] The processing server 106 may include blockchain data 206, which may be stored in the memory 208 of the processing server 106 or stored in a separate area within the processing server 106 or made accessible by the processing server 106. The blockchain data 206 may include a blockchain, which may comprise a plurality of blocks, and may be associated with a blockchain network (e.g., blockchain network 116). In some cases, the blockchain data 206 may further include any other data associated with the blockchain and its management and its performance, such as block generation algorithms, digital signature generation and confirmation algorithms, aggregated mining bids, mining bid weights 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.

[0042] The processing server 106 may also include a query module 214. The query module 214 may be configured to run queries on a database to identify information. The query module 214 may receive one or more data values ​​or query strings and based thereon may run the query strings on the indicated database (e.g., the memory 208 of the processing server 106) to identify information stored therein. 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 run queries 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. For example, the query module 214 may 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.

[0043] The processing server 106 may also include a generation module 216. The generation module 216 may be configured to generate data used by the processing server 106 in performing the functions of the present disclosure. The generation module 216 may receive instructions as input values, generate data based on the instructions, and 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 blockchain operations. The generation module 216 may also be configured to generate endorsement tokens 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 endorsement tokens based on values ​​of the digital tokens. Additionally, the generation module 216 may be configured to generate payment status tokens for unlocking one or more smart contracts on the asset network 114.

[0044] The processing server 106 may also include a validation module 218. The validation module 218 may be configured to perform validations on the processing server 106 as part of the functionality of the present disclosure. The validation module may receive as input instructions, which may include data to be used in performing the validation, perform the validation upon request, and output the results of the validation to another module or engine of the processing server 106. For example, the validation module 218 may be configured to confirm a blockchain transaction by analyzing blockchain data values ​​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 submitted new transaction and that the transaction output has not already been used to transfer currency in another transaction. The validation module 218 may be configured to validate a digital signature using a public key and a suitable signature generation algorithm. The validation module 218 may further be configured to validate digital tokens, endorsement tokens, payment status tokens, and / or assets traded in the system 100.

[0045] The processing server 106 may also include a transmitting device 220. The transmitting device 220 may be configured to transmit data over one or more networks via one or more network protocols. In some examples, the transmitting device 220 may be configured to transmit 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 systems and entities via one or more communication methods, such as radio frequency, local area network, wireless area network, cellular communication, Bluetooth, radio frequency (RF), the Internet, etc. In some embodiments, the transmitting device 220 may include multiple devices (e.g., different transmitting devices for transmitting data over different networks (e.g., a first transmitting device transmitting data over a local area network and a second transmitting device transmitting data over the Internet)). The transmitting device 220 may electronically transmit a data signal having the superimposed data, the data being analyzed by the receiving device 202. In some embodiments, the transmitting device 220 may include one or more modules for superimposing, encoding, or formatting the data into a data signal suitable for transmission.

[0046] The sending device 220 can be configured to electronically transmit data signals 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, which may have the following superimposed or encoded thereon: new blockchain data values; new blocks for confirmation; confirmed blocks; messages regarding confirmation of blocks or transactions; and other data used in the operation and management of the blockchain. The sending device 220 can also be configured to electronically transmit data signals 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, which may have the following superimposed or encoded thereon, as described in more detail above: asset request transactions; asset transfer transactions; and settlement transaction messages.

[0047] Processing transaction settlements and smart contract access using the guarantee token 3A-3G illustrate a process 300 for transaction settlement and access to smart contracts using an assurance token, according to an example embodiment.

[0048] At S302, the receiving computing device 102 selects an asset to acquire on the asset network 114. For example, a user of the receiving computing device 102 may select an NFT to be sold by the sending computing device 110 in a marketplace for NFTs (e.g., the asset network 114). The receiving computing device 102 generates an asset purchase request at S304 and transmits the asset purchase request to the first financial institution 104 at S306. The asset purchase request may include, but is not limited to, the following: a sending party address of the sending computing device 110, an identification of the asset network 114, an identification of the asset, and a value of the asset.

[0049] At S308, the first financial institution 104 receives the asset purchase request from the receiving computing device 102. The first financial institution 104 can check an account associated with the receiving computing device 102 to verify that the receiving computing device 102 has a balance large enough to cover the value of the asset purchase. At S310, the first financial institution 104 generates a transaction request, which includes at least a receiving party digital address, a digital token issued by the first financial institution 104 to the receiving party digital address, a sending party address, an identification of the asset network, and an identification of the asset. The first financial institution 104 also transmits the transaction request to the processing server 106 at S312. The processing server 106 is part of a multi-token network 112, which may include a blockchain network (e.g., blockchain network 116), and in S312, the first financial institution 104 may send a transaction request to the blockchain network 116.

[0050] At S314, the processing server 106 receives the transaction request from the first financial institution 104 and at S318 generates an endorsement token for the digital token. The endorsement token includes at least a unique symbol, a circulation amount, and an exchange value. In an embodiment, the processing server 106 may generate the endorsement token on a private blockchain network in the multi-token network 112. For example, the processing server 106 may be a node in a permissioned private blockchain network to generate the endorsement token for use in the multi-token network 112. In an embodiment in which the endorsement token is generated on a private blockchain network, a smart contract may be used to transfer the endorsement token between the private blockchain network and a public blockchain network (e.g., the asset network 114). The processing server 106 can receive the transaction request directly from the first financial institution 104, or the first financial institution 104 can send the transaction request to a blockchain network (e.g., blockchain network 116), and the processing server 106 and any other nodes (e.g., the first financial institution 104 and the second financial institution 108) can receive the transaction request at S316 as nodes in the blockchain network (e.g., blockchain network 116).

[0051] At S320, the processing server 106 generates an asset request transaction that includes, but is not limited to, the security token, the receiving party digital address of the receiving computing device 102, the sending party digital address of the sending computing device 110, and an identification of the asset. The processing server 106 transmits the asset request transaction to the asset network 114 at S322.

[0052] At S324, 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 can be received by a smart contract associated with the asset network 114 and / or the asset. The asset network 114 can process the asset request and generate an asset transaction at S326. For example, the asset network 114 can verify that the endorsement token included in the asset request can unlock the smart contract associated with the asset network 114 and / or the asset. The asset transaction can include, but is not limited to: a receiving party digital address of the receiving computing device 102 and a sending party digital address of the sending computing device 110. At S327, the asset network 114 transmits the asset transaction to the processing server 106 and / or the blockchain network 116.

[0053] At S328, the processing server 106 receives the asset transaction from the asset network 114. The processing server 106 can receive the asset transaction directly from a node in the asset network 114, or the node in the asset network 114 can transmit the asset transaction to the blockchain network (e.g., the blockchain network 116), and the processing server and any other nodes (e.g., the first financial institution 104 and the second financial institution 108) can receive the transaction request at S330 as nodes in the blockchain network (e.g., the blockchain network 116).

[0054] At S332, the processing server 106 generates an asset transfer transaction. The asset transfer transaction includes, but is not limited to, the receiving party digital address of the receiving computing device 102, the sending party digital address of the sending computing device 110, and an identification of the asset. At S334, the processing server 106 transmits the asset transfer transaction to a blockchain network (e.g., blockchain network 116) and / or the digital address of the receiving computing device 102.

[0055] At S336 and S337, the blockchain network 116 and the digital address of the receiving computing device 102, respectively, can receive the asset transfer transaction. Alternatively, the processing server 106 can simply send the assets to the digital address of the receiving computing device 102 at S338. For example, the receiving computing device 102 is not part of a blockchain network (e.g., the blockchain network 116), and the digital address of the receiving computing device 102 receives the assets at S340.

[0056] Returning to S326, the process 300 may proceed to S342, where the asset network 114 sends the guarantee token for the asset transaction to the second financial institution 108. In an embodiment, the guarantee token is generated on a private blockchain network in the multi-token network 112, and the asset network 114 may first send the guarantee token to the processing server 106 to release the guarantee token from the private blockchain network. In an embodiment, where the guarantee token is generated on a private blockchain network, the processing server 106 may perform S342 after the guarantee token is released from the private blockchain network. In S344, the second financial institution 108 receives the guarantee token from the asset network 114 and generates a redemption request including the guarantee token in S346. The second financial institution 108 sends the redemption request to the processing server 106 at S348.

[0057] At S350, the processing server 106 receives a redemption request including the guarantee token from the second financial institution 108. At S352, the processing server 106 generates a payment transaction message including, but not limited to, the digital token and instructions to send an equivalent fiat currency for the digital token from the first financial institution 104 to the second financial institution 108. The processing server 106 transmits the payment transaction message to the first financial institution 104 at S354.

[0058] At S356, the first financial institution 104 receives the payment transaction message from the processing server 106. The first financial institution 104 may verify the payment transaction message (e.g., based on the digital token itself, based on a digital signature of the processing server 106, etc.). In response to the payment transaction message, at S358, the first financial institution 104 may unlock an amount of fiat currency equivalent for the digital token included in the payment transaction message, and at S360, may transmit the fiat currency to the second financial institution 108.

[0059] At S362, the second financial institution 108 receives the fiat currency from the first financial institution 104. The second financial institution 108 may generate a notification to the processing server 106 confirming receipt of the fiat currency at S364, and may send the notification at S366. The processing server 106 receives the notification from the second financial institution 108 at S368.

[0060] Exemplary Methods for Settling Transactions and Accessing Smart Contracts Using the Guarantee Token 4A-4B illustrate a method 400 for transaction settlement and access to smart contracts using assurance tokens, according to an example embodiment.

[0061] At S402, 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 (first financial institution 104). The transaction request includes at least, but is not limited to, a receiving party digital address, a digital token issued by the first financial institution (e.g., first financial institution 104) to the receiving party digital address, a sending party address, an identification of an asset network (e.g., an identification of the asset network 114), and an identification of an asset. The digital token may be, but is not limited to, a digitized deposit token, a CBDC, or any other suitable digital coin for transactions within the system 100. The receiving party digital address, the identification of the asset network, the sending party digital address, and the identification of the asset may be accompanied by a digital asset contract (e.g., a contract to purchase or procure an asset from the asset network 114). The asset network 114 may be a marketplace for non-fungible tokens (NFTs), and the assets may be NFTs.

[0062] At S404, a generating module (e.g., generating module 216) of a processing server (e.g., processing server 106) generates an endorsement token for the digital token, where the endorsement token includes a processing device digital address. The endorsement token is a tokenized endorsement for the digital token issued by a first financial institution (e.g., first financial institution 104). For example, the processing server 106 generates the endorsement token based on the value of the digital token. The endorsement token represents a legal claim against the processing server 106 regarding the value of the digital token. The processing server 106 can identify (e.g., using query module 214) an asset smart contract on the asset network 114 that is associated with the asset. The asset smart contract can include one or more asset purchase requirements for the asset. In generating the endorsement token, the processing server 106 can leverage one or more requirements of the smart contract such that the endorsement token unlocks the asset from the asset network 114.

[0063] At S406, a generating module (e.g., generating 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, the following: an endorsement token, a receiving party digital address (e.g., a digital address of the receiving computing device 102), a sending party digital address (e.g., a digital address of the sending computing device 110), and an identification of an asset. At S408, a sending device (e.g., sending device 220) of the processing server (e.g., processing server 106) sends the asset request transaction to an asset network (e.g., asset network 114). The processing server 106 can send the asset request transaction directly to the asset network 114, or the processing server 106 can send the asset request transaction to a blockchain network (e.g., blockchain network 116), and the nodes in the asset network 114 and any other nodes in the blockchain network 116 can receive the asset request transaction as nodes in the blockchain network 116.

[0064] At S410, 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 the receiving computing device 102) and a sending party digital address (e.g., a digital address of the sending computing device 110). In some embodiments, the asset transaction can be received by a smart contract on the processing server 106.

[0065] At S412, a generating module (e.g., generating 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, the receiving party digital address (e.g., the digital address of the receiving computing device 102), the sending party digital address (e.g., the digital address of the sending computing device 110), and an identification of the asset. At S414, a sending device (e.g., sending device 220) of the processing server (e.g., processing server 106) sends the asset transfer transaction to the receiving party digital address (e.g., the digital address of the receiving computing device 102). In an embodiment, the processing server 106 can send only the asset instead of the entire asset transfer transaction. In some embodiments, the asset transfer transaction can be generated via a smart contract on the processing server 106.

[0066] At S416, 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 an assurance token (e.g., the assurance token generated by processing server 106 at S404). In response to receiving the assurance token, a generation module (e.g., generation module 216) of the processing server (e.g., processing server 106) generates a payment transaction message at S418. The payment transaction message includes at least, but is not limited to, the digitized deposit token (e.g., a digital token issued by the first financial institution 104) and instructions to send an equivalent fiat currency for 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).

[0067] At S420, a sending device (e.g., sending device 220) of a processing server (e.g., processing server 106) sends the payment transaction message to the first financial institution (e.g., first financial institution 104). The payment transaction message can be sent and received by the processing server 106 using a smart contract.

[0068] Processing transaction settlements and access to smart contracts using guarantee and payment status tokens 5A-5B illustrate a process 500 for transaction settlement and access to smart contracts using an endorsement token and a payment status token, according to an example embodiment. Process 500 shares steps S302-S318 of process 300, proceeding from S318 to S502. Process 500 separates the tokenized endorsement of the digital token issued by the first financial institution and the smart contract functionality of the endorsement token. In process 500, the endorsement token serves as a tokenized endorsement for the digital token issued by the first financial institution, and the payment status token serves to unlock smart contracts on the asset network 114 associated with one or more assets. In process 500, the endorsement token is not sent to the asset network 114.

[0069] At S502, the processing server 106 generates a payment status token. The payment status token includes asset transaction metadata, including but not limited to one or more of a transaction reference, a transaction payment confirmation, an asset identity, an indication of transaction payment default, and an indication of transaction payment delinquency. 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 matching (e.g., if the asset network 114 wishes to claim commission against the processing server 106). The payment status token may be any suitable cryptographically verifiable messaging token, including but not limited to a non-fungible ERC 721 token, an ERC 20 token, etc.

[0070] At S504, processing server 106 transmits the guarantee token (e.g., the guarantee token generated at S318) to second financial institution 108. At S506, second financial institution 108 receives the guarantee token from processing server 106. From S506, process 500 proceeds to S346 to S368 of process 300.

[0071] At S508, the processing server 106 generates an asset request transaction that includes, but is not limited to, the payment status token, the receiving party digital address of the receiving computing device 102, the sending party digital address of the sending computing device 110, and an identification of the asset. The processing server 106 transmits the asset request transaction to the asset network 114 at S510.

[0072] At S512, the asset network 114 (e.g., one or more nodes of the asset network 114) receives the asset request from the processing server 106. The asset request can be received by a smart contract of the asset network 114 and / or associated with the asset. The asset network 114 can receive the asset request directly from the processing server 106, or the processing server 106 can transmit the asset request to a blockchain network (e.g., the blockchain network 116) at S511, and the nodes in the asset network 114 and any other nodes of the blockchain network 116 can receive the asset request as nodes in the blockchain network 116 at S512.

[0073] The asset network 114 may process the asset request and generate an asset transaction at S514. For example, the asset network 114 may verify that the payment status token included in the asset request can unlock a smart contract associated with the asset network 114 and / or the asset. The asset transaction may include, but is not limited to: a receiving party digital address of the receiving computing device 102 and a sending party digital address of the sending computing device 110. At S516, the asset network 114 transmits the asset transaction to the processing server 106 and / or the blockchain network 116. At S518, the blockchain network 116 receives the asset transaction from the asset network 114. From S516, the process 500 proceeds to S328-S340 of the process 300.

[0074] From S514, process 500 may proceed to S520, where the asset network 114 transmits the payment status token to the second financial institution 108 (S522) and / or to the processing server 106 (S524). The second financial institution 108 and / or the processing server 106 may receive the payment status token directly from the asset network 114, or the asset network 114 may transmit the payment status token to a blockchain network (e.g., the blockchain network 116), and the second financial institution 108 and / or the processing server 106 and any other nodes of the blockchain network 116 may receive the payment status token as nodes in the blockchain network 116. S520-S524 are optional in process 500, and the asset network 114 may retain the payment status token. In an embodiment, S520-S524 may be performed simultaneously or sequentially with respect to S504-S368.

[0075] Exemplary Methods for Settling Transactions and Accessing Smart Contracts Using Guarantee Tokens and Payment State Tokens 6A-6B illustrate a method 600 for transaction settlement and access to smart contracts using an assurance token and a payment status token, according to an example embodiment.

[0076] At S602, 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 receiving party digital address, a digital token issued by the first financial institution (e.g., first financial institution 104) to the receiving party digital address, a sending party address, an identification of an asset network (e.g., an identification of the asset network 114), and an identification of an asset. The digital token may be, but is not limited to, a digitized deposit token, a CBDC, or any other suitable digital coin for trading within the system 100. The receiving party digital address, the identification of the asset network, the sending party digital address, and the identification of the asset may include a digital asset contract (a contract to purchase or procure an asset from the asset network 114). The asset network 114 may be a marketplace for non-fungible tokens (NFTs), and the asset may be an NFT.

[0077] At S604, a generating module (e.g., generating module 216) of a processing server (e.g., processing server 106) generates an endorsement token for the digital token, where the endorsement token includes a processing device digital address. The endorsement token is a tokenized endorsement for the digital token issued by a first financial institution (e.g., first financial institution 104). For example, the processing server 106 generates the endorsement token based on the value of the digital token. The endorsement token represents a legal claim against the processing server 106 regarding the value of the digital token. The processing server 106 can identify (e.g., using query module 214) an asset smart contract on the asset network 114 associated with the asset. The asset smart contract can include one or more asset purchase requirements for the asset. In generating the endorsement token, the processing server 106 can leverage one or more requirements of the smart contract such that the endorsement token unlocks the asset from the asset network 114.

[0078] At S606, a generating module (e.g., generating module 216) of a processing server (e.g., processing server 106) generates a payment status token. The payment status token is a tokenized payment confirmation message for a payment related to an asset associated with the asset identity (e.g., the asset identity of the transaction request). The payment status token includes asset transaction metadata. The asset transaction metadata may include, but is not limited to, one or more of a transaction reference, a transaction payment confirmation, an asset identity, an indication of transaction payment default, and an indication of transaction payment delinquency. 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 matching (e.g., if the asset network 114 desires to claim commission against the processing server 106). The payment status token may be any suitable cryptographically verifiable messaging token, including, but not limited to, a non-fungible ERC 721 token, an ERC 20 token, etc. The processing server 106 can generate a payment status token on a private blockchain network (e.g., blockchain network 116), which includes a smart contract for transferring the payment status token from the private blockchain network to the asset network 114, as described below in S610.

[0079] At S608, a generation module (e.g., generation module 216) of a processing server (e.g., processing server 106) generates an asset request transaction that includes at least, but is not limited to, the following: a payment status token, a receiving party digital address (e.g., the digital address of the receiving computing device 102), a sending party digital address (e.g., the digital address of the sending computing device 110), and an identification of the asset.

[0080] At S610, 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). The processing server 106 can send the asset request transaction directly to the asset network 114, or the processing server 106 can send the asset request transaction to a blockchain network (e.g., blockchain network 116), and the nodes in the asset network 114 and any other nodes in the blockchain network 116 can receive the asset request transaction as nodes in the blockchain network 116.

[0081] At S612, a sending device (e.g., sending device 220) of a processing server (e.g., processing server 106) sends the guarantee token to a second financial institution (e.g., second financial institution 108) associated with the sending party address (e.g., the digital address of the sending computing device 110).

[0082] At S614, 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 the asset network 114 and / or the sending computing device 110). The asset transaction includes at least, but is not limited to: an asset, a receiving party digital address (e.g., a digital address of the receiving computing device 102), and a sending party digital address (e.g., a digital address of the sending computing device 110). In some embodiments, the asset transaction can be received by a smart contract on the processing server 106. In some embodiments, the asset transaction can include a payment status token. For example, once the asset network 114 uses the payment status token to verify 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 can transmit the payment status token to the second financial institution 108, or the asset network 114 can retain and store or retain and discard the payment status token.

[0083] At S616, a generating module (e.g., generating 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, the receiving party digital address (e.g., the digital address of the receiving computing device 102), the sending party digital address (e.g., the digital address of the sending computing device 110), and an identification of the asset. At S618, a sending device (e.g., sending device 220) of the processing server (e.g., processing server 106) sends the asset transfer transaction to the receiving party digital address (e.g., the digital address of the receiving computing device 102). In an embodiment, the processing server 106 can send only the asset instead of the entire asset transfer transaction. In some embodiments, the asset transfer transaction can be generated via a smart contract on the processing server 106.

[0084] From S618, the process 600 may proceed to S416-S420 of the process 400.

[0085] Computer System Architecture 7 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 the blockchain nodes in the blockchain network 116 of FIG. 1 and the processing server 106 of FIG. 2 may be implemented in the computer system 700 using hardware, a non-transitory computer readable medium having stored instructions, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The hardware may embody modules and components used to implement the methods of FIGS. 3A-6B.

[0086] Where programmable logic is used, such logic may be executed on commercially available processing platforms configured with executable software code, resulting in special purpose or dedicated devices (e.g., programmable logic arrays, application specific integrated circuits (ASICs), etc.). Those skilled in the art will appreciate that embodiments of the disclosed subject matter may be implemented in a variety of computer system configurations, including multi-core, multi-processor systems, minicomputers, mainframe computers, distributed functionality linked or clustered computers, and general purpose or miniature computers that may be implemented in virtually any device. For example, at least one processor unit and memory may be used to implement the embodiments described above.

[0087] A processor unit or device of the present disclosure 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” of the present disclosure are generally used to refer to tangible media (e.g., removable storage unit 718, removable storage unit 722, and a hard disk installed in hard disk drive 712, etc.).

[0088] Various embodiments of the present disclosure are described with respect to this exemplary computer system 700. After reading this disclosure, it will be apparent to one of ordinary skill in the art how to implement the present disclosure using other computer systems and / or computer architectures. Although operations are disclosed as sequential processes, some operations may in fact be performed in parallel, concurrently and / or in distributed environments, where the program code is stored locally or remotely for access by a single processor or multi-processor machine. Furthermore, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

[0089] The processor unit 704 may be a special purpose or general purpose processor unit that is specially configured to perform the functions of the present disclosure. The processor unit 704 may be connected to a communication infrastructure 706 (e.g., a bus, a message queue, a network, a multi-core message passing scheme, etc.). The network may be any network suitable for performing the functions of the present disclosure, and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., Wifi), a mobile communication network, a satellite network, the Internet, optical fiber, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. The computer system 700 may also include a main memory 708 (e.g., random access memory, read only memory, etc.) and may also include a secondary memory 710. The secondary memory 710 may include a hard disk drive 712 and a removable storage drive 714 (e.g., a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, etc.).

[0090] The removable storage drive 714 may read from and / or write to the removable storage unit 718 in a well-known manner. The removable storage unit 718 may include a removable storage medium that can be read from and written to by the removable storage drive 714. For example, if the removable storage drive 714 is a floppy disk drive or a USB 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.

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

[0092] Data stored in computer system 700 (e.g., in main memory 708 and / or secondary memory 710) may be stored on any type of suitable computer-readable medium, such as optical storage (compact discs, digital versatile discs, Blu-ray discs, etc.) or magnetic tape storage (e.g., hard disk drives). The data may be organized in any type of suitable database structure (e.g., a relational database, a Structured Query Language (SQL) database, a distributed database, an object database, etc.). Suitable structures and storage types will be apparent to those skilled in the art.

[0093] Computer system 700 may also include a communications interface 724. Communications interface 724 may allow software and data to be sent and received between computer system 700 and external devices. Exemplary communications interface 724 may include a modem, a network interface (e.g., an Ethernet card), a communications port, a PCMCIA slot and card, and the like. The software and data transferred via communications interface 724 may be in the form of signals. The signals may be in the form of electronic, electromagnetic, optical, or other signals as will be apparent to those skilled in the art. The signals travel over communications path 726, which is configured to transmit the signals and may be implemented using wire, cable, fiber optics, a telephone line, a cellular phone link, a radio frequency link, and the like.

[0094] Computer system 700 may further include a display interface 702. Display interface 702 may be configured to allow data to be transferred between 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. Display 730 may be any suitable type of display to display data transferred via display interface 702 of 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.

[0095] The computer program medium and computer usable medium may refer to memory (e.g., main memory 708 and secondary memory 710), which may be semiconductor memory (DRAM, etc.). These computer program products may be means for providing software to the computer system 700. Computer programs (e.g., computer control logic) may be stored in the main memory 708 and / or secondary memory 710. Computer programs may also be received via the communication interface 724. Such computer programs, when executed, may enable the computer system 700 to perform the methods of the present disclosure. In particular, the computer programs, when executed, may enable the processor unit 704 to perform the methods illustrated in Figures 3A-6B as described herein. Thus, such computer programs represent the controller of the computer system 700. The present disclosure is implemented using software. The software may be stored in the computer program product and loaded into the computer system 700 using the removable storage drive 714, the interface 720, and the hard disk drive 712 or the communication interface 724.

[0096] The processor unit 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 embodiments, software (e.g., which corresponds to program code or programs stored in the main memory 708 or the auxiliary memory 710). In such embodiments, the program code may be compiled by the processor unit 704 (e.g., by a compilation module or engine) before execution by the hardware of the computer system 700. For example, the program code may be source code (e.g., assembly language or machine code) written in a programming language that is translated into a lower-level language for execution by the processor unit 704 and / or any additional hardware components of the computer system 700. The compilation process may include the use of lexical analysis, preprocessing, syntax analysis, semantic analysis, syntax-driven translation, code generation, code optimization, and any other techniques that may be suitable for translating the program code into a lower-level language suitable for controlling the computer system 700 to perform the functions of the present disclosure. Those skilled in the art will appreciate that such processing results in computer system 700 becoming a specially configured computer system 700 that is uniquely programmed to perform the functions described above.

[0097] 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 upon scanning with a dental imaging device. While various exemplary embodiments of the system and method of the present disclosure are described above, it should be understood that they are presented for illustrative purposes only and not for limitation. It is not exhaustive and does not limit the present disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings. Modifications and variations may be obtained from the implementation of the present disclosure without departing from the scope or scope. Although operations are disclosed as sequential processes, some operations may in fact be performed in parallel, simultaneously and / or in a distributed environment, where the program code is stored locally or remotely for access by a single processor or multi-processor machine. Furthermore, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter. Those skilled in the art will appreciate that the present disclosure may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The presently disclosed embodiments are therefore considered in all respects as illustrative and not restrictive, the scope of the disclosure being indicated by the appended claims rather than the foregoing description, and all changes that come within the meaning, scope and equivalency thereof are intended to be embraced therein.

Claims

1. 1. A method of transaction settlement using an assurance token, the method comprising: receiving, by a receiving device of a processing server, a transaction request from a first financial institution, the transaction request including at least a receiving party digital address, a digital token issued by the first financial institution to the receiving party digital address, a sending party address, an identification of an asset network, and an identification of an asset; generating, by a generation module of the processing server, an endorsement token for the digital token, the endorsement token being a tokenized endorsement of the digital token issued by the first financial institution; generating, by the generation module of the processing server, an asset request transaction, the asset request transaction including at least the assurance token, the receiving party digital address, the sending party digital address, and an identification of the asset; transmitting, by a transmitting device of the processing server, the asset request transaction to the asset network; receiving, by the receiving device of the processing server, an asset transaction from the asset network, the asset transaction including at least the asset, the receiving party digital address, and the sending party digital address; generating, by the generation module of the processing server, an asset transfer transaction, the asset transfer transaction including at least the receiving party digital address, the sending party digital address, and an identification of the asset; transmitting, by the sending device of the processing server, the asset transaction to the receiving party digital address.

2. 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 the transaction request, the asset request transaction, the asset transaction, and the asset transfer transaction are recorded on a blockchain of the blockchain network.

3. The method of claim 1 further comprising: receiving, by the receiving device of the processing server, a redemption request from a second financial institution, the redemption request including the guarantee token; generating, by the generation module of the processing server, a payment transaction message including at least the digital token and instructions to transmit a fiat currency equivalent of the digital token from the first financial institution to the second financial institution; transmitting, by the transmitting device of the processing server, the payment transaction message to the first financial institution.

4. 4. The method of claim 3, wherein the digital token is a digitized deposit token.

5. 2. The method of claim 1, wherein the processing server generates the endorsement token on a private blockchain network, the private blockchain network including a smart contract for transferring the endorsement token from the private blockchain network to the asset network.

6. 10. The method of claim 1, wherein the receiving party digital address, the identification of the asset network, the sending party digital address, and the identification of the asset comprise a digital asset contract.

7. 2. 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. 10. The method of claim 1, wherein the asset network is a marketplace for non-fungible tokens (NFTs) and the assets are NFTs.

9. 10. The method of claim 1, wherein the steps of receiving the asset from the asset network and sending the asset to the receiving party digital address are performed by the processing server using a smart contract.

10. The method of 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; The endorsement token is generated to unlock the asset smart contract.

11. A system for transaction settlement using a guarantee token, comprising: a receiving device of the processing server for receiving a transaction request from a first financial institution, the transaction request including at least a receiving party digital address, a digital token issued by the first financial institution to the receiving party digital address, a sending party digital address, an identification of an asset network, and an identification of an asset; a generation module of the processing server that generates an endorsement token for the digital token, the endorsement token being a tokenized endorsement 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 including at least the assurance token, the receiving party digital address, the sending party digital address, and an identification of the asset; a transmitting device of the processing server for transmitting 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 including at least the asset, the receiving party digital address, and the sending party digital address; the generating module of the processing server generates an asset transfer transaction, the asset transfer transaction including at least the receiving party digital address, the sending party digital address, and an identification of the asset; The sending device of the processing server sends the asset transaction to the receiving party digital address.

12. 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 the transaction request, the asset request transaction, the asset transaction, and the asset transfer transaction are recorded on a blockchain of the blockchain network.

13. 12. 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 guarantee token; the generation module of the processing server generates a payment transaction message, the payment transaction message including at least the digital token and instructions to transmit a fiat currency equivalent of the digital token from the first financial institution to the second financial institution; The sending device of the processing server sends the payment transaction message to the first financial institution.

14. 14. The system of claim 13, wherein the digital token is a digitized deposit token.

15. 12. The system of claim 11, wherein the processing server generates the endorsement token on a private blockchain network, the private blockchain network including a smart contract for transferring the endorsement token from the private blockchain network to the asset network.

16. 12. The system of claim 11, wherein the receiving party digital address, the identification of the asset network, the sending party digital address, and the identification of the asset comprise a digital asset contract.

17. 12. The system of claim 11, wherein sending the asset request transaction to the asset network includes sending the asset request transaction to a smart contract on the asset network.

18. 12. The system of claim 11, wherein the asset network is a marketplace for non-fungible tokens (NFTs) and the assets are NFTs.

19. 12. The system of claim 11, wherein receiving the asset from the asset network and sending the asset to the receiving party digital address are performed by the processing server using a smart contract.

20. 12. 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; The endorsement token is generated to unlock the asset smart contract.

21. 1. A method of transaction settlement using an assurance token and a payment status token, the method comprising: receiving, by a receiving device of a processing server, a transaction request from a first financial institution, the transaction request including at least a receiving party digital address, a digital token issued by the first financial institution to the receiving party digital address, a sending party address, an identification of an asset network, and an identification of an asset; generating, by a generation module of the processing server, an endorsement token for the digital token, the endorsement token being a tokenized endorsement of the digital token issued by the first financial institution; generating, by the generation module of the processing server, a payment status token, the payment status token being a tokenized payment acknowledgement message for a payment for an asset associated with the identity of the asset; generating, by the generation module of the processing server, an asset request transaction, the asset request transaction including at least the payment status token, the receiving party digital address, the sending party digital address, and an identification of the asset; transmitting, by a transmitting device of the processing server, the asset request transaction to the asset network; transmitting, by the sending device of the processing server, the assurance token to a second financial institution associated with the sending party address; receiving, by the receiving device of the processing server, an asset transaction from the asset network, the asset transaction including at least the asset, the receiving party digital address, and the sending party digital address; generating, by the generation module of the processing server, an asset transfer transaction, the asset transfer transaction including at least the receiving party digital address, the sending party digital address, and an identification of the asset; transmitting, by the sending device of the processing server, the asset transaction to the receiving party digital address.

22. 22. The method of claim 21, wherein the asset transaction further includes the payment status token.

23. 22. The method of claim 21, wherein the processing server, the first financial institution, and the second financial institution are part of a blockchain network, and the transaction request, the asset request transaction, the asset transaction, and the asset transfer transaction are recorded on a blockchain of the blockchain network.

24. 22. The method of claim 21, wherein the processing server generates the payment state token on a private blockchain network, the private blockchain network including a smart contract for transferring the payment state token from the private blockchain network to the asset network.

25. 22. The method of claim 21, wherein sending the asset request transaction to the asset network includes sending the asset request transaction to a smart contract on the asset network, and the payment state token unlocks the smart contract on the asset network.

26. 22. The method of claim 21, wherein the payment status token includes asset transaction metadata, the asset transaction metadata including one or more of: a transaction reference, a transaction payment confirmation, an identification of the asset, an indication of transaction payment default, and an indication of transaction payment delinquency.

27. 22. The method of claim 21 , wherein the payment state token is a non-fungible ERC-721 token.

28. 1. A system for transaction settlement using an assurance token and a payment status token, comprising: a receiving device of the processing server for receiving a transaction request from a first financial institution, the transaction request including at least a receiving party digital address, a digital token issued by the first financial institution to the receiving party digital address, a sending party digital address, an identification of an asset network, and an identification of an asset; a generation module of the processing server that generates an endorsement token for the digital token, the endorsement token being a tokenized endorsement 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 acknowledgement message for a payment for an asset associated with the identity of the asset; a generating module of the processing server for generating an asset request transaction, the asset request transaction including at least the payment status token, the receiving party digital address, the sending party digital address, and an identification of the asset; a transmitting device of the processing server for transmitting the asset request transaction to the asset network; the sending unit of the processing server sends the assurance token to a second financial institution associated with the sending party address; the receiving device of the processing server receives an asset transaction from the asset network, the asset transaction including at least the asset, the receiving party digital address, and the sending party digital address; the generating module of the processing server generates an asset transfer transaction, the asset transfer transaction including at least the receiving party digital address, the sending party digital address, and an identification of the asset; The sending device of the processing server sends the asset transaction to the receiving party digital address.

29. 30. The system of claim 28, wherein the asset transaction further includes the payment status token.

30. 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 the transaction request, the asset request transaction, the asset transaction, and the asset transfer transaction are recorded on a blockchain of the blockchain network.

31. 30. The system of claim 28, wherein the processing server generates the payment status token on a private blockchain network, the private blockchain network including a smart contract for transferring the payment status token from the private blockchain network to the asset network.

32. 30. The system of claim 28, wherein sending the asset request transaction to the asset network includes 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. 30. The system of claim 28, wherein the payment status token includes asset transaction metadata, the asset transaction metadata including one or more of: a transaction reference, a transaction payment confirmation, an identification of the asset, an indication of transaction payment default, and an indication of transaction payment delinquency.

34. 30. The system of claim 28, wherein the payment state token is a non-fungible ERC-721 token.

Images