Method and system for creating a trusted digital asset transfer using a digital signature

Abstract

The present invention provides methods and systems for transferring digital assets in a digital asset network. Network users can be centrally registered and screened for compliance. Standardized transfer processes and unique identifiers can provide a transparent and direct transfer process. Digital assets can include sufficient information to ensure that value will be provided, including one or more digital signatures, such that the value is immediately available to the recipient.

Description

[0001] This divisional application of the invention application is a divisional application of the invention patent application with international application number PCT / US2017 / 015498, international filing date of January 27, 2017, entering the Chinese national phase with application number 201780010861.X and title "Method and System for Creating Trusted Digital Asset Transfers Using Digital Signatures".

[0002] Cross - Reference to Related Applications

[0003] This application is an international patent application of U.S. Patent Application No. 15 / 283,930 filed on October 3, 2016 and claims the benefit of its filing date. This U.S. patent application claims priority to U.S. Provisional Application No. 62 / 294,825 filed on February 12, 2016, the entire content of which is incorporated herein by reference for all purposes. BACKGROUND OF THE INVENTION

[0004] People (and organizations) often transfer value to others. Typically, such value transfer is accomplished by providing value from the account of a sender at a first financial institution to the account of a recipient at a second financial institution. For example, the account of the sender may be decreased by that value, and the account of the recipient may be increased by that value.

[0005] The decrease in the value of the sender's account results in a gain for the first financial institution (e.g., because the liability is decreased), while the increase in the recipient's account results in a loss (e.g., because the liability is increased). To correct for these gains and losses of the financial institutions, the financial institutions may engage in equal and opposite transactions. For example, the first financial institution and the second financial institution may have corresponding banking relationships, where the first financial institution has an account at the second financial institution, and / or the second financial institution has an account at the first financial institution. The equal and opposite transactions may include debiting from the account of the first financial institution at the second financial institution the same value as is credited to the recipient's account (thus eliminating any net balance change at the second financial institution).

[0006] This type of correspondent banking relationship is commonly used for international money transfers. However, most financial institutions only have a few corresponding banking relationships. Thus, for international wire transfers, it is possible that the sending financial institution does not have a direct corresponding banking relationship with the receiving financial institution. Therefore, the first financial institution may have to transfer the value indirectly to the second financial institution. For example, the first financial institution may transfer the value to a third (intermediate) financial institution with which it has a correspondent banking relationship, and the third financial institution can then transfer the value to the second financial institution. This type of indirect path is common in international transfers. For example, an international transfer may involve one or more domestic transfers in the sender's country, the international transfer, and one or more domestic transfers in the recipient's country before finally reaching the recipient's account.

[0007] As an example, a typical international wire transfer can be carried out as follows. In step 1, Alice receives an invoice from Bob. The invoice includes the requested payment amount and information identifying Bob's UK bank account. In step 2, Alice (located in the US) instructs her US bank to send a wire transfer of funds to Bob's UK bank account. Alice's bank and Bob's bank do not have a direct correspondence, so an intermediary bank is required. In step 3, Alice's bank sends a payment initiation message to a US correspondent bank associated with Alice's bank. For example, Alice's bank sends an MT 103 message via the Society for Worldwide Interbank Financial Telecommunication (SWIFT). The SWIFT message (e.g., the MT 103 message) instructs the US correspondent bank to pay a certain number of pounds to Bob's bank. In step 4, the US correspondent bank charges Alice's bank an amount of US dollars equal to the pounds. For example, Alice's bank may have a corresponding account with the correspondent bank and can charge this account for the equivalent value in US dollars. This charging event can be considered a settlement between the correspondent bank and Alice's bank. In step 5, the US correspondent bank sends a payment instruction via SWIFT (e.g., an MT 103 message) to pay to the next correspondent bank, which is located in England. This payment instruction also requests a payment to Bob's bank to be credited to Bob's account. In step 6, the UK correspondent bank charges the US correspondent bank. For example, the US correspondent bank may have a corresponding account (e.g., a "nostro" account) with the UK correspondent bank and can be charged in pounds for this account. This charging event can be considered a settlement between the US correspondent bank and the UK correspondent bank. In step 7, the UK correspondent bank sends a payment instruction via SWIFT (e.g., an MT 103 message) to pay to Bob's bank through the local UK wire transfer system. In step 8, Bob's bank charges the UK correspondent bank. For example, the UK correspondent bank may have a corresponding account with Bob's bank and can be charged in pounds for this account. This charging event can be considered a settlement between the UK correspondent bank and Bob's bank. In step 9, Bob's bank credits the funds transfer amount (which may be reduced) to Bob's account. At this point, Bob can obtain the funds sent by Alice.

[0008] Although this example shows a funds transfer to Bob, the transfer may have taken a long time (e.g., 3 - 7 days). Due to the uncertainty of the system, each correspondent bank does not send the next payment instruction to the next bank until it receives the funds during the settlement process. Also, each settlement step can be postponed until the end - of - day net settlement process. Thus, each correspondent bank may add an extra day for the funds transfer. Due to different time zones, the time delay can be exacerbated by the asynchronous banking hours. Also, during the transfer process, the funds may have been significantly reduced (unpredictable amount) because each correspondent bank may charge a fee for each SWIFT message and for foreign currency exchange. Also, in reality, there may be more intermediate correspondent banks than described in this example.

[0009] Each correspondent bank may have different transfer protocols, which may not be visible to other banks. Additionally, multi - regional wire transfer networks may be used, and each network may have different rules and protocols. Thus, Alice's bank may not know how long the transfer will take, the rules governing each transfer step (e.g., what information the bank may be forwarding), the status of the pending transfer (e.g., no confirmation message may be provided), whether the correspondent banks are correctly recording the details of the transaction, and whether the transfer will ultimately successfully reach Bob's account. Also, Alice and her bank may want to include this information in the transaction but may not be able to reliably transmit this data to the recipient. Thus, after Alice's bank sends the first funds transfer to the first correspondent bank and it is no longer under the control of Alice's bank, there is only the hope that the funds transfer will be properly completed. If a problem occurs (e.g., the payment is not received or is delayed), then Alice and her bank cannot quickly or reliably trace the transaction.

[0010] Thus, international wire transfers are completed through a decentralized and inconsistent network of correspondent bank relationships. Each additional link in the correspondent bank chain adds time, uncertainty, insecurity, cost, and inefficiency. Also, it is difficult to change the system because the entire system can only be changed by renegotiating each specific correspondent bank protocol.

[0011] Embodiments of the present invention, either alone or in combination, solve these and other problems. Summary of the Invention

[0012] One embodiment of the present invention relates to a method. The method includes a first computer (e.g., a management node computer) receiving from a second computer a request to confirm a digital asset including a first digital signature. The first digital signature is generated using a first private key associated with the second computer, and the digital asset indicates a transfer of value from a sender to a receiver. The method further includes confirming the digital asset and generating a second digital signature for the digital asset. The second digital signature is generated using a second private key associated with the first computer. The method also includes providing the second digital signature to the second computer (e.g., an issuer node computer). The second computer then sends the digital asset to a receiver node computer. The method also includes recording the digital asset in a database; and coordinating a transaction associated with the digital asset.

[0013] Another embodiment of the present invention relates to a first computer (e.g., a management node computer) configured to perform the above method.

[0014] Another embodiment of the present invention relates to a method, including: a second computer (e.g., an issuer node computer) receiving a request to transfer value from a sender associated with a sender identifier to a receiver associated with a receiver identifier. The method further includes generating a digital asset that indicates the value is being transferred to the receiver; and generating a first digital signature for the digital asset. The first digital signature is generated using a first private key associated with the second computer. The method also includes sending a request to confirm the digital asset to a first computer (e.g., a management node computer). The request includes the digital asset and the first digital signature. The first computer then confirms the digital asset and generates a second digital signature for the digital asset. The second digital signature is generated using a second private key associated with the first computer. The method also includes receiving the second digital signature from the first computer; and providing the digital asset to a receiver node computer associated with the receiver. The first computer then records the digital asset in a database and coordinates a transaction associated with the digital asset.

[0015] Another embodiment of the present invention relates to a second computer (e.g., an issuer node computer) configured to perform the above method.

[0016] Other details regarding embodiments of the present invention can be found in the detailed description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 A block diagram of a system according to an embodiment of the present invention is shown.

[0018] Figure 2A block diagram of a management node computer according to an embodiment of the present invention is shown.

[0019] Figure 3 A block diagram of an issuer node computer according to an embodiment of the present invention is shown.

[0020] Figure 4 An example of an asset transfer network according to an embodiment of the present invention is shown.

[0021] Figure 5 A flowchart of a method for providing digital assets in an asset conversion network according to an embodiment of the present invention is shown. Detailed Description

[0022] Embodiments of the present invention relate to systems and methods for digital asset transfer. An asset transfer network may allow digital assets to be sent quickly and directly to a recipient through a transparent process, regardless of the location and identity of the sender and recipient.

[0023] In some embodiments, the asset transfer network may be a general network to which participating entities can directly register. The general network may allow a sending financial institution to communicate with any receiving financial institution associated with the network and directly provide value (e.g., digital assets) to any receiving financial institution. Digital assets may be a promise of value that can be settled at a later time. The general network may also allow each registered entity to be uniquely identified (e.g., by assigning a unique identifier to each entity during the registration process).

[0024] In some embodiments, the asset transfer network may be a permissioned network that only allows confirmed entities to participate in the network. For example, a central network administrator may confirm financial institutions and other entities during the registration process. During the confirmation process, the administrator may ensure that the registered entities are legitimate organizations that have been screened to comply with network rules. The administrator may also implement standardized messaging procedures and communicate these procedures to the registered entities.

[0025] In some embodiments, digital assets associated with a value transfer may be digitally signed by the sending entity and / or the management entity. The sender's signature may indicate that the digital asset has been legally sent by the indicated sender, and the administrator's signature may indicate that the digital asset has been approved and / or recorded by the administrator. In some embodiments, the digital signature may indicate that the digital asset has been transferred and that the value cannot be reclaimed.

[0026] Implementations allow asset transfers to be recorded in a ledger of transactions. The ledger can be a distributed ledger. For example, a transferred digital asset can be announced to one or more nodes in a network, and each of the one or more nodes maintains adding information about the new digital asset to its own ledger. Subsequently, different nodes can compare their ledgers to determine which digital assets are genuine and thus reach an agreement on a common updated ledger (e.g., a new block in a blockchain).

[0027] Some implementations include a central clearing entity. The central clearing entity can allow value to be efficiently cleared from a sending account at a sending financial institution to a receiving account at a receiving financial institution. The central clearing entity can include a central financial institution having multiple locations and multiple accounts. The central clearing entity can have at least one location and one account in each country in which it operates. As a result, a first financial institution can have an account (e.g., a clearing account) with the central clearing entity in a first country, and a second financial entity can have an account with the central clearing entity in a second country. Thus, in some implementations, international transfers are made by transferring from the first financial institution to the central clearing entity and then from the central clearing entity to the second financial institution. This means that in some implementations, each financial institution participating in the asset transfer network can have only one external account with the central clearing entity (e.g., instead of multiple corresponding bank relationships).

[0028] As can be seen, implementations provide an asset transfer network with improved speed, security, reliability, transparency, and efficiency. For example, general and permissioned networks can be well organized and enable efficient messaging and transfers directly between senders and receivers regardless of location. Such organization can reduce additional communication and remove the secrecy of various unknown correspondent bank relationships that exist in decentralized traditional systems.

[0029] Central registration of participating entities, fitness screening, standardized communication, and a universal identifier that uniquely identifies entities can each promote a sense of trust in the network and participating entities. The distributed ledger can instill confidence that each participating entity has the same information about the protocols and transfers that have taken place. Similarly, digitally signed digital assets can be highly trusted because the signature can be verified to confirm that the digital asset is being legally transferred.

[0030] Advanced network trust and digitally signed digital assets can allow the receiving financial institution to make the value of the received digital asset immediately available in the receiver's account even if the value has not yet been cleared. This means that the transferred value can be made almost immediately available.

[0031] In an embodiment of the present invention, to initiate an asset transfer, a user (or an institution on behalf of the user) may command an issuer node in the asset transfer network to generate and provide a digital asset. The issuer node may generate the digital asset and digitally sign the digital asset. The issuer node may also obtain approval and a second digital signature from a management node (such as a central administrator of the network). Subsequently, the issuer node may provide the digital asset to a recipient node (e.g., directly or through network-wide distribution). The recipient node may then provide the digital asset to the recipient (or an institution on behalf of the recipient).

[0032] In an alternative embodiment, the digital asset may be generated and / or signed by an interaction platform (instead of the sender node). The interaction platform may then provide the prepared digital asset to the issuer node or the management node for distribution in the asset transfer network.

[0033] In either case, the digital asset may be provided using a single push-type message. This single message may have sufficient information and be trusted enough to replace one or more traditional transfer messages (such as authorization request messages, authorization response messages, settlement messages, and / or multiple intermediate correspondent bank transfer messages), thereby improving messaging efficiency.

[0034] The embodiments allow for the transfer of any suitable type of value in the digital asset. For example, the digital asset may represent a commitment of monetary value, so it can be used for payments. Additionally, the digital asset can be used to provide access rights, such as access codes to restricted areas, tickets to events, login credentials for accessing secure information, etc. The digital asset can also be used to transfer ownership, such as property deeds, vehicle pink slips, patents, and to provide credit, such as game credits, energy credits, mobile phone minutes, and / or for any other suitable purpose.

[0035] Accordingly, embodiments of the present invention provide an asset transfer platform that can directly and predictably exchange value (such as value represented by account data, cryptographically signed digital assets, and supporting instructions). The platform also provides adaptive screening of participants (such as banks and their customers). In some embodiments, screening information about the user is obtained from a bank or other service provider. Additionally, the embodiments use smart contracts that can automatically enforce settlement of the digital asset according to certain criteria (such as enforcing settlement 24 hours after the digital asset has been distributed in the network).

[0036] Before discussing specific embodiments of the present invention, some terms may be described in detail.

[0037] "Digital assets" can refer to digital content associated with value. In some cases, digital assets can also indicate the transfer of value. For example, digital assets can include data indicating the transfer of a monetary value (e.g., fiat currency). In other embodiments, digital assets can correspond to other non-monetary values, such as access permission data (e.g., the number of authorized uses or time allocation for accessing information) and ownership data (e.g., digital rights data).

[0038] In some embodiments, a digital asset can be considered a trustworthy guarantee of value to be provided (e.g., a reliable IOU). For example, providing a digital asset to a recipient can be considered a reliable enough commitment to replace authorization request / response messages and / or settlement messages during a transaction.

[0039] Digital assets can also include information about one or more digital asset attributes. For example, digital assets can include useful information for transferring value from one entity or account to another entity or account. Digital assets can also include remittance information (e.g., information identifying the sending entity). In some embodiments, a digital asset can include one or more of the following: a digital asset identifier, a value (e.g., an amount, an original currency type, a destination currency type), transfer fee information, a currency exchange rate, an invoice number, a purchase order number, a timestamp, a sending entity identifier (e.g., a sender enterprise ID), a sending entity account number, a sending entity name, a sending entity contact information (e.g., an address, a phone number, an email address, etc.), a sending institution information (e.g., a financial institution name, an enterprise ID, and a BIN), a receiving entity identifier (e.g., a recipient enterprise ID), a receiving entity account number, a receiving entity name, a receiving entity contact information (e.g., an address, a phone number, an email address, etc.), and / or a receiving institution information (e.g., a financial institution name, an enterprise ID, and a BIN). When a digital asset is received, the recipient can have enough information to proceed with a settlement transaction for the indicated value.

[0040] In some embodiments, digital assets can also include digital signatures and / or encryption keys for authentication and entity identification. For example, digital assets can include a digital signature and a public key of an issuer node, as well as a public key of a management node.

[0041] An "asset transfer network" can be a network for providing and / or receiving digital assets. The asset transfer network can provide an infrastructure for providing digital assets in a "push" message. The asset transfer network can include one or more types of nodes. In some embodiments, digital assets transmitted in the asset transfer network can be recorded in a ledger of transactions. An example of an asset transfer network is a blockchain network, where the ledger of transactions can take the form of a blockchain.

[0042] The term "node" can refer to a connection point. In some embodiments, a node can be a physical electronic device that is capable of creating, receiving, or transmitting data. In other embodiments, a node can be a software module on a computing device, a software module connection point in a communication network. In some embodiments, a node can be a computing device within an asset transfer network. A node is capable of minting assets, transferring assets, receiving assets, verifying assets, maintaining a ledger of transactions, and / or performing any other suitable function. Different types of nodes can perform different sets of functions within the asset transfer network. In some embodiments, a node can be associated with and / or operated by a financial institution computer (such as a bank), a payment processor computer, a third-party computer, or any other suitable entity.

[0043] The term "ledger of transactions" can refer to a compilation of data from previous transactions. The ledger of transactions can be a database or other comparable file structure that can be configured to store data from all previous digital asset transfers, including the date and time of the transfer, the transfer amount, and the identification information of the participants in the transfer (e.g., the sender and recipient of the transfer amount). In some embodiments, the ledger of transactions can be in the form of an electronic ledger (such as a blockchain), where the data that has been stored in the electronic ledger is immutable. In some embodiments, each node in the asset transfer network can store its own copy of the ledger of transactions. In other embodiments, only some nodes store their own copies of the ledger of transactions. In additional embodiments, some nodes can have a restricted view of the ledger of transactions. For example, some nodes may only be able to view and / or verify transactions of which they are a party.

[0044] The ledger of transactions can include transaction records that are digitally signed (e.g., with a private key) in order to protect the transaction entries in the ledger from being tampered with by false transaction data. This can prevent double-spending, making all transactions immutable and irreversible, and thus making the ledger trustworthy.

[0045] In some embodiments, the ledger of transactions can be publicly viewable. For example, one or more entities can access the ledger and be able to review the ledger to determine whether a particular transaction actually occurred or whether a particular value is genuine. In some embodiments, the ledger can be only partially viewable by one or more entities.

[0046] As used herein, "blockchain" can include a series of blocks. Each block in the blockchain can include a record of one or more historical transactions as well as metadata. In some embodiments, the blocks in the blockchain can be linked by including a reference to a previous block (e.g., the hash output of a previous block). Each new block in the blockchain can be determined algorithmically based on new transactions in the blockchain and previous blocks. As a result, tampering with the data stored in these previous blocks can be detected.

[0047] "Enterprise ID" may include an identifier for an individual, enterprise, institution, or any other suitable entity. In some embodiments, the enterprise ID may be a globally unique identifier. For example, the enterprise ID may be issued by a central trusted entity. The enterprise ID may include alphanumeric characters, special characters, and any other suitable symbols. In some embodiments, the enterprise ID may be a one-time use identifier that is refreshed after each transaction. In some embodiments, the enterprise ID may be used as an address for receiving digital asset transfers (e.g., the enterprise ID may be associated with an account).

[0048] "Key pair" may include a pair of linked cryptographic keys. For example, the key pair may include a public key and a corresponding private key. In a key pair, a first key (e.g., the public key) may be used to encrypt a message, and a second key (e.g., the private key) may be used to decrypt the encrypted message. Additionally, the public key can authenticate a digital signature created with the corresponding private key. The public key may be distributed across a network to allow authentication of messages signed with the corresponding private key. The public key and the private key may be in any suitable format, including formats based on RSA or elliptic curve cryptography (ECC). In some embodiments, an asymmetric key pair algorithm may be used to generate the key pair. However, as would be understood by one of ordinary skill in the art, other means may also be used to generate the key pair.

[0049] The term "digital signature" may refer to an electronic signature for a message. The digital signature may be a digital value, alphanumeric value, or any other type of data including a graphical representation. The digital signature may be a unique value generated from the message and a private key using a cryptographic algorithm. In some embodiments, a confirmation algorithm using the public key may be used to confirm the signature.

[0050] "Server computer" may include a powerful computer or a computer cluster. For example, the server computer may be a mainframe, a small computer cluster, or a group of servers that act as a unit. In one example, the server computer may be a database server coupled to a web server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the foregoing for servicing requests from one or more client computers.

[0051] Figure 1System 100 is shown including a number of components. The system includes a user computer 110 operated by a user (not shown). The user computer 110 may communicate with a sending agency computer 160, which may be associated with an issuer node computer 165. System 100 also includes a resource provider computer 130 associated with a resource provider (not shown). The resource provider computer 130 may communicate with a receiving agency computer 140, which may be associated with a recipient node computer 145. The system also includes an interactive platform 154, one or more management node computers 150, a foreign exchange trading application interface 152, a settlement service computer 155, a transaction repository 156, and a risk management computer 157. Figure 1 Each of the entities shown in Figure 1 may be operably communicable with each other via any suitable communication channel or communication network. Suitable communication networks may be any one and / or combination of the following: direct interconnection, the Internet, local area network (LAN), metropolitan area network (MAN), operations over a metropolitan area network (OMNI), secure custom connection, wide area network (WAN), wireless network (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), i-mode, etc.).

[0052] Messages between computers, networks, and devices may be transmitted using secure communication protocols such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), etc.

[0053] System 100 may allow individuals, businesses, and other entities to transfer value to each other. System 100 may use "push" transaction messages, which are digitally signed and verified by a trusted central entity. Transactions may also be recorded in a trusted ledger (e.g., blockchain). Thus, push messages can be trusted and relied upon. Push messages may be used as an alternative to typical authorization request messages, authorization response messages, and / or clearing messages.

[0054] System 100 may include a network of nodes, such as management node computers 150, issuer node computers 165, and recipient node computers 145. These nodes may be combined to form an asset transfer network (e.g., a blockchain network). Such an asset transfer network may be used to provide any suitable type of digital asset, such as payment digital assets (e.g., for the transfer of monetary value) or access digital assets (e.g., for the transfer of access rights).

[0055] As an example, system 100 can be used as a transaction system for providing payments. For explanatory purposes, the entire system 100 can be referred to as a transaction system, and the central network of nodes (e.g., one or more receiving node computers 145, one or more administrative node computers 150, one or more issuer node computers 165) can be referred to as an asset transfer network.

[0056] In such a transaction system, a user can provide a payment to a resource provider. To do so, user computer 110 can command sending institution computer 160 to transfer value from the user's account at sending institution computer 160. Sending institution computer 160 can then interact with the asset transfer network to request that a digital asset be sent to the resource provider. The digital asset can be a highly trusted commitment of value transfer. Thus, when the receiving institution receives the official digital asset associated with the asset transfer network, the receiving institution can be notified and assured that the value will be transferred from the user's account to the resource provider's account. This value can be settled between the accounts at a later time (e.g., through a settlement account at a central clearing bank).

[0057] For illustrative purposes, system 100 shows an example of a user (associated with user computer 110) and a resource provider (associated with resource provider computer 130). Embodiments also allow value to be sent to or received from any suitable entity. For example, system 100 can host business-to-business payments, peer-to-peer payments, and any other suitable type of transfer.

[0058] To participate in system 100, a user can register. For example, the user can register (through user computer 110 and / or an interface provided by sending institution computer 160) with the asset transfer network. The asset transfer network for the registration service can be provided by interaction platform 154 and / or administrative node computer 150. The asset transfer network administrator (e.g., interaction platform 154) can associate an enterprise ID with the user and the user's account in user computer 110. In some embodiments, sending institution computer 160 can obtain the enterprise ID on behalf of the user from interaction platform 154.

[0059] Sending institution computer 160 can store value on behalf of the user. Sending institution computer 160 is also capable of providing value on behalf of the user (e.g., providing a payment). Examples of sending institutions can be issuers, which generally can refer to commercial entities (e.g., banks) that issue and maintain user accounts (e.g., bank accounts).

[0060] User accounts at the sending institution computer 160 can be associated with various user information. For example, a user transaction account can be associated with the following: first name, last name, government-issued identification number (such as a driver's license number, passport number, or social security number), date of birth, residential and / or business address, phone number, account username, account password, email address, etc.

[0061] The sending institution computer 160 can also register with the asset transfer network (e.g., through the management node computer 150 or the interaction platform 154) in order to interact with the network. As a result, the sending institution computer 160 can also receive a unique enterprise ID.

[0062] In some embodiments, the sending institution computer 160 can also receive a key pair. This key pair can be stored in a hardware security module (HSM). In some embodiments, the sending institution computer 160 can maintain its own HSM. Alternatively, the sending institution computer 160 key pair can be stored in an HSM of another entity (e.g., the HSM at the issuer node computer 165 or the management node computer 150).

[0063] The sending institution computer 160 can be associated with and / or represented by the issuer node computer 165, which is capable of providing payments (e.g., via digital assets) on behalf of the sending institution computer 160 in the asset transfer network.

[0064] As explained in more detail below, the embodiments provide several ways for the sending institution computer 160 to interact with the asset transfer network to request a value transfer. For example, in some embodiments, the sending institution computer 160 can work closely with the interaction platform 154, which can generate digital assets and interact with the asset transfer network on behalf of the sending institution computer 160. In such a case, the sending institution computer 160 can command the interaction platform 154 to initiate a value transfer from the user account to the resource provider account. The interaction platform 154 can then generate a digital asset, digitally sign the digital asset (e.g., with one or more digital signatures based on one or more private keys), and then provide the digital asset to the asset transfer network (e.g., the management node computer 150 or the issuer node computer 165). The digital asset can then be distributed within the asset transfer network and recorded.

[0065] In an alternative example, the sending institution computer 160 may instead work more closely with the issuer node computer 165 that represents the sending institution computer 160. The issuer node computer 165 replaces the interaction platform 154 and can generate digital assets and digitally sign the digital assets on behalf of the sending institution computer 160. However, in some embodiments, the interaction platform 154 may still play a role by providing an interface for the sending institution computer 160 to communicate with the issuer node computer 165. In such a case, the sending institution computer 160 may command the issuer node computer 165 to initiate a value transfer from the user account to the resource provider account. The issuer node computer 165 may then generate a digital asset indicating the transfer of funds from the user to the resource provider. The issuer node computer 165 may digitally sign the digital asset, obtain a second digital signature from the management node computer 150, and provide the digital asset to the receiving node computer 145. The receiving node computer 145 may provide the digital asset to the receiving institution computer 140.

[0066] In other embodiments, the sending institution computer 160 may directly manage and control the issuer node computer 165 or may have white-label access to the asset transfer network. In any case, there are ways for the sending institution computer 160 to access the network and initiate transactions.

[0067] The interaction platform 154 may include one or more service computers. As mentioned above, the interaction platform 154 may facilitate the interaction between the asset transfer network and financial institutions (such as the sending institution computer 160 and the receiving institution computer 140). For example, the interaction platform 154 may include platforms and interfaces (such as application interfaces) that allow financial institutions and users to access the asset transfer network (such as communicate with nodes in the network).

[0068] Embodiments allow the interaction platform 154 to play a more active role by performing tasks such as registering users, generating digital assets, signing digital assets, and maintaining transaction records. Other embodiments allow the interaction platform 154 to play a more passive role by performing fewer tasks and instead mainly acting as a communication interface between the asset transfer network and financial institutions.

[0069] The interaction platform 154 may allow users (through the user computer 110) and financial institutions to register to participate in the asset transfer network and set up profiles. The interaction platform 154 may also provide an interface where users and financial institutions can initiate transactions, view foreign exchange rates and transfer fees, and receive coordination information for the transactions.

[0070] The interaction platform 154 can also save records of transactions that have occurred (such as a list of transactions or a ledger of the blockchain type). In addition, the interaction platform 154 can perform analysis of user and bank behaviors. Users and financial institutions can be allowed to view the analysis, view the global directory, and view network adaptation information.

[0071] As described above, the interaction platform 154 can also perform many services related to generating assets, digitally signing assets, storing transaction records, and any other suitable services. However, these services are also described below with reference to the management node computer 165. This is because in some embodiments, some or all of the functions described below with reference to the management node computer 150 can instead be performed by the interaction platform 154. Similarly, some or all of the functions regarding the interaction platform 154 can instead be performed by the management node computer 150. Additionally, the interaction platform 154 and the management node computer 150 can be combined into a single entity. In some embodiments, the management node computer 150 can be a node associated with the interaction platform 154 and participating in the asset transfer network on behalf of the interaction platform 154 (e.g., in a manner similar to how the issuer node computer 165 is associated with the sending institution computer 160).

[0072] Embodiments allow the interaction platform 154 and the management node computer 150 to exchange functions and / or be combined because in some embodiments, these two entities can be associated with the same management entity and / or operated by the same management entity. This management entity (not shown in system 100) can be a central entity that manages system 100. Thus, the interaction platform 154 and the management node computer 150 can cooperate together as different components of a network organization entity. This management entity can be associated with several other entities in system 100 and / or operate several different entities, such as, for example, the interaction platform 154, the foreign exchange trading application interface 152, the settlement service computer 155, the transaction repository 156, and / or the risk management computer 157.

[0073] In some embodiments, the management entity can also operate the asset transfer network. For example, the management entity can provide the issuer node computer 165, the management node computer 150, and / or the receiving node computer 145. However, in other embodiments, a third - party entity can provide the asset transfer network (e.g., the management entity can outsource the control of the asset transfer network). Even in this case, the management entity can still operate one or more nodes (such as the management node computer 150), or the management entity can communicate with the management node computer 150 that represents the management entity within the asset transfer network.

[0074] In some embodiments, the management entity can be a transaction processing entity (e.g., one or more transaction processing computers). As an example, the transaction processing computer can include a data processing subsystem, a network, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. For example, the transaction processing computer can include a server (e.g., via an external communication interface) coupled to a network interface and an information database. The transaction processing computer can represent a transaction processing network. An exemplary transaction processing network can include VisaNet TM . Such as VisaNet TM 's transaction processing network is capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet TM specifically includes the VIP system (Visa Integrated Payment System) for processing authorization requests and the Base II system for performing clearing and settlement services. The transaction processing computer can use any suitable wired or wireless network, including the Internet.

[0075] The management node computer 150 can manage the asset transfer network. Although one management node computer 150 is shown in the system 100, there can be any suitable number of management nodes. In addition to acting as a node in the asset transfer network, the management node computer 150 can also organize and ensure the reliability of the asset transfer network. The management node computer 150 can be a trusted central entity. As a result, the asset transfer network managed by the management node computer 150 can also be trusted. For example, as explained in more detail below, the asset transfer network can be a consortium network.

[0076] The management node computer 150 can provide many services that facilitate the asset transfer network and the transaction system. For example, the management node computer 150 can register nodes, service providers, users, etc. The management node computer 150 can also provide enterprise identifiers and key pairs to these registered entities. The management node computer 150 can also generate digital assets, confirm new digital assets, provide digital signatures for new digital assets, and maintain a ledger of transactions.

[0077] Figure 2 An example of the management node computer 150 according to some embodiments of the present invention is shown. The management node computer 150 includes a processor 150A, a network interface 150B, a node database 150C, a ledger database 150D, a key database 150P, a user database 150Q, and a computer-readable medium 150E.

[0078] The computer-readable medium 150E may include a registration module 150F, an authentication module 150G, a risk module 150H, a confirmation module 150J, a signature module 150K, a ledger update module 150L, a digital asset module 150M, and any other suitable software modules. The computer-readable medium 150E may also include code executable by the processor 150A for implementing a method that includes receiving, from an issuer node computer, a request to confirm a digital asset that includes a first digital signature, where the first digital signature is generated using a first private key associated with the issuer node computer, and where the digital asset indicates a transfer of value from a sender to a receiver; authenticating the digital asset; generating a second digital signature for the digital asset, where the second digital signature is generated using a second private key associated with the management node computer; providing the second digital signature to the issuer node computer, where the issuer node computer sends the digital asset to a receiver node computer; recording the digital asset in a database; and coordinating a transaction associated with the digital asset.

[0079] As obtained above, one or more functions, modules, databases, or other aspects of the management node computer 150 may alternatively be implemented at the interaction platform 154.

[0080] The registration module 150F may include code that causes the processor 150A to register entities (such as financial institutions, users, and enterprises) to interact with the asset transfer network. For example, the registration module 150F may contain logic that causes the processor 150A to receive a request from an entity to join the system. This logic may include instructions for evaluating whether the entity can be registered and what level of risk to assign to the new entity. For example, the management node computer 150 may determine a risk profile for a registering financial institution based on, for example, whether it is a known bank (such as based on the financial institution name or bank identification number), the risk level of the bank's country, and whether the bank has provided collateral. The management node computer 150 may assign a risk level, as well as activity restrictions, based on the risk profile. Activity restrictions for various types of entities may include, for example, a maximum transaction threshold limit and / or a speed limit, such as a limit on the number or total digital asset value of digital assets that can be generated within a certain time period (such as a day, a week, or a month).

[0081] The registration module 150F may include instructions for assigning permissions to registered entities. For example, the management node computer 150 may allow different nodes, service providers, and users to have different views of the global transaction ledger. In some embodiments, the management node computer 150 may allow a financial institution to view transactions for which it is a party.

[0082] When a user and an enterprise register to participate in the asset transfer network, their information (such as name, address, phone number, enterprise profile of the enterprise, etc.) can be made public to the management node computer 150, so that the management node computer 150 has sufficient information about the participating entities. In addition, in some embodiments, the management node computer 150 can access user information collected by a service provider (such as a bank), such as the legal name of the user, address (street, city, country, etc.), date of birth, and any other suitable information.

[0083] The registration module 150F may also include instructions for generating and assigning enterprise IDs to registered entities. Additionally, there are instructions for generating keys and assigning the keys to registered entities. For example, the management node computer 150 can generate a key pair for a bank or a user at the time of registration. In some embodiments, the management node computer 150 can provide a digital certificate to the registered entity, which proves that the entity is authenticated by the management node computer 150, and the digital certificate links the entity to the public key. In some embodiments, the public key can be used as the enterprise ID.

[0084] Information about registered users, enterprises, and other participants can be stored in the user database 150Q. In some embodiments, a separate node database 150C may include information about other nodes (such as issuer nodes and recipient nodes) and entities associated with these nodes.

[0085] The verification module 150G may include code for causing the processor 150A to verify digital signatures. For example, the verification module 150G may contain logic for causing the processor 150A to apply the public key to the digital signature in order to verify that the signature is authentic. For example, if a signed digital asset is claimed to be generated by the issuer node computer 165, the public key associated with the issuer node computer 165 can be used to verify the signature.

[0086] The risk module 150H may include code for causing the processor 150A to evaluate transaction risks and / or entity risks. For example, the risk module 150H may contain logic for causing the processor 150A to determine the risk of a certain digital asset based on the transaction speed of one or more parties involved.

[0087] The risk module 150H may also include instructions for setting restrictions on entities that are exhibiting risky behavior or entities involved in settlement failures. For example, if a financial institution is exceeding its consumption limit, the management node computer 150 can temporarily block the generation of digital assets by the financial institution.

[0088] The confirmation module 150J may include code that causes the processor 150A to confirm a transaction. For example, the confirmation module 150J may contain logic that causes the processor 150A to analyze information in the digital asset and determine whether to approve the digital asset. For example, the instructions may include determining whether the named recipient (and / or sender) of the digital asset is a registered customer who has been screened for compliance. The instructions may also include verifying that the financial institution (or other service provider) complies with rules and protocols. For example, a financial institution may be required to have customer due diligence compliance (e.g., sufficient information about the user), Office of Foreign Assets Control compliance, anti-money laundering compliance, etc. Additionally, in some embodiments, the final transaction amount and currency may be confirmed based on the sending amount and currency, foreign exchange rates, and transfer fees.

[0089] The signature module 150K may include code that causes the processor 150A to generate a digital signature. For example, the signature module 150K may contain logic that causes the processor 150A to generate a digital signature for the digital asset using the management node private key. The digital signature of the management node computer can be used to indicate the authenticity of the digital asset and can provide assurance that the transfer is valid and trustworthy. In some embodiments, the digital signature of the management node computer may be considered a co-signature of the digital asset or the minting of the digital asset. Additionally, the digital signature can activate a smart contract that makes the sending institution computer 160 responsible for sending the amount in the original currency. For example, after a certain amount of time, the smart contract may automatically initiate a settlement process.

[0090] In some embodiments, the management node computer 150 may include a hardware security module or be associated with a hardware security module ( Figure 2 shown as the key database 150P in the figure). The hardware security module (HSM) may store one or more keys (e.g., private keys) for the management node computer 150, and the hardware security module may sign messages and / or digital assets on behalf of the issuer node computer 165.

[0091] The ledger update module 150L may include code that causes the processor 150A to save the ledger of the transaction. For example, the ledger update module 150L may contain logic that causes the processor 150A to record information about the digital asset along with the records of previous digital assets. For example, the management node computer 150 may record the digital asset once it has been minted (e.g., approved and digitally signed) and / or once the digital asset has been sent to the recipient node computer 145. The ledger may be authenticated by the management node computer 150 as being authentic, and the authenticity may be shown by a digital signature (e.g., for each transaction or for the entire ledger).

[0092] In some embodiments, the updated ledger module 150L may include instructions for maintaining a ledger of transactions in the form of a blockchain. For example, the management node computer 150 is capable of creating and / or signing new blocks. After an average time interval (e.g., every minute, ten minutes, 1 hour, etc.), a new block including one or more digital assets may be generated. Authenticity may be provided to the block via a digital signature. The management node computer 150 may optionally create a hash header for each block based on the digital assets in the block, the hash of the previous block, a one-time random value, a nonce, and / or any other suitable information.

[0093] The ledger, such as a blockchain ledger, may be stored in the ledger database 150D. An additional database may store transaction records (e.g., a list of transactions not in the blockchain) and / or invoice records. Additionally, a settlement database may include information about transactions pending settlement. In some embodiments, one or more of these databases may alternatively be implemented by the transaction repository 156.

[0094] In embodiments of the present invention, the blockchain ledger may not exist on all computers in the distributed network, but may be maintained by the secure management node computer 150. Thus, computationally intensive features such as proof-of-work may not exist or may not be required. In some embodiments, there may be multiple management node computers 150, each receiving transaction updates and updating its own ledger. These different management node computers 150 may communicate with each other to confirm that their ledgers have the same transaction information.

[0095] The updated ledger module 150L may further include instructions for providing transaction updates to other nodes. For example, when a new digital asset is confirmed and signed, the management node computer 150 may distribute information about the new digital asset to other nodes in the network (other management nodes, issuer nodes, and / or recipient nodes) such that the other nodes may update their own ledgers. The management node computer 150 may additionally or alternatively distribute information about ledger updates (e.g., new transaction blocks).

[0096] In some embodiments, the issuer node and the recipient node may not maintain their own ledgers and may instead reference the centrally maintained ledger of the management node computer 150. For example, the issuer node computer 165 and the recipient node computer 145 may both be lightweight nodes. In such a case, the management node computer 150 may provide other nodes with real-time access to the central ledger, or the management node computer 150 may provide regular ledger updates (e.g., updates may be sent every 10 seconds, 1 minute, 5 minutes, etc.). As a result, other nodes may know about new digital assets immediately or shortly after the digital assets are minted.

[0097] The ledger of the transactions can provide the management node 150 with real-time visibility into the net position of each financial institution, user, and / or enterprise at any point in time. However, in some embodiments, other entities may not be able to see the entire ledger, but rather they may have a filtered or permitted view of the ledger. For example, other nodes, financial institutions, and / or users may only be able to view the transactions for which they are a party.

[0098] This selective disclosure of sensitive information in the global ledger can be accomplished through one or more techniques. For example, the management node computer 150 may not provide other nodes (such as the issuer node computer 165 and / or the recipient node computer 145) with access to the entire ledger. Instead, the management node computer 150 may only allow each node to view the transactions associated with it in the ledger. For example, the management node computer 150 may send a trimmed-down copy of the ledger to each node, or may block portions of the ledger as the central ledger is being accessed by the nodes.

[0099] In some embodiments, a one-time use address (such as a one-time use enterprise ID or other one-time use identifier) may be used for the payee and / or payer. As a result, users and / or resource providers may not be individually identified based on the address or other information in the digital asset. Thus, even though the transactions (and transaction details) are publicly viewable, users may not be identified based on the information in the transactions. Instead, the identity and account of the user may remain anonymous. However, the user and resource may keep information about the one-time use addresses and identify which ones were used, thereby being able to identify the transactions in the ledger for which they were a party.

[0100] In some embodiments, a filtered ledger view can also be achieved by encrypting the metadata in the digital asset. For example, the information identifying the user and / or resource provider in the digital asset may be encrypted with the public key associated with the user and / or resource provider. As a result, only the user and / or resource provider can decrypt and view the identifying (or other) information in the digital asset included in the ledger for which they are a party.

[0101] In some embodiments, zero-knowledge proofs can be used to establish a filtered ledger view. Zero-knowledge proofs can hide the value and / or identifying information of the digital assets in a transaction while allowing the entire network to confirm the integrity of the content. For example, an external user can use a zero-knowledge proof to verify that the claimed value of a digital asset is genuine (not fraudulent), but the external user cannot identify the value involved or the exact history of the parties. As a result, only the parties involved (and those granted access) can view the details of the transaction. Embodiments may not require a proof of work because the ledger is trusted without these verifications (such as due to the federated nature of the network).

[0102] The updated ledger module 150L may further include instructions for transmitting information about the new digital asset to an end user (such as user computer 110 and / or resource provider computer 130). For example, when a digital asset is created, signed, and / or distributed, the management node computer 150 may send a message to the user computer and / or resource provider computer 130. As a result, the end user can know about the new transfer when it starts to occur. In some embodiments, the message may alternatively be sent to a service provider (such as the sending institution computer 160 and / or receiving institution computer 140), which in turn may notify the end user.

[0103] As mentioned above, in some embodiments, the management node computer 150 (or interaction platform 154) may perform one or more functions in place of the issuer node computer 165. For example, instead of the issuer node computer 165, the management node computer 150 may generate a digital asset on behalf of the sending institution computer 160. For this reason, the management node computer 150 may include a digital asset module 150M. The digital asset module 150M may include a module that causes the processor 150A to create a digital asset. For example, the digital asset module 150M may contain logic that causes the processor 150A to generate a digital asset that includes information associated with transferring value from a user account to a recipient account.

[0104] In addition, in some embodiments, the management node computer 150 may generate a digital signature on behalf of the sending institution computer 160 and / or the issuer node computer 165. For example, the management node computer 150 may store keys associated with the sending institution computer 160 and / or the issuer node computer 165, and may create a digital signature for the digital asset after generating the digital asset.

[0105] Referring again to Figure 1 , the issuer node computer 165 may be a node in the asset transfer network, and the issuer node computer 165 may be associated with the sending institution computer 160. The issuer node computer 165 is capable of generating, minting (or requesting minting), and / or providing digital assets in order to transfer value (such as funds) on behalf of the sending institution computer 160. In some embodiments, the issuer node computer 165 may receive a payment instruction from the sending institution computer 160 via the interaction platform 154.

[0106] In some embodiments, the issuer node computer 165 may serve a single financial institution exclusively. In other embodiments, the issuer node computer 165 may represent two or more financial institutions (such as multiple banks).

[0107] In some embodiments, the issuer node computer 165 may be centrally registered (e.g., through the management node computer 150 or a third-party registration service provider) to participate in the asset transfer network. Once registered, the issuer node computer 165 may be associated with an enterprise ID.

[0108] Figure 3 An example of the issuer node computer 165 according to some embodiments of the present invention is shown. The issuer node computer 165 includes a processor 165A, a network interface 165B, a ledger database 165C, and a computer-readable medium 165D.

[0109] The computer-readable medium 165D may include an interaction module 165E, a digital asset module 165F, a signature module 165G, an approval module 165H, a distribution module 165J, an update ledger module 165K, and any other suitable software modules. The computer-readable medium 165F may also include code executable by the processor 165A to implement a method that includes: receiving a request to transfer value from a sender associated with a sender identifier to a receiver associated with a receiver identifier; generating a digital asset indicating that the value is being transferred to the receiver; generating a first digital signature for the digital asset, the first digital signature being generated using a first private key associated with the issuer node computer; sending a request to confirm the digital asset to the management node computer, the request including the digital asset and the first digital signature, wherein the management node computer confirms the digital asset and generates a second digital signature for the digital asset, the second digital signature being generated using a second private key associated with the management node computer; receiving the second digital signature from the management node computer; and providing the digital asset to a receiver node computer associated with the receiver, wherein the management node computer records the digital asset in a database and coordinates the transaction associated with the digital asset.

[0110] The interaction module 165E may include code that enables the processor 165A to interact with other entities such as the sending institution computer 160 and the interaction platform 154. For example, the interaction module 165E may contain logic that enables the processor 165A to receive payment instructions from the sending institution computer 160 (e.g., through the interaction platform 154).

[0111] The digital asset module 165F may include code that enables the processor 165A to create digital assets. For example, the digital asset module 165F may contain logic that enables the processor 165A to generate digital assets that include information for transferring value from a user account to a receiver account.

[0112] Signature module 165G may include code that causes processor 165A to create a digital signature. For example, signature module 165G may contain logic that causes processor 165A to apply a private key and / or a mathematical algorithm to a digital asset such that a digital signature is generated for the digital asset. Other entities (such as other nodes) can then use the corresponding public key to verify the digital signature, thereby verifying the authenticity of the digital asset.

[0113] In some embodiments, the issuer node computer 165 may include or be associated with a hardware security module. The hardware security module (HSM) may store one or more keys (such as a private key) for the issuer node computer 165, and the hardware security module may sign messages and / or digital assets on behalf of the issuer node computer 165.

[0114] In some embodiments, the key pair of the issuer node computer may be generated and provided by the management node computer 150 (such as via a digital certificate) or by a separate third-party service computer. In other embodiments, the key pair of the issuer node computer may be generated locally (such as by the hardware security module). When the key pair is generated locally, the issuer node computer 165 may provide the key pair to the management node computer 150 during the registration process.

[0115] Approval module 165H may include code that causes processor 165A to obtain approval for a digital asset. For example, approval module 165H may contain logic that causes processor 165A to provide the digital asset and / or the corresponding issuer node digital signature to the management node computer 150 in order to obtain approval and a second digital signature from the management node computer 150. The management node computer 150 may then verify the digital signature of the issuer node computer, confirm the digital asset, and generate a second digital signature for the digital asset.

[0116] Distribution module 165J may include code that causes processor 165A to distribute a digital asset. For example, distribution module 165J may contain logic that causes processor 165A to provide the digital asset to the recipient node computer 145, the management node computer 150, and / or any other suitable node or other entity. In order to provide the digital asset to the appropriate recipient node computer 145, the issuer node computer 165 may operate an appropriate routing table. For example, the recipient node computer 145 may be identified based on an enterprise identifier, a public key, a bank identification number, and / or any other suitable identifier in the digital asset.

[0117] The Update Ledger Module 165K may include code that causes the processor 165A to record information related to the creation and / or distribution of digital assets used for transactions. For example, the Update Ledger Module 165K may contain logic that causes the processor 165A to update ledger records of transactions by basing them on new digital assets or other transactions. This ledger may be stored in the ledger database 165C. The Update Ledger Module 165K may include instructions for adding a block to a blockchain, the new block including information about one or more transactions.

[0118] In some embodiments, the Issuer Node Computer 165 may view the ledger maintained by the Management Node Computer 150 or by a third-party ledger manager, rather than maintaining its own ledger.

[0119] In some embodiments, the Issuer Node Computer 165 may only be able to view a subset of the transactions that occur within the asset transfer network. For example, the Issuer Node Computer 165 may have a filtered view of the full ledger (e.g., blockchain) maintained by the Management Node Computer 150. The Issuer Node Computer 165 is able to view the transaction records of transactions in which the Issuer Node Computer 165 or the Sending Institution Computer 160 is a party.

[0120] This filtered ledger view may be implemented in several possible ways. In one instance, the Issuer Node Computer 165 may be a light node that only receives information about relevant transactions. In another instance, the Issuer Node Computer 165 may obfuscate the ledger such that the view of the receiving institution computer of the ledger is filtered. In another instance, the digital asset may include less information about the providing entity (e.g., user, sending bank, and / or sending node) such that the recipient may receive value from the digital asset without exposing personal sender information. Techniques for providing a filtered ledger view are described above.

[0121] In some embodiments, one or more of the functions of the Issuer Node Computer 165 described above may instead be performed by another entity such as the Management Node Computer 150 or the Interaction Platform 154. For example, instead of the Issuer Node Computer 165, the Interaction Platform 154 may generate digital assets on behalf of the Sending Institution Computer 160 (e.g., the Interaction Platform 154 may perform this operation instead of forwarding transaction instructions to the Issuer Node Computer 165). Similarly, in some embodiments, another entity may manage keys on behalf of the Issuer Node Computer 165 and provide digital signatures. For example, the Management Node Computer 150 or the Interaction Platform 154 is able to store the keys of the Issuer Node Computer in the HSM and is able to generate digital signatures for digital assets on behalf of the Issuer Node Computer 165.

[0122] Referring again to Figure 1, the recipient node computer 145 can be a node in the asset transfer network. The recipient node computer 145 can be associated with or operated by the receiving institution computer 140. For example, the recipient node computer 145 can receive digital assets on behalf of the receiving institution computer 140, can store digital assets on behalf of the receiving institution computer 140, and can transfer the received digital assets to the receiving institution computer 140 (e.g., via the interaction platform 154).

[0123] In some embodiments, the recipient node computer 145 can serve a single financial institution. In other embodiments, the recipient node computer 145 can represent two or more financial institutions (e.g., multiple banks).

[0124] The recipient node computer 145 can be centrally registered (e.g., via the management node computer 150) to participate in the asset transfer network. Once registered, the recipient node computer 145 can be associated with an enterprise ID.

[0125] The recipient node computer 145 can receive digital assets sent by the issuer node computer 165 and / or the management node computer 150. In some embodiments, the digital assets can be broadcast to several or all nodes, and the recipient node computer 145 can identify which digital assets are relevant to the receiving institution and / or resource provider (e.g., based on the receiving enterprise ID indicated in the digital asset).

[0126] The recipient node computer 145 can also confirm that the digital asset is authentic. For example, the recipient node computer 145 can verify one or more digital signatures associated with the digital asset. The digital signature can be verified using the public key associated with the signing entity (e.g., the sending institution computer 160, the issuer node computer 165, and / or the management node computer 150).

[0127] In some embodiments, the recipient node computer 145 can also record information about the digital assets received for a transaction. For example, the recipient node computer 145 can update the ledger for the transaction based on the new digital assets or other transactions. In some embodiments, the recipient node computer 145 can add a block to the blockchain, where the new block includes information about one or more digital assets. In other embodiments, the recipient node computer 145 can view the ledger maintained by the management node computer 150 instead of maintaining its own ledger.

[0128] In some embodiments, the recipient node computer 145 may only be able to view a subset of the transactions occurring within the asset transfer network. For example, the recipient node computer 145 may have a filtered view of the full ledger (e.g., blockchain) maintained by the administrative node computer 150. The recipient node computer 145 is able to view the transaction records of transactions for which the recipient node computer 145 or the recipient institution computer 140 is a party. For example, the recipient node computer 145 may be a lightweight node that only receives information about relevant transactions. In some embodiments, the recipient node computer 145 may obfuscate the ledger such that the view of the ledger by the recipient institution computer is filtered.

[0129] The issuer node computer 165 and the recipient node computer 145 may provide different services (e.g., providing and receiving digital assets) to financial institutions using the asset transfer network. Thus, each financial institution (e.g., the sending institution computer 160 and the recipient institution computer 140) may use the services of both the issuer node computer 165 and the recipient node computer 145. In some embodiments, a single node may act as both an issuer node and a recipient node.

[0130] The recipient institution computer 140 may store value and receive value (e.g., receive payments) on behalf of the resource provider computer 130. Examples of recipient institutions may be acquirers, which are typically business entities (e.g., commercial banks) that have a business relationship with a particular resource provider or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may include such single-entity issuer-acquirers.

[0131] In some embodiments, the recipient institution computer 140 may make the value indicated in the received digital asset immediately available (e.g., withdrawable) in the resource provider account. The recipient institution computer 140 may settle the transaction by receiving the actual value at a later time (instead of just an IOU).

[0132] The recipient institution computer 140 may register to interact with the asset transfer network (e.g., via the interaction platform 154 or the administrative node computer 150) in order to participate in the system 100. As a result, the recipient institution computer 140 may receive a unique enterprise ID and be associated with the unique enterprise ID. In some embodiments, the recipient institution computer 140 may also receive a key pair and be associated with the key pair. This key pair may be stored in an HSM.

[0133] The resource provider computer 130 may be associated with a resource provider, which may be an entity capable of providing resources such as goods, services, information, and / or access. Examples of resource providers include merchants, access devices, secure data access points, etc. A merchant is typically an entity that participates in a transaction and is capable of selling goods or services or providing access to goods or services.

[0134] The resource provider may have an account at the receiving institution computer 140. The account may be associated with various resource provider information. For example, a resource provider account may be associated with a merchant name, residential and / or business address, phone number, account username, account password, email address, etc.

[0135] The resource provider computer 130 may register for the asset transfer network service. For example, the resource provider may register through the interactive platform 154, or the receiving institution computer 140 may register on behalf of the resource provider. Thus, the resource provider computer 130 may also be associated with a unique enterprise ID.

[0136] The foreign exchange trading application interface 152 may provide information about foreign exchange rates. For example, before initiating an international transaction, the user computer 110 and / or the sending institution computer 160 are able to view the real-time foreign exchange rate for the transaction. In some embodiments, the foreign exchange trading application interface 152 may be provided by the interactive platform 154, the management node computer 150, or alternatively by a management entity (such as a payment processing entity).

[0137] The settlement service computer 155 (which may include one or more service computers) is able to provide settlement services. For example, a digital asset may act as a guarantee for a payment or IOU (such as proof of a potential payment), but the actual transfer of funds may not actually occur when the digital asset is provided. Thus, after sending a digital asset, the settlement service computer 155 is able to facilitate the actual exchange of funds between the sending institution computer 160 and the receiving institution computer 140 (such as by transferring value between corresponding settlement accounts at a central settlement bank). By interacting with a central settlement account service (such as a central bank) that may be associated with the asset transfer network, the settlement service computer 155 may facilitate settlement. For example, the central bank may be associated with the management node computer 150, the interactive platform 154, or a management entity. In some embodiments, the settlement service computer 155 itself may be operated by the interactive platform 154 or alternatively by a management entity (such as a payment processing entity).

[0138] The transaction repository 156 (which may include one or more service computers) may be a database for past transactions. For example, a ledger of transactions may be stored in the transaction repository 156. The management node computer 150 may store its ledger (such as a blockchain ledger) or non-blockchain records of transactions in the transaction repository 156.

[0139] A risk management computer 157 (which may include one or more service computers) may provide risk management services. For example, the risk management computer 157 may analyze risks associated with digital assets sent in the asset transfer network. In some embodiments, the functions described with respect to the risk module 150H at the management node computer 150 may alternatively be performed by the risk management computer 157.

[0140] In some embodiments, the system 100 may include one or more asset audit nodes (not shown) capable of auditing the network. For example, the asset audit nodes may confirm that different ledgers match, that nodes and financial institutions are operating within rules and restrictions, and that double spending has not occurred. The asset audit nodes may be operated by the same management entity as the interaction platform 154 and / or the management node computer 150.

[0141] As mentioned above, the system 100 can be used for any type of value transfer, such as the transfer of access credentials, digital media, or any other suitable value. Thus, service providers that are not financial institutions can also participate in the system 100. For example, other service providers can manage user accounts, operate issuer nodes and recipient nodes, etc.

[0142] In Figure 4 an example of an asset transfer network is shown. In some embodiments, as Figure 4 shown, several nodes are capable of providing and receiving digital assets within the asset transfer network. An example transfer is shown, where the issuer node computer 165 is providing digital assets to the recipient node computer 145. Although a direct arrow is shown, the issuer node computer 165 may actually broadcast digital asset information to some or all of the nodes in the network. One or more management nodes may maintain a ledger of digital assets that have been transferred between nodes.

[0143] In some embodiments, the asset transfer network may be a blockchain network. For example, the ledger may take the form of a blockchain. Each block in the blockchain may include information about one or more transactions (e.g., digital assets). A blockchain ledger cannot be changed without detection. For example, each block may include a data header that includes the hash of the previous block in the blockchain ledger and the root value of all previous transactions. Since each block in the blockchain ledger can be generated in a similar manner by including a data header that stores information referencing its previous entry and previous transactions, no entry can be modified without affecting all subsequent entries. This ensures that no tampering with information related to transactions can go undetected, such as attempting to reallocate digital assets to an inappropriate entity.

[0144] In some embodiments, the asset transfer network can be a federated asset transfer network (also referred to as a "permissioned" asset transfer network). For example, permission may be required from a trusted central party in order to participate in the asset transfer network. As explained above, the management node computer 150 is capable of registering entities into the network. Thus, the management node computer 150 can determine which parties participate and set the rules and protocols for participating in the network. The management node computer 150 can also restrict entities as needed (e.g., restrict or block a financial institution due to bad behavior).

[0145] Entities that can be confirmed for the network (e.g., registered entities to participate and enforce compliance) can be referred to as "federated" entities. In some embodiments, the management node computer 150 can be the only federated entity. In other embodiments, another entity can perform this management role in place of the management node computer 150. For example, a management entity (which can be associated with the management node computer 150) or a separate third-party service provider can manage the asset transfer network.

[0146] In some embodiments, the asset transfer network can act as a proprietary asset transfer network. For example, the asset transfer network can be used as a tool for a transaction processor to record transactions. The network ledger can be essentially an outsourced record-keeping system and can only be accessed and / or modified by the transaction processor.

[0147] Reference may be made to Figure 5 to describe method 500 according to embodiments of the present invention. Some elements in other figures will also be referred to. In embodiments of the present invention, the steps shown in method 500 can be performed in sequence or in any suitable order. In some embodiments, one or more of the steps can be optional.

[0148] The various messages described below can use any suitable form of communication. In some embodiments, a request or response can have an electronic message format, such as, an email, a Short Message Service (SMS) message, a Multimedia Messaging Service (MMS) message, a Hypertext Transfer Protocol (HTTP) request message, a Transmission Control Protocol (TCP) packet, a web form submission. The request or response can be directed to any suitable location, such as, an email address, a phone number, an Internet Protocol (IP) address, or a Uniform Resource Locator (URL). In some embodiments, a request or response can include a mix of different message types, such as, both an email message and an SMS message.

[0149] As described above, many entities can register to interact with an asset transfer network, which can be a blockchain network. Each entity (e.g., a node, a financial institution, and a user) can be associated with a unique enterprise ID and be identifiable based on the unique enterprise ID. In the example below, currency is transferred using the network. However, any other suitable type of value can also be transferred (e.g., using credit, access credentials, ownership certificates, digital media, etc.).

[0150] The user computer 510 can initiate providing value to the resource provider computer 530. For example, the resource provider can provide goods and services to the user, and the resource provider computer 530 can send a payment invoice to the user computer 510. The invoice can include an amount, a currency type, an enterprise ID associated with the resource provider computer 530 or the resource provider account, information about the goods and services provided, an invoice identifier, and any other suitable information.

[0151] In step S502, the user (e.g., via the user computer 510) can contact the sending institution computer 560 to request sending a payment to the resource provider computer 530. The user computer 510 can provide any suitable information about the payment, such as the amount and the recipient currency type, information identifying the recipient (e.g., the enterprise ID of the resource provider), the invoice, and the selection of the user account from which to withdraw funds for the payment.

[0152] The payment can be an international transfer. For illustrative purposes only, the user account can be an account headquartered in the United States and include US dollars. The recipient (e.g., the resource provider) account can be an account headquartered in England and include British pounds.

[0153] In step S504, the sending institution computer 560 can collect information for initiating the payment. For example, for an international transaction, a foreign exchange rate may be required to identify the correct amount of currency to withdraw from the user's account. The sending institution computer 560 can obtain information about the current foreign exchange rate (e.g., the exchange rate of US dollars to British pounds) related to the transaction from a foreign exchange trading application interface (e.g., via an interactive platform).

[0154] The foreign exchange trading application interface or the interactive platform can also provide information about the transfer fees that can be charged for the transaction. For example, the sending institution computer 560, the receiving institution computer 540, and / or any one of the participating nodes for managing the transaction can charge a fee. In some embodiments, all these fees can be immediately calculated and available before the transaction is initiated. The sending institution computer 560 can also provide this fee and foreign exchange information to the user computer 510.

[0155] Thus, the sending institution computer 560 can determine the amount of funds to be withdrawn from the user's account (i.e., how much to charge the user). The total charge can be calculated based on the amount that the resource provider should receive, the transfer fee, and the exchange rate.

[0156] For example, a user may wish to provide 1000 British pounds to a resource provider. The foreign exchange rate may be 1 British pound to 1.33 US dollars. Thus, 1330 US dollars may be required to provide 1000 British pounds. Additionally, the sending institution computer 560 may charge 15 US dollars for the transfer. Thus, it can be determined that the user will be charged 1345 US dollars to provide 1000 British pounds.

[0157] In other embodiments, the sending institution computer 560 may instead start with the amount to be sent in the original currency as indicated by the user, and may deduct the fees and exchange rate in order to determine the amount that the resource provider will receive.

[0158] The sending institution computer 560 can also check that the transaction will comply with the rules and restrictions set for the user and / or the sending institution computer 560, and perform any suitable risk analysis. For example, the sending institution computer 560 can verify that the transaction will not exceed the speed or amount thresholds for the user's account or the sending institution computer 560. The sending institution computer 560 can also verify that the user's account has sufficient funds to conduct the transaction.

[0159] In step S506, the sending institution computer 560 can send a transaction request to the issuer node computer 565 (e.g., via an interaction platform). The request may include information for providing the payment to the resource provider, such as information about the original currency, target currency, amount, fees and exchange rate, resource provider enterprise ID, user enterprise ID, and sending institution computer 560 enterprise ID, as well as any other suitable information.

[0160] The sending institution computer 560 can also debit or temporarily freeze the total charge amount from the user's account. Thus, the funds can still be available for settlement at a later time.

[0161] In step S508, the issuer node computer 565 may generate a digital asset for the requested transaction. The digital asset may include any suitable information for conveying that value is being transferred from the user account to the resource provider account (e.g., remittance information). For example, the digital asset may include a digital asset identifier, the original currency type, the destination currency type, the amount of the sending currency, the fee and exchange rate, the amount of the destination currency, various user information (e.g., user enterprise ID, address, phone number, email address), various sending institution computer 560 information (e.g., financial institution name, enterprise ID, public key, BIN), various resource provider computer 530 information (e.g., enterprise ID, name, address, phone number, email address), various receiving institution computer 540 information (e.g., financial institution name, enterprise ID, public key, BIN), the issuer node computer 565 enterprise ID and / or public key, the recipient node computer 545 enterprise ID and / or public key, the invoice number and invoice information, the purchase order number, the timestamp, and any other suitable information. The digital asset identifier may be an identifier that uniquely identifies the digital asset generated by the issuer node computer 565. For example, the digital asset identifier may be an alphanumeric string or a scannable image (e.g., QR code). The transaction identifier may be used as the digital asset identifier.

[0162] The issuer node computer 565 may also generate a digital signature for the digital asset, which indicates that the digital asset was truly created by the issuer node computer 565. The digital signature may be generated by applying a mathematical algorithm to the digital asset and the private key of the issuer node computer (or the private key of the sending institution computer). The digital signature may be attached to the digital asset or included in the digital asset, along with the corresponding public key of the issuer node computer used to verify the digital signature.

[0163] The digital asset may be considered as a guarantee of the payment amount. Thus, once signed and sent, each entity may consider the payment as either completed or soon to be completed. For example, the digital asset may be priced similar to a paper check and may include any necessary information for obtaining the promised funds.

[0164] Before generating and / or providing the digital asset, the issuer node computer 565 may also check that the digital asset transaction complies with rules, protocols, and restrictions (e.g., speed and transaction amount thresholds).

[0165] In step S510, the issuer node computer 565 may provide the digital asset and any other suitable information to the management node computer 550. The issuer node computer 565 may request consent for the digital asset and request a second digital signature.

[0166] In step S512, the management node computer 550 may confirm the digital asset. For example, the management node computer 550 may identify each involved entity based on the enterprise ID and ensure that each entity is registered and has a good reputation. For example, the management node computer 550 may check whether each entity follows the rules and protocols and whether it is within any risk limits. The management node computer 550 may also perform a risk analysis on the transaction, checking for any warning signs (such as an unusually high amount or a rare transfer direction for a particular account or financial institution).

[0167] The management node computer 550 may also verify the digital signature of the issuer node computer (e.g., using the public key of the issuer node computer or the public key of the sending institution computer). The management node computer 550 may also check that the attached public key is truly associated with the enterprise ID of the issuer node computer and, similarly, ensure that the other information in the digital asset is accurate and valid.

[0168] In step S514, after confirming the transaction, the management node computer 550 may generate a second digital signature for the digital asset. For example, the management node computer 550 may generate a digital signature using a private key based on the information in the digital asset. In some embodiments, after providing the second digital signature, the digital asset may be considered minted and valid. The management node computer 550 may also attach a smart contract to the digital asset.

[0169] In step S516, the management node computer 550 may provide the digital asset and the second digital signature back to the issuer node computer 565. Thus, the issuer node computer 565 may be notified that the digital asset is confirmed and ready to use.

[0170] At this time or at a later time, the management node computer 550 may also update the ledger of the transaction based on the digital asset. The entities in the ledger may include information about the value, the recipient of the value, the sender of the value, the transaction date and time, the digital asset identifier, and any other suitable information. In some embodiments, the ledger may store a copy of the digital asset.

[0171] In some embodiments, the management node computer 550 may also distribute information about the digital asset or the updated ledger to other management node computers 550. Moreover, when the ledger is updated, the transaction (such as the transfer of value from a user to a resource provider) may be considered official and guaranteed.

[0172] In some embodiments, the management node computer 550 may update the ledger by adding a new block to the blockchain, where the new block includes information about the new digital asset. The new block may also include information about other transactions that occurred during a similar period (e.g., all digital assets minted within a ten-minute interval).

[0173] In some embodiments, the ledger may not be updated (e.g., new blocks may not be added) until a transaction is confirmed in the asset transfer network. Nodes in the network may use Simplified Byzantine Fault Tolerance (SBFT) or any other suitable method to reach a consensus on how to add blocks to the blockchain at each step. In SBFT, a designated block generator (e.g., the administrative node computer 550) collects and validates proposed transactions, periodically gathering them together to form a new block proposal. Other designated block signers (e.g., the administrative node computer 550) approve the proposed block with their signatures. All network members may know the identities of the block signers, and the block is only accepted when signed by a sufficient number of signers. This ensures that competing transactions can be resolved, transactions can be final, and the history cannot be rewritten.

[0174] In step S518, after receiving the second digital signature for the digital asset, the issuer node computer 565 may update the ledger of the transaction to include the new digital asset. Alternatively, in some embodiments, the issuer node computer 565 may not maintain its own ledger and may instead refer to the ledger of the administrative node computer when needed.

[0175] In step S520, the digital asset may be generated, minted (e.g., signed), recorded, and made ready for transmission. Thus, in some embodiments, the issuer node computer 565 may provide the digital asset to the recipient node computer 545. The issuer node computer 565 may identify the correct recipient node computer 545 for providing the digital asset based on one or more enterprise IDs present in the digital asset (e.g., the enterprise ID of the recipient node computer 545, the receiving institution computer 540, or the resource provider computer 530). Embodiments allow for several alternative ways to provide the digital asset to the recipient node computer 545, which are described below after this process description.

[0176] In step S522, the recipient node computer 545 may receive the digital asset and verify the authenticity of the digital asset. For example, the recipient node computer 545 may verify that one or more digital signatures are authentic and are associated with the sending institution computer 560, the issuer node computer 565, and / or the administrative node computer 550.

[0177] In some embodiments, the digital asset may include public keys associated with the sending institution computer 560, the issuer node computer 565, and / or the administrative node computer 550. Alternatively, the digital asset may include enterprise IDs associated with one or more of these entities, and the recipient node computer 545 may query for the appropriate public keys based on the enterprise IDs. The recipient node computer 545 may then use the included public keys to verify one or more digital signatures.

[0178] In some embodiments, verifying a digital signature can be considered as verifying that the digital asset information is valid and that the digital asset value is being legally transferred. In some embodiments, the recipient node computer 545 can also confirm that the value being transferred is properly owned by the user (e.g., whether the recipient node computer 545 has a full ledger view or other access to the user's account records).

[0179] In some embodiments, the recipient node computer 545 can also update the ledger. Thus, in some embodiments, the recipient node computer 545 can refrain from maintaining its own ledger and instead refer to the ledger of the management node computer when needed.

[0180] In step S524, the recipient node computer 545 can forward the digital asset to the receiving institution computer 540 (e.g., via an interactive platform). The recipient node computer 545 can provide all digital assets to the same receiving institution computer 540, or can provide the digital assets to the receiving institution computer 540 associated with the enterprise ID indicated in the digital asset. Additionally, the recipient node computer 545 can provide a message to the resource provider computer 530, the message having information about the received digital asset and the promised value.

[0181] In step S526, the receiving institution computer 540 can store the digital asset and associate it with the resource provider's account. The receiving institution computer 540 can identify the resource provider computer 530 and / or the resource provider account based on the recipient enterprise ID indicated in the digital asset.

[0182] In some embodiments, the receiving institution computer 540 can place a high degree of trust that the digital asset is genuine and that the value will be provided. For example, the receiving institution computer 540 can trust the digital signature provided by the digital asset, the receiving institution computer 540 can trust the management node computer 550, and the receiving institution computer 540 can trust other participating network entities because they have all been screened during registration. A deceiver cannot submit a digital asset on behalf of the issuer node computer 565 because the private key of the issuer node computer can be kept confidential. Moreover, even if the transfer is initiated deceptively, the management node computer 550 can still ensure the security of the funds.

[0183] Thus, in some embodiments, the receiving institution computer 540 can immediately credit the value indicated in the digital asset to the resource provider's account. As a result, this value can be immediately available (e.g., withdrawn) upon receipt of the digital asset, even if the value has only been promised and not actually received.

[0184] The value credited to the resource provider's account may be less than the amount indicated in the digital asset. For example, the receiving institution computer 540 and / or other entities may charge a fee, which may be deducted from the provided amount.

[0185] For example, the resource provider may receive a digital asset of £1000 from a user. However, the receiving institution computer 540 may charge £20 for the transfer. Therefore, only £980 may be credited to the resource provider's account.

[0186] In step S528, the receiving institution computer 540 may notify the resource provider computer 530 that the digital asset has been received and that a specific value has been credited to the resource provider's account. The receiving institution computer 540 may provide remittance data including the payment amount, information about the sender (such as the user and / or the sending institution computer 560), and any other suitable information to the resource provider computer 630.

[0187] At this time, the user computer 510 and / or the sending institution computer 560 may also be notified that the transfer is complete. For example, the interaction platform may provide a reconnaissance document to the user computer 510 and / or the sending institution computer 560.

[0188] In step S530, at a later time, the settlement of the digital asset value may be performed between the sending institution computer 560 and the receiving institution computer 540. For example, the settlement service computer may coordinate the transfer of value. Information related to the settlement (such as the enterprise ID, amount, etc.) may be obtained from the digital asset.

[0189] In some embodiments, the settlement may include debiting the digital asset value from the user's account at the sending institution computer 560. The digital asset may also be transferred to a central bank (such as a financial institution provided by an entity managing the asset transfer network or any other suitable entity). Alternatively, the sending institution computer 560 may already have an account pre-loaded with funds at the central bank, so it may not be necessary to transfer the digital asset value from the sending institution computer 560 to the central bank at this time (such as because the funds are already at the central bank).

[0190] Settlement can continue by debiting the digital asset value (or the re-presented settlement value) from a first account (e.g., a first settlement account) associated with a sending institution computer 560 at a central bank, and this value can be credited to a second account (e.g., a second settlement account) associated with a receiving institution computer 540 at the central bank. For example, the sending institution computer 560 and the receiving institution computer 540 may have settlement accounts created at this central bank when registering to participate in the asset transfer network, and these accounts can exist specifically for the settlement process. The first account can be at a first central bank location in a first country (e.g., the United States), while the second account can be at a second central bank location in a second country (e.g., England). Thus, pounds can be credited to the second account (thereby achieving currency conversion).

[0191] Once the value reaches the second account associated with the receiving institution computer 540, the receiving institution computer 540 can then credit the digital asset value to a resource provider account at the receiving institution. Alternatively, as described above, the receiving institution computer 540 may have already credited the resource provider account in step S526.

[0192] As a result, settlement may not need to occur through multiple corresponding bank relationships. In fact, funds can be settled through the central bank between the receiving institution computer 540 and the sending institution computer 560. Additionally, each of the receiving institution computer 540 and the sending institution computer 560 can maintain only one account at the central bank (or other settlement account service provider). The receiving institution computer 540 and the sending institution computer 560 do not have to manage any other corresponding bank relationships because all transfers can be completed through the asset transfer network and the central bank. As a result, the receiving institution computer 540 and the sending institution computer 560 do not have to allocate resources for multiple corresponding accounts or otherwise interact with multiple correspondent banks.

[0193] In other embodiments, the digital asset value can be settled through one or more correspondent bank relationships (e.g., instead of through the central bank). For example, settlement can occur through one or more correspondent banks in a first country (e.g., the United States), an international correspondent bank relationship, and one or more correspondent banks in a second country (e.g., England).

[0194] In some embodiments, the digital asset can be a smart contract that is designed to settle within a predefined period (e.g., 5 hours, 1 day, or 1 week). Alternatively, the smart contract can cause the settlement process to be executed together with the next batch of settlements or at a specific time of day. After settlement, the digital asset can be destroyed (e.g., deleted or marked as settled). Also, the digital asset can be digitally signed to indicate that settlement is complete, and the transaction record can be stored (e.g., in a database list or a blockchain ledger).

[0195] In some embodiments, many digital asset transfers can be settled at the same time. Thus, the net position between the sending institution computer 560 and the receiving institution computer 540 can be calculated. Instead of transferring the value of each digital asset back and forth, a net total can be transferred to whichever entity has a net ownership (e.g., based on a settlement period, including a certain group of digital asset transfers).

[0196] As mentioned above with reference to step S520, digital assets can be provided to the recipient node computer 545 in many alternative ways. For example, in some embodiments, instead of providing a single targeted message to the recipient node computer 545, the issuer node computer 565 can distribute the digital assets to several or all of the nodes in the asset transfer network (e.g., all recipient nodes in the network). In such a case, the recipient node computer 545 can be one of several nodes that receive the digital assets. The recipient node computer 545 can identify the purpose of the digital assets as the receiving institution computer 540 based on the enterprise ID included in the digital assets.

[0197] Alternatively, in some embodiments, the management node computer 550 can distribute the digital assets on behalf of the issuer node computer 565. The management node computer 550 can provide the digital assets directly to the recipient node computer 545, or can distribute the digital assets to multiple recipient nodes (as described above). In other embodiments, the management node computer 550 can instead publicly distribute updates to the transaction ledger to one or more nodes. In such a case, the recipient node computer 545 can review the new digital assets recorded in the updated ledger and identify any relevant digital assets (e.g., based on the enterprise ID).

[0198] In other embodiments, neither the issuer node computer 565 nor the management node computer 550 can distribute the digital assets. In fact, the management node computer 550 can continuously update the ledger of transactions, and the recipient node computer 545 can have access to the ledger (e.g., real-time access). In such a case, the recipient node computer 545 can periodically or continuously check the central ledger for relevant transactions (e.g., hosted by the management node computer 550).

[0199] Additionally, as mentioned above, one or more additional nodes (e.g., management nodes, issuer nodes, and / or recipient nodes) can also maintain their own ledgers and extend the ledger based on digital asset transfers. However, in some embodiments, certain entities and nodes may only be able to view a subset of the transactions (or meaningful information associated with a subset of the transactions) rather than the entire ledger. Thus, in some embodiments, the ledger may not be fully public because access can be restricted and filtered based on viewing entities.

[0200] As referenced Figure 1 above, the sending institution computer 560 can interact with the asset transfer network in many ways. Thus, in some embodiments, steps S506 - S520 can be performed in alternative ways. For example, instead of directly contacting the issuer node computer 565, the sending institution computer 560 can communicate with an interaction platform regarding the digital asset.

[0201] In such a case, the sending institution computer 560 can send a transaction request to the interaction platform. The interaction platform can then generate the digital asset (instead of the issuer node computer 565), or the interaction platform can request the generation of the digital asset (e.g., by a node in the asset transfer network). Additionally, the interaction platform (instead of the issuer node computer 565) can generate a digital signature for the digital asset based on the private key of the issuer node computer 565 or the sending institution computer 560. The interaction platform can also perform some of the functions of the management node computer 550, such as providing a second digital signature.

[0202] Next, the interaction platform can provide the digital asset and the corresponding digital signature to the asset transfer network, thereby publishing the transaction. For example, the interaction platform can provide the digital asset and signature to the issuer node computer 565 and / or the management node computer 550. Once the digital asset reaches the asset transfer network, the digital asset can be distributed among the nodes and provided to the recipient node computer 545.

[0203] Embodiments of the present invention have many advantages. For example, the embodiments provide an asset transfer network with improved speed, security, reliability, transparency, and efficiency. General and licensed networks can be well - organized and capable of effective messaging through known paths, which facilitates direct value transfer between senders and receivers regardless of location. Such organization can reduce additional communication and remove the secrecy of various unknown correspondent bank relationships present in decentralized traditional systems.

[0204] Central registration of participating entities, fitness screening, standardized communication, and a universal identifier that uniquely identifies entities can each promote a sense of trust in the network and the participating entities. This trust can be further enhanced knowing that network validators (such as management nodes) can be restricted, known, predefined, and operated by trusted parties. The distributed ledger can instill confidence in each participating entity having the same information regarding the protocols and transfers that have taken place. Similarly, digitally - signed digital assets can be highly trusted because the signature can be verified to confirm that the sending financial institution has performed appropriate transaction confirmation and that the digital asset is being legally transferred.

[0205] Such highly network-trusted and digitally signed digital assets can sufficiently reduce transaction risks to allow a receiving financial institution to make the value of the received digital assets in the recipient's account immediately available, even if the value has not been settled. This means that after a transfer is initiated, the transferred value is almost immediately available. Thus, regardless of when and how settlement occurs, the implementation allows funds to be available much faster than traditional transfer methods (e.g., immediately available vs. 3 - 7 days available).

[0206] The use of a central settlement service entity (such as a central bank) advantageously allows for a centralized settlement process. For example, in some implementations, the sending bank and the receiving bank may each have an account at the central bank. When the sending bank wishes to transfer value to the receiving bank, the value can be transferred between their corresponding accounts at the central bank. The accounts can be at a single central bank location in one country, or the central bank can have multiple locations in different countries (e.g., a global bank). Either way, the central bank can coordinate the transfer of value from the sending bank's account to the receiving bank's account. This provides a more streamlined and transparent process compared to the traditional correspondent banking relationships used in national wire transfers. Instead of transferring between multiple correspondent banks (e.g., three, four, five or more transfer steps between different banks), funds can be settled at the central bank. In addition to simplifying the settlement process, this also advantageously allows each bank to access a global asset transfer network with only one external relationship (e.g., with the central bank). As a result, a particular bank may no longer need to maintain multiple correspondent banking relationships, which traditionally could include twenty or more relationships.

[0207] A computer system that can be used to implement any of the entities or components described herein will now be described. Subsystems in the computer system are interconnected via a system bus. Additional subsystems include a printer, a keyboard, a fixed disk, and a monitor, which can be coupled to a display adapter. Peripheral devices and input / output (I / O) devices can be coupled to an I / O controller and can be connected to the computer system by any number of means known in the art (e.g., a serial port). For example, a computer device can be connected to a wide area network such as the Internet, a mouse input device, or a scanner using a serial port or an external interface. The interconnection via the system bus allows the central processor to communicate with each subsystem and control the execution of instructions from the system memory or the fixed disk and the exchange of information between subsystems. The system memory and / or the fixed disk can embody computer-readable media.

[0208] As described above, the services of the present invention may involve implementing one or more functions, processes, operations, or method steps. In some embodiments, the functions, processes, operations, or method steps may be implemented by executing an instruction set or software code by a suitably programmed computing device, microprocessor, data processor, etc. The instruction set or software code may be stored in a memory or other form of data storage element accessible by the computing device, microprocessor, etc. In other embodiments, the functions, processes, operations, or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.

[0209] Any software component or function described in this application may be implemented as software code executed by a processor using any suitable computer language (such as, for example, Java, C++, or Perl), using, for example, traditional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer-readable medium, such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or a floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium may reside on or inside a single computing device and may exist on or inside different computing devices within a system or network.

[0210] Although some exemplary embodiments have been described in detail and shown in the drawings, it should be understood that such embodiments are illustrative of the invention and not restrictive, and the invention is not limited to the specific arrangements and structures shown and described, as various other modifications may occur to those of ordinary skill in the art.

[0211] As used herein, unless expressly indicated to the contrary, the use of "a", "an", or "the" is intended to mean "at least one".

Claims

1. A method for digital asset transfer, the method comprises: receiving, by a management node computer, a digital asset and a first digital signature for the digital asset from an issuer node computer, the digital asset including a sender identifier of a sender, a recipient identifier of a recipient, and an amount of legal currency paid by the sender to the recipient, wherein the first digital signature is generated by the issuer node computer based on the digital asset and a first private key associated with the issuer node computer, and wherein the first digital signature is generated by the issuer node computer in response to the issuer node computer receiving a transaction request from a sending institution computer holding a first account of the sender; verifying, by the management node computer, the digital asset at least by analyzing the sender identifier of the sender, the amount of legal currency, and the recipient identifier of the recipient; generating, by the management node computer, a second digital signature for the digital asset, the second digital signature being generated based on the digital asset and a second private key associated with the management node computer; generating, by the management node computer, a block of a blockchain, the block including information about the digital asset; providing, by the management node computer, directly or via the issuer node computer, the digital asset to a recipient node computer, wherein the recipient node computer provides the digital asset to a receiving institution computer holding a second account of the recipient; and coordinating, by the management node computer after generating the block, a fund transfer, the fund including the amount of legal currency from the sender to the recipient.

2. The method according to claim 1, further comprises: verifying, by the management node computer, the first digital signature.

3. The method according to claim 1, wherein verifying the first digital signature is performed using a first public key associated with the issuer node computer, the first public key corresponding to the first private key.

4. The method according to claim 3, wherein the first public key is stored at the management node computer, and further comprises: looking up the first public key using the sender identifier before verification.

5. The method according to claim 3, wherein the digital asset further includes the first public key, and further comprises: obtaining the first public key from the digital asset before verification.

6. The method according to claim 1, wherein generating the second digital signature for the digital asset includes signing information of the digital asset with the second private key, and wherein the issuer node computer generates the first digital signature by signing information of the digital asset with the first private key.

7. The method according to claim 1, further comprises: providing, by the management node computer, the second digital signature to the recipient node computer, wherein the recipient node computer verifies the second digital signature using a second public key associated with the management node computer, the second public key corresponding to the second private key.

8. The method according to claim 1, wherein the receiving party node computer receives the second digital signature and verifies that the second digital signature is authentic.

9. The method according to claim 8, wherein, in response to verifying that the second digital signature is authentic, the receiving institution computer credits the account of the receiving party with the amount of fiat currency indicated in the digital asset, even if the amount of fiat currency has not actually been received from the sending party.

10. The method according to claim 1, wherein the fund transfer includes a settlement between the receiving institution computer holding the second account of the receiving party and the sending institution computer holding the first account of the sending party.

11. The method according to claim 1, wherein the blockchain is updated only after all transactions in the block have been verified by nodes in the asset transfer network, and the transactions in the block are verified using a simplified Byzantine fault tolerance process.

12. A management node computer, comprising: a processor; and a computer-readable medium including code executable by the processor for implementing the method according to any one of claims 1 to 11.

13. A method for digital asset transfer, the method comprising: receiving, by an issuer node computer, from a sending institution computer holding a first account of a sending party, a request to transfer an amount of fiat currency from the sending party to a receiving party; generating, by the issuer node computer, a digital asset including a sender identifier of the sending party, a receiver identifier of the receiving party, and the amount of fiat currency paid by the sending party to the receiving party, generating, by the issuer node computer in response to the transfer request, a first digital signature for the digital asset, the first digital signature being generated based on the digital asset and a first private key associated with the issuer node computer; and sending, by the issuer node computer, the digital asset and the first digital signature for the digital asset to a management node computer, wherein the management node computer verifies the digital asset at least by analyzing the sender identifier of the sending party, the amount of fiat currency, and the receiver identifier of the receiving party, generates a second digital signature based on the digital asset and a second private key associated with the management node computer, provides the digital asset directly or via the issuer node computer to a receiving party node computer, wherein the receiving party node computer provides the digital asset to a receiving institution computer holding a second account of the receiving party, and the management node computer generates a block of the blockchain including information about the digital asset and coordinates the fund transfer, the fund including the amount of fiat currency from the sending party to the receiving party.

14. The method according to claim 13, wherein the request includes the sender identifier of the sender and the recipient identifier of the recipient, and wherein the recipient node computer receives the second digital signature and verifies that the second digital signature is authentic.

15. The method according to claim 14, further comprising: receiving, by the issuer node computer, the second digital signature from the management node computer; and providing, by the issuer node computer, the second digital signature to the recipient node computer.

16. The method according to claim 13, wherein generating the first digital signature for the digital asset includes signing the information of the digital asset with the first private key, and wherein the management node computer generates the second digital signature by signing the information of the digital asset with the second private key, and wherein the management node computer verifies the first digital signature with a first public key associated with the issuer node computer, the first public key corresponding to the first private key.

17. An issuer node computer, comprising: a processor; and a computer-readable medium including code executable by the processor for implementing the method according to any one of claims 13 to 16.

Images