Network topology

Abstract

A network topology is provided that includes multiple data centers for building blockchain blocks. The data centers can process different subgroups of blocks and then update each other with information about new blocks. Additionally, some data centers may protect sensitive block body information and only share block headers.

Description

[0001] This divisional application of the invention application is a divisional application of the invention patent application with international application number PCT / US2017 / 046364, international filing date August 10, 2017, and entering the Chinese national phase with application number 201780054059.0 and title "Network Topology".

[0002] Cross - reference to related applications

[0003] This application is an international patent application claiming the benefit of the filing date of U.S. Provisional Application No. 62 / 490,487, filed on April 26, 2017, the entire content of which is incorporated herein by reference for all purposes.

[0004] This application is also a partial continuation application of U.S. Patent Application No. 15 / 283,930, filed on October 3, 2016, which claims the benefit of U.S. Provisional Patent Application No. 62 / 294,825, filed on February 12, 2016, the entire content of which is incorporated herein by reference for all purposes. Background

[0005] There are many networks and applications for transferring information and assets. For example, there are those designed to transfer access credentials, event tickets, property rights, currency, game points, mobile phone minutes, digital media, etc. Additionally, there are typically multiple networks for transferring the same type of asset. For example, if someone wishes to transfer an event ticket to a friend, they can choose one of several ticket - transfer networks and applications.

[0006] Unifying and simplifying many types of transfer networks can be beneficial. For example, if all asset - transfer networks for transferring mobile phone minutes are combined into a single global network, it can simplify the transfer process. Participants may only have one application configured for one network. Additionally, it can simplify record - keeping, as one network can track where the assets have moved.

[0007] However, new problems can arise when unifying transfer networks. For example, coordinating all transfers can be a huge task and may be overly burdensome for network administrators. Additionally, network administrators may be able to view the details of each transfer. This can limit the privacy of network participants and may give network administrators too much power.

[0008] Embodiments of the present invention solve these and other problems, either individually or jointly. Summary of the Invention

[0009] One embodiment of the present invention relates to a method. The method includes creating, by a first data center computer, a first block of a first blockchain. The first block includes a first block header and a first block body. The method further includes sending a message to a second data center computer, the message indicating that the first block has been created for the first blockchain. The message includes the first block header, but does not include the first block body. The second data center computer adds the first block header to a second blockchain and does not add the first block body to the second blockchain.

[0010] Another embodiment of the present invention relates to a first data center computer configured to perform the above method.

[0011] Another embodiment of the present invention relates to a method that includes creating, by a first data center computer, a first block for a first blockchain. The first block includes a first block header and a first block body. The method further includes sending a first message to a second data center computer, the first message indicating that the first block has been created for the first blockchain. The message includes the first block header, but does not include the first block body. The method further includes receiving, by the second data center computer, the first message indicating that the first block has been created for the first blockchain. The second data center computer may also create a second block for a second blockchain. The second block includes a second block header that is the same as the first block header, and the second block does not include the first block body.

[0012] Another embodiment of the present invention relates to a system that includes a first data center computer and a second data center computer configured to perform the above method.

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

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

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

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

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

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

[0019] Figure 6 An example of an asset transfer network with additional details is shown.

[0020] Figure 7 A diagram showing an example network topology that can be used with embodiments of the present invention.

[0021] Figure 8 A flowchart showing a method of processing digital assets in an asset conversion network having multiple data centers, illustrated according to an embodiment of the present invention.

[0022] Figure 9 A diagram of an asset transfer network with different data center groups, according to an embodiment of the present invention.

[0023] Figure 10 A flowchart showing a method of distributing ledger updates to different groups of data centers, according to an embodiment of the present invention.

[0024] Figure 11 A diagram of a partially-matched blockchain ledger, according to an embodiment of the present invention. DETAILED DESCRIPTION

[0025] Embodiments of the present invention relate to systems and methods for processing data elements using multiple data centers. By using multiple data centers and load balancing techniques, the processing burden can be distributed and transfer efficiency can be improved.

[0026] In addition, each data center can maintain a separate network record, which can be in the form of a blockchain ledger. The data centers can update each other with the corresponding data elements they have processed and / or the blocks they have created. Thus, even though both the data element submission process and the record keeping process are distributed processes, the data centers can synchronize their records and effectively act as a single extensive network.

[0027] Separating network management between multiple data centers can enable the use of special local configurations, rules, and data restrictions. For example, in some embodiments, certain data centers may not share meaningful data element information or block bodies with other data centers, but can still share record identifiers (e.g., block headers) or other non-descriptive data element tags with other data centers (e.g., as record updates). Thus, sensitive record information can be contained and protected, thereby improving the privacy of the participants using the data centers.

[0028] Embodiments of the present invention may be applied to transfer values in an asset transfer network. 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 may 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).

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

[0030] In some embodiments, digital assets associated with a value transfer may be digitally signed by the sending entity and / or the administrative 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.

[0031] Some embodiments include a central settlement entity. The central settlement entity may allow for the efficient settlement of value from a sending account at a sending financial institution to a receiving account at a receiving financial institution. The central settlement entity may include a central financial institution having multiple locations and multiple accounts. The central settlement entity may have at least one location and one account in each country in which it operates. As a result, a first financial institution may have an account (e.g., a settlement account) with the central settlement entity in a first country, and a second financial entity may have an account with the central settlement entity in a second country. Thus, in some embodiments, international transfers are made by transferring from the first financial institution to the central settlement entity and then from the central settlement entity to the second financial institution. This means that in some embodiments, each financial institution participating in the asset transfer network may have only one external account with the central settlement entity (e.g., instead of multiple corresponding bank relationships). In some embodiments, the central settlement entity has only one location rather than having different branches in different countries. In such a case, financial institutions in other countries may still maintain corresponding accounts with the central settlement entity (e.g., Nostro accounts). Additionally, in some embodiments, each financial institution may have different accounts in the central settlement entity for different currencies (e.g., 1, 5, 10, 20, or 100 accounts, each for a different type of currency). Thus, financial institutions may settle transactions with other financial institutions using the most appropriate currency or a currency that both financial institutions have.

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

[0033] 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. A distributed ledger can instill confidence that each participating entity has the same information about the protocols and transfers that have taken place. Similarly, a digital asset with a digital signature can be highly trusted because the signature can be verified to confirm that the digital asset is being legally transferred.

[0034] Advanced network trust and digital assets with digital signatures may allow the receiving financial institution to make the value of the received digital asset immediately available in the receiving account, even if the value has not yet been settled. This means that the transferred value can be made almost immediately available.

[0035] In an embodiment of the present invention, to initiate an asset transfer, a user (or an institution representing the user) may command an issuer node in an 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 (e.g., a central administrator of the network). Subsequently, the issuer node may provide the digital asset to a recipient node (e.g., directly or via network-wide distribution). The recipient node may then provide the digital asset to the recipient (or an institution representing the recipient).

[0036] 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.

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

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

[0039] Accordingly, embodiments of the present invention provide an asset transfer platform that can directly and predictably exchange value (e.g., value represented by account data, cryptographically signed digital assets, and supporting instructions). The platform also provides for the adaptive screening of participants (e.g., banks and their customers). In some embodiments, screening information about the user is obtained from a bank or other service provider. Additionally, embodiments use a smart contract that can automatically enforce the settlement of digital assets according to certain criteria (e.g., enforce settlement 24 hours after the digital asset has been distributed in the network). For example, during registration, a financial institution agrees to establish a smart contract when a digital asset is requested or generated.

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

[0041] "Data element" may refer to digital information. For example, a data element may be information that exists in binary format. In some embodiments, a data element may contain information about anything describable in a record. For example, a data element may contain any suitable type of digital information, such as medical data, biometric data, ownership data, academic credentials, product data, etc. A data element may also be used to describe an update, change, or request. For example, a data element may contain digital information about: a change in a person's medical status, an update to the number of sick leave days an employee has used, a request to verify or approve a value transfer, or a commitment to transfer value from one entity to another. An instance of a data element is a digital asset.

[0042] "Digital asset" may refer to digital content associated with a value. In some cases, a digital asset may also indicate a transfer of value. For example, a digital asset may contain data indicating the transfer of a monetary value (e.g., fiat currency or cryptocurrency). In other embodiments, a digital asset may 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).

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

[0044] A digital asset may also contain information about one or more digital asset attributes. For example, a digital asset may contain useful information for transferring value from one entity or account to another entity or account. A digital asset may also contain remittance information (e.g., information identifying the sending entity). In some embodiments, a digital asset may contain 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 may have enough information to proceed with a settlement transaction for the indicated value.

[0045] In some embodiments, the digital asset may further include digital signatures and / or encryption keys for authentication and entity identification. For example, the digital asset may include the digital signature and public key of the issuer node, as well as the public key of the management node.

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

[0047] The term "node" may refer to a connection point. In some embodiments, a node may be a physical electronic device capable of creating, receiving, or transmitting data. In other embodiments, a node may be a software module on a computing device, a software module connection point in a communication network. In some embodiments, a node may be a computing device within an asset transfer network. A node is capable of minting assets, transferring assets, receiving assets, authenticating assets, maintaining a ledger of transactions, and / or performing any other suitable functions. Different types of nodes are capable of performing different sets of functions in the asset transfer network. In some embodiments, a node may 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.

[0048] "Record" may refer to evidence of a data element. A digital record may be an electronic document of a data element. A record may include a record identifier and record information. For example, the record information may include data elements (such as digital assets) and / or information about the data elements (such as digital signatures associated with the digital assets). The record identifier may be a number, a title, or other value used to identify the record. The record identifier may not describe, in which case it may not provide any meaningful information about the record information in the record. Examples of records include medical records, academic records, transaction records in a transaction ledger, etc. Another example of a record is a block in a blockchain. A single block may be a single record, and a blockchain may be a series of records. A blockchain header is an example of a record identifier, and a blockchain body is an example of record information.

[0049] The term "transaction ledger" can refer to a compilation of data from previous transactions. The transaction ledger 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 transaction ledger can be in the form of an electronic ledger (e.g., a blockchain), where the data already stored in the electronic ledger is immutable. In some embodiments, each node in the asset transfer network can store its own copy of the transaction ledger. In other embodiments, only some nodes store their own copies of the transaction ledger. In additional embodiments, some nodes may have a restricted view of the transaction ledger. For example, some nodes may only be able to view and / or verify transactions for which they are a party.

[0050] The transaction ledger can include transaction records that are digitally signed (e.g., with a private key) 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.

[0051] In some embodiments, the transaction ledger 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 to one or more entities.

[0052] As used herein, "blockchain" can include a series of blocks. Each block in the blockchain can contain 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.

[0053] A block can contain a "block body" and a "block header". The block header can be a block identifier or a label. The block header can be used to identify the block, and the block headers can be used to link the blocks together. The block body can contain the information stored in the block. For example, the record information stored in the block can be regarded as the block body. The block body can also contain other data, such as a reference to the previous block (e.g., the previous block header), a timestamp, a random number, a hash of the record information (e.g., transaction data), and / or any other suitable information. In some embodiments, the block body can be all the block data other than the block header. The block header can be created based on the block body. For example, some or all of the block body information can be used as the input to a hash algorithm, encrypted, or otherwise manipulated to create the block header. When generating the current block header, the previous block can be linked to the current block by using the previous block header as the input.

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

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

[0056] The term "digital signature" can refer to an electronic signature for a message. The digital signature can be a numerical value, an alphanumeric value, or any other type of data that includes a graphical indication. The digital signature can be a unique value generated from the message and the private key using a cryptographic algorithm. In some embodiments, a verification algorithm using the public key can be used to verify the signature.

[0057] The term "zero - knowledge proof" or "zero - knowledge protocol" can refer to a method of proving information without actually conveying the information itself. In a zero - knowledge protocol, it is verifiable without revealing the secret information. For more information on zero - knowledge proofs, see:

[0058] J. Camenisch and M. Stadler, Proof Systems for General Statements about Discrete Logarithms. Technical Report TR260, Institute of Theoretical Computer Science, ETH Zürich, March 1997.

[0059] In some embodiments, the verification of a fuzzy or partially fuzzy transaction ledger can employ a zero - knowledge protocol.

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

[0061] Figure 1 System 100, which includes a number of components, is shown. The system includes a user computer 110 operated by a user (not shown). The user computer 110 can communicate with a sending - agency computer 160, which can 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 can communicate with a receiving - agency computer 140, which can be associated with a recipient - node computer 145. The system further includes an interaction 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 can all be operably communicable with each other via any suitable communication channel or communication network. Suitable communication networks can be any one and / or combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an operations - on - the - net (OMNI) as a node on the Internet; a secure custom connection; a wide area network (WAN); a wireless network (e.g., using protocols such as but not limited to Wireless Application Protocol (WAP), i - mode, etc.).

[0062] Messages between computers, networks, and devices can 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., ISO8583), and / or the like.

[0063] System 100 can be used to process, approve, and record any suitable type of data element. Individuals, organizations, and any other appropriate entities can submit requests to process and approve data elements and can create and update records for the data elements.

[0064] For illustration, system 100 is primarily described as a system that allows individuals, businesses, and other entities to transfer value to each other. System 100 can use "push" transaction messages that are digitally signed and verified by a trusted central entity. Transactions can also be recorded in a trusted ledger (e.g., a blockchain). Thus, push messages can be trusted and relied upon. Push messages can be used as an alternative to typical authorization request messages, authorization response messages, and / or settlement messages.

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

[0066] As an example, system 100 can be used as a transaction system for providing payments. For purposes of illustration, the entire system 100 can be referred to as a transaction system, and the central network of nodes (e.g., one or more recipient 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.

[0067] 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 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).

[0068] For purposes of description, 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.

[0069] To participate in system 100, a user can register. For example, the user can register (via user computer 110 and / or an interface provided by sending institution computer 160) to an asset transfer network. The asset transfer network for the registration service can be provided by interaction platform 154 and / or management node computer 150. An asset transfer network administrator (such as 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 an enterprise ID on behalf of the user from interaction platform 154.

[0070] 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 (such as providing a payment). Examples of sending institutions can be issuers, which generally can refer to commercial entities (such as banks) that issue and maintain user accounts (such as bank accounts).

[0071] The user account at sending institution computer 160 can be associated with various user information. For example, a user transaction account can be associated with: first name, last name, government-issued identification number (such as 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.

[0072] Sending institution computer 160 can also register with the asset transfer network (such as via management node computer 150 or interaction platform 154) in order to interact with the network. As a result, sending institution computer 160 can also receive a unique enterprise ID.

[0073] In some embodiments, 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, 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 (such as an HSM at issuer node computer 165 or management node computer 150).

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

[0075] 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 may 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 scenario, the sending institution computer 160 may command the interaction platform 154 to initiate a value transfer from a user account to a resource provider account. The interaction platform 154 may 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 may then be distributed within the asset transfer network and recorded.

[0076] In an alternative instance, 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, instead of the interaction platform 154, may generate a digital asset and digitally sign the digital asset 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 scenario, the sending institution computer 160 may command the issuer node computer 165 to initiate a value transfer from a user account to a 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 recipient node computer 145. The recipient node computer 145 may provide the digital asset to the receiving institution computer 140.

[0077] 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 (e.g., the issuer node computer 165 may be provided by another entity, but may be used by the sending institution computer 160 for transactions). In any case, there are ways for the sending institution computer 160 to access the network and initiate a transaction.

[0078] The interaction platform 154 may include one or more service computers. As mentioned above, the interaction platform 154 may facilitate interactions 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).

[0079] 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, maintaining transaction records, etc. 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.

[0080] 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 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 transactions.

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

[0082] As described above, the interaction platform 154 may 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 may instead be performed by the interaction platform 154. Similarly, some or all of the functions regarding the interaction platform 154 may instead be performed by the management node computer 150. Additionally, the interaction platform 154 and the management node computer 150 may be combined into a single entity. In some embodiments, the management node computer 150 may be a node associated with the interaction platform 154 and participating in the asset transfer network on behalf of the interaction platform 154 (such as in a manner similar to how the issuer node computer 165 is associated with the sending institution computer 160).

[0083] 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 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 trading repository 156, and / or the risk management computer 157.

[0084] In some embodiments, the management entity can also operate an asset transfer network. For example, the management entity can provide the issuer node computer 165, the management node computer 150, and / or the recipient node computer 145. However, in other embodiments, a third party entity can provide the asset transfer network (e.g., the management entity can outsource control of the asset transfer network). Even in such a case, the management entity can still operate one or more nodes (e.g., 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.

[0085] In some embodiments, the management entity can be a transaction processing entity (e.g., one or more transaction processing computers). As an example, a 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, a transaction processing computer can include a server coupled to a network interface (e.g., via an external communication interface) and an information database. A 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) that processes authorization requests and the BaseII system that performs clearing and settlement services. A transaction processing computer can use any suitable wired or wireless network, including the Internet.

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

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

[0088] Figure 2 An example of the management node computer 150 in accordance with 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.

[0089] The computer-readable medium 150E may include a registration module 150F, a verification module 150G, a risk module 150H, a confirmation module 150J, a signature module 150K, an update ledger 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, wherein the first digital signature is generated using a first private key associated with the issuer node computer, and wherein the digital asset indicates a transfer of value from a sender to a receiver; confirming the digital asset; generating 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; providing the second digital signature to the issuer node computer, wherein 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.

[0090] The computer-readable medium 150E may further include code executable by the processor 150A for implementing a method including the operations of: processing, by a first data center computer, a first digital asset that indicates a transfer of value from a sender to a recipient; recording the first digital asset in a first database; and sending a message indicating that the first digital asset has been recorded to a second data center computer, wherein the second data center computer updates a second database based on the message.

[0091] The computer-readable medium 150E may further include code executable by the processor 150A for implementing a method including the operations of: processing, by a first data center computer, a first data element; creating, by the first data center computer, a first record of the first data element in a first database; and sending, by the first data center computer, a message indicating that the first record has been created to a second data center computer, wherein the second data center computer updates a second database based on the message.

[0092] The computer-readable medium 150E may further include code executable by the processor 150A for implementing a method including the operations of: creating, by a first data center computer, a first block of a first blockchain, the first block including a first block header and a first block body; and sending, by the first data center computer, a message indicating that the first block has been created for the first blockchain to a second data center computer, the message including the first block header but not including the first block body, wherein the second data center computer adds the first block header to a second blockchain and wherein the second data center computer does not add the first block body to the second blockchain.

[0093] As mentioned 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.

[0094] 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 to join the system from an entity. 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 risk profiles for registering financial institutions 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 country of the bank, and whether the bank has provided collateral. The management node computer 150 may assign a risk level and activity restrictions based on the risk profile. Activity restrictions for various types of entities may include, for example, maximum transaction threshold limits and / or speed limits, such as limits on the number or total digital asset value of digital assets that can be generated within a certain time period (such as one day, one week, or one month).

[0095] The registration module 150F may contain 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.

[0096] When users and enterprises register to participate in the asset transfer network, their information (such as name, address, phone number, enterprise profile of the enterprise, etc.) may 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 may 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.

[0097] The registration module 150F may also contain 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 may generate a key pair for a bank or user at the time of registration. In some embodiments, the management node computer 150 may provide a digital certificate to the registered entity, the digital certificate certifying that the entity is authenticated by the management node computer 150, and the digital certificate linking the entity to the public key. In some embodiments, the public key may be used as the enterprise ID.

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

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

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

[0101] The risk module 150H may also contain instructions to set limits on entities that are exhibiting risky behavior or entities involved in settlement failures. For example, if a financial institution is exceeding spending limits, the management node computer 150 may temporarily block the generation of digital assets by the financial institution.

[0102] 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 the 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 a financial institution (or other service provider) is compliant with rules and protocols. For example, a financial institution may be required to have know-your-customer 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.

[0103] 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 a digital asset using the management node private key. The digital signature of the management node computer may be used to indicate the authenticity of the digital asset and may 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 may 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 the settlement process. In some embodiments, the management node computer 150 may enforce settlement between the sending institution account and the receiving institution account at the central bank.

[0104] In some embodiments, the management node computer 150 may include or be associated with a hardware security module ( Figure 2 shown as the key database 150P in FIG. 2). 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.

[0105] The update ledger module 150L may include code that causes the processor 150A to maintain a ledger of transactions. For example, the update ledger module 150L may contain logic that causes the processor 150A to record information regarding a digital asset along with the record of previous digital assets. For example, the management node computer 150 may record a digital asset once the digital asset 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).

[0106] In some embodiments, the update ledger module 150L may contain 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 1 second, 5 seconds, 10 seconds, 30 seconds, 1 minute, ten minutes, 1 hour, etc.), a new block containing 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 nonce, a random number, and / or any other suitable information.

[0107] 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 contain information regarding transactions to be settled. In some embodiments, one or more of these databases may alternatively be implemented by the transaction repository 156.

[0108] In an embodiment 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, for example, 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.

[0109] The updated ledger module 150L may also 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) so that the other nodes can update their own ledgers. The management node computer 150 may additionally or alternatively distribute information about ledger updates (such as new transaction blocks).

[0110] In some embodiments, the issuer nodes and recipient nodes may not maintain their own ledgers and may instead refer to 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 light 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 (such as updates may be sent every 10 seconds, 1 minute, 5 minutes, etc.). As a result, other nodes can know about new digital assets immediately or shortly after the digital assets are minted.

[0111] The ledger of 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 instead 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.

[0112] 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 full ledger. Instead, the management node computer 150 may only allow each node to view the transactions in the ledger that are associated with it (such as based on enterprise ID, encryption key, transaction ID, etc.). For example, the management node computer 150 may send a trimmed copy of the ledger to each node, or may block portions of the ledger while the central ledger is being accessed by the nodes. In some embodiments, information about certain recorded transactions may be obfuscated (such as encrypted) in the body of the block, or removed from the block, but all block headers may still be provided. Thus, the entire blockchain (which can be linked by hashed headers) may still be shown as complete, but the transaction details in the blocks may be removed or obfuscated.

[0113] In some embodiments, a one-time use address (e.g., a one-time use enterprise ID or other one-time use identifier) can be used for the payee and / or payer. As a result, users and / or resource providers cannot 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 cannot be identified based on the information in the transactions. Instead, the identities and accounts of the users can remain anonymous. However, the users and resources can maintain information about the one-time use addresses and identify which ones have been used, thus enabling the identification of the transactions in the ledger of which they are a party.

[0114] 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 users and / or resource providers in the digital asset can be encrypted with the public key associated with the users and / or resource providers. As a result, only the users and / or resource providers can decrypt and view the identifying (or other) information in the digital asset contained in the ledger of which they are a party.

[0115] In some embodiments, zero-knowledge proofs can be used to verify the authenticity of the filtered transaction ledger. When the value and / or identifying information of the digital asset in the transaction can be hidden with a password, zero-knowledge proofs can be used to confirm the integrity of the content. For example, an external party can use a zero-knowledge proof to verify that the claimed value of the digital asset is genuine (not deceptive), but the external party 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 (e.g., due to the federated nature of the network).

[0116] The updated ledger module 150L can also include instructions for transferring information about new digital assets to the end users (e.g., 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 can 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 can alternatively be sent to a service provider (e.g., sending institution computer 160 and / or receiving institution computer 140), which in turn can notify the end user.

[0117] As mentioned above, in some embodiments, the management node computer 150 (or the interaction platform 154) may perform one or more functions on behalf of the issuer node computer 165. For example, instead of the issuer node computer 165, the management node computer 150 may generate digital assets 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 modules that cause the processor 150A to create digital assets. For example, the digital asset module 150M may contain logic that causes the processor 150A to generate digital assets that include information associated with transferring value from a user account to a recipient account.

[0118] Additionally, in some embodiments, the management node computer 150 may generate digital signatures 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 a digital asset after the digital asset is generated.

[0119] 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 of) 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 payment instructions from the sending institution computer 160 via the interaction platform 154.

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

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

[0122] 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.

[0123] 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 updated ledger module 165K, and any other suitable software modules. The computer-readable medium 165F may also include code executable by the processor 165A for implementing a method that includes: receiving a request to transfer value from a sender associated with a sender identifier to a recipient associated with a recipient identifier; generating a digital asset indicating that the value is being transferred to the recipient; 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 recipient node computer associated with the recipient, wherein the management node computer records the digital asset in a database and coordinates the transaction associated with the digital asset.

[0124] 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., via the interaction platform 154).

[0125] 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 a digital asset that contains information for transferring value from a user account to a recipient account.

[0126] The signature module 165G may include code that enables the processor 165A to create digital signatures. For example, the signature module 165G may contain logic that enables the 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 (e.g., other nodes) can then use the corresponding public key to verify the digital signature and thus verify the authenticity of the digital asset.

[0127] 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 (e.g., private keys) 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.

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

[0129] The approval module 165H can include code that causes the processor 165A to obtain approval for the digital asset. For example, the approval module 165H can contain logic that causes the 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 can then verify the digital signature of the issuer node computer, confirm the digital asset, and generate a second digital signature for the digital asset.

[0130] The distribution module 165J can include code that causes the processor 165A to distribute the digital asset. For example, the distribution module 165J can contain logic that causes the 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 can operate an appropriate routing table. For example, the recipient node computer 145 can be identified based on an enterprise identifier, a public key, a bank identification number, and / or any other suitable identifier in the digital asset.

[0131] The update ledger module 165K can include code that causes the processor 165A to record information related to the creation and / or distribution of the digital asset used for a transaction. For example, the update ledger module 165K can contain logic that causes the processor 165A to record information by updating the ledger record of the transaction based on the new digital asset or other transaction. This ledger can be stored at the ledger database 165C. The update ledger module 165K can include instructions for adding a block to the blockchain, the new block containing information about one or more transactions.

[0132] In some embodiments, the issuer node computer 165 can view the ledger maintained by the management node computer 150 or by a third-party ledger manager instead of maintaining its own ledger.

[0133] In some embodiments, the issuer node computer 165 may only be able to view a subset of the transactions occurring within the asset transfer network. For example, the issuer node computer 165 may have a filtered view of a full ledger (e.g., a blockchain) maintained by the management node computer 150. The issuer node computer 165 is able to view the transaction records of transactions where the issuer node computer 165 or the sending institution computer 160 is a party. In some embodiments, the issuer node computer 165 may view the total blockchain, but the block headers of each block in the issuer node computer 165 may not be able to view some or all of the record information within the block body (e.g., transactions not associated with the issuer node computer 165, or transactions conducted in different countries / regions).

[0134] This filtered ledger view can be achieved through several possible implementations. In one instance, the issuer node computer 165 may be a light node that only receives information about relevant transactions. In one implementation, the issuer node computer 165 only receives all block headers, but only receives the corresponding block bodies of associated transactions. If the issuer node computer 165 constructs its own copy of the transaction ledger, it can only receive the block headers of certain blocks. If the issuer node computer 165 does not construct its own ledger but accesses a central ledger (e.g., maintained by the management node computer 150), the central ledger can be filtered when the issuer node computer 165 is accessing it, such that the issuer node computer 165 can only see the block headers of certain blocks.

[0135] In some embodiments, the issuer node computer 165 may obscure or remove parts of the ledger when presented to the sending institution computer 160. For example, the issuer node computer 165 may access the entire ledger, but when the sending institution computer 160 views the ledger, the block bodies of certain blocks may be removed (while also optionally displaying the block headers).

[0136] Additional techniques for providing a filtered ledger view are described above. For example, a digital asset may contain less information about the providing entity (e.g., user, sending bank, and / or sending node) such that the recipient can receive value from the digital asset without exposing personal sender information.

[0137] In some embodiments, the functionality of one or more of the above-described issuer node computers 165 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 do this instead of forwarding the transaction instruction 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 capable of storing the keys of the issuer node computer in the HSM and is capable of generating digital signatures for digital assets on behalf of the issuer node computer 165.

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

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

[0140] The recipient node computer 145 may 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 may be associated with an enterprise ID.

[0141] The recipient node computer 145 is capable of receiving digital assets sent by the issuer node computer 165 and / or the management node computer 150. In some embodiments, the digital assets may be broadcast to several or all nodes, and the recipient node computer 145 may 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).

[0142] The recipient node computer 145 may also confirm that the digital assets are authentic. For example, the recipient node computer 145 may verify one or more digital signatures associated with the digital assets. The digital signatures may be verified using the public keys associated with the signing entities (e.g., the sending institution computer 160, the issuer node computer 165, and / or the management node computer 150).

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

[0144] In some embodiments, the recipient node computer 145 may only be able to view a subset of the transactions that occur 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 where the recipient node computer 145 or the receiving institution computer 140 is a party. For example, the recipient node computer 145 may be a light node that only receives information about relevant transactions. In some embodiments, the recipient node computer 145 may view the total blockchain, but the recipient node computer 145 may not be able to view some or all of the record information within the block body for each block. For example, the block body containing transactions not associated with the recipient node computer 145 or transactions conducted in different countries may be removed.

[0145] In some embodiments, if the recipient node computer 145 constructs its own copy of the transaction ledger, the administrative node computer 150 may only send the block headers of certain blocks when the administrative node computer 150 provides ledger updates to the recipient node computer 145. Alternatively, if the recipient node computer 145 does not construct its own ledger but instead accesses a central ledger (e.g., maintained by the administrative node computer 150), the central ledger may be filtered when the recipient node computer 145 accesses it such that the recipient node computer 145 can only see the block headers of certain blocks (e.g., blocks containing digital assets associated with the recipient node computer 145).

[0146] In some embodiments, the recipient node computer 145 may remove ledger information while the receiving institution computer 140 is viewing the ledger. For example, the recipient node computer 145 may obfuscate or reduce the ledger (e.g., by encrypting or removing the transaction details and / or block body of certain transactions but still showing the block headers), which would filter the receiving institution computer's view of the ledger.

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

[0148] The receiving institution computer 140 can store value and receive value (e.g., receive payments) on behalf of the resource provider computer 130. Examples of receiving institutions can 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 can perform the functions of both an issuer and an acquirer. Some embodiments can cover such single-entity issuer-acquirers.

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

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

[0151] The resource provider computer 130 can be associated with a resource provider, which can 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 transactions and is capable of selling goods or services or providing access to goods or services.

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

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

[0154] In some embodiments, the resource provider computer 130 may establish relationships with multiple institutions (e.g., a receiving institution and a sending institution). The resource provider computer 130 may register with the asset transfer network through each entity and may be associated with multiple enterprise IDs. For example, a first enterprise ID may represent the resource provider computer 130 when interacting through the receiving institution, and a second enterprise ID may represent the resource provider computer 130 when interacting with the network through the sending institution. In some embodiments, different enterprise IDs may be assigned to the resource provider computer 130 for transactions in different types of currency (e.g., creating digital assets) (e.g., a first enterprise ID for US dollars and a second enterprise ID for British pounds). The embodiments allow users and any other suitable entities to obtain multiple enterprise IDs in a similar manner.

[0155] The foreign exchange trading application interface 152 may provide information regarding foreign exchange rates. For example, prior to 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 interaction platform 154, the management node computer 150, or alternatively by a management entity (e.g., a payment processing entity).

[0156] The settlement service computer 155 (which may comprise one or more service computers) is able to provide a settlement service. For example, a digital asset may act as a guarantee for a payment or an IOU (e.g., proof of a potential payment), but the actual transfer of funds may not actually occur when the digital asset is provided. Accordingly, after sending the 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 (e.g., by transferring value between corresponding settlement accounts at a central clearing bank). By interacting with a central settlement account service (e.g., 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 interaction platform 154, or a management entity. In some embodiments, the settlement service computer 155 itself may be operated by the interaction platform 154 or alternatively by a management entity (e.g., a payment processing entity).

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

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

[0159] In some embodiments, the system 100 can include one or more asset audit nodes (not shown) that are capable of auditing the network. For example, the asset audit nodes can 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 can be operated by the same management entity as the interaction platform 154 and / or the management node computer 150.

[0160] 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.

[0161] In Figure 4 an example of the asset transfer network is shown. In some embodiments, as Figure 4 shown, several nodes can provide and receive 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 can actually broadcast digital asset information to some or all of the nodes in the network. One or more management nodes can maintain a ledger of digital assets that have been transferred between the nodes.

[0162] In some embodiments, the asset transfer network can be a blockchain network. For example, the ledger can take the form of a blockchain. Each block in the blockchain can contain information about one or more transactions (such as digital assets). The blockchain ledger cannot be changed without detection. For example, each block can contain a data header that contains 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 an attempt to reassign digital assets to an inappropriate entity. The block header and the block body containing the transaction information (e.g., and any other suitable information) can together constitute a block.

[0163] As mentioned above, a blockchain can be a distributed database that maintains a growing list of digital records, thus preventing tampering and revision. A blockchain can contain multiple interacting record blocks. Each block in the blockchain can also contain a timestamp and a link to the previous block. For example, each block can contain or be appended with the hash of the previous block. In other words, the transaction records in the blockchain can be stored as a series of "blocks" or permanent files containing records of several transactions that occurred within a given time period. After a block is completed and verified, the block can be appended to the blockchain by appropriate nodes. In an embodiment of the present invention, the blockchain can be distributed, and a copy of the blockchain can be maintained at each node in the verification network. Any node in the verification network can then use the blockchain to verify transactions. The security of the blockchain can be obtained using a cryptographic scheme.

[0164] 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 from a trusted central party may be required to participate in the asset transfer network. As explained above, the management node computer 150 is capable of registering entities into the network. Therefore, the management node computer 150 is capable of deciding which parties participate and setting the rules and protocols for participating in the network. The management node computer 150 is also capable of restricting entities as needed (e.g., restricting or blocking a financial institution due to bad behavior).

[0165] Entities that can authenticate the network (e.g., register 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.

[0166] 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 substantially an outsourced record-keeping system and can only be accessed and / or modified by the transaction processor.

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

[0168] 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, e.g., 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, e.g., an email address, a phone number, an Internet Protocol (IP) address, or a Uniform Resource Locator (URL). In some embodiments, the request or response can include a mix of different message types, e.g., both an email message and an SMS message.

[0169] 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 can be identified based on the unique enterprise ID. In the following example, 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.).

[0170] 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.

[0171] In step S502, the user (e.g., via user computer 510) can contact the sending institution computer 560 to request that a payment be sent to the resource provider computer 530. The user computer 510 can provide any suitable information about the payment, such as the amount and the type of recipient currency, 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.

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

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

[0174] The foreign exchange trading application interface or the interaction 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 of 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.

[0175] Accordingly, 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.

[0176] For example, the user may wish to provide 1000 British pounds to the resource provider. The exchange rate can be 1 British pound to 1.33 US dollars. Therefore, 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. Therefore, it can be determined that the user will be charged 1345 US dollars to provide 1000 British pounds.

[0177] 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 fee and the exchange rate in order to determine the amount that the resource provider will receive.

[0178] 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 does not exceed speed or amount thresholds for the user 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.

[0179] 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 can include information for providing payment to the resource provider, such as information about the original currency, target currency, amount, fees and exchange rates, resource provider enterprise ID, user enterprise ID, and sending institution computer 560 enterprise ID, as well as any other suitable information.

[0180] 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.

[0181] In step S508, the issuer node computer 565 can generate a digital asset for the requested transaction. The digital asset can include any suitable information for transferring value being transferred from the user account to the resource provider account (e.g., remittance information). For example, the digital asset can include a digital asset identifier, original currency type, destination currency type, sending currency amount, fees and exchange rates, destination currency amount, 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), issuer node computer 565 enterprise ID and / or public key, recipient node computer 545 enterprise ID and / or public key, invoice number and invoice information, purchase order number, timestamp, and any other suitable information. The digital asset identifier can be an identifier uniquely identifying the digital asset generated by the issuer node computer 565. For example, the digital asset identifier can be an alphanumeric string or a scannable image (e.g., QR code). The transaction identifier can be used as the digital asset identifier.

[0182] The issuer node computer 565 can also generate a digital signature for the digital asset, which indicates that the digital asset is authentically created by the issuer node computer 565. The digital signature can 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 can be attached to or included in the digital asset, along with the corresponding public key of the issuer node computer used to verify the digital signature.

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

[0184] Before generating and / or providing the digital asset, the issuer node computer 565 can also check that the digital asset transaction complies with rules, protocols, and restrictions (such as speed and transaction amount thresholds).

[0185] In step S510, the issuer node computer 565 can provide the digital asset and any other suitable information to the management node computer 550. The issuer node computer 565 can request consent for the digital asset and request a second digital signature. For example, the issuer node computer 565 can transmit a message identified by the management node computer 550 as a digital asset transfer request message. The message can contain the digital asset and the first digital signature and can request the management node computer 550 to approve (e.g., verify) the digital asset, provide a second digital signature, publish the digital asset to the blockchain ledger, notify the recipient node computer 545 of the digital asset, and / or otherwise process the digital asset.

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

[0187] The management node computer 550 can 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 can 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.

[0188] In step S514, after the transaction is confirmed, 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 the second digital signature is provided, the digital asset may be considered minted and valid.

[0189] In some embodiments, the management node computer 550 may also generate a smart contract for the digital asset (e.g., a smart contract indicating the conditions under which the value of the digital asset should be settled). For example, each entity participating in the network may have agreed during registration to establish a smart contract when a digital asset is requested or generated. Thus, the management node computer 550 may be authorized to create and execute the smart contract. When the conditions for settlement of the smart contract are triggered, the management node computer 550 may enforce settlement between the sending institution account and the receiving institution account (e.g., an account at a central bank, or other correspondent account).

[0190] 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 for use.

[0191] 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 contain information about the value, the recipient of the value, the sender of the value, the date and time of the transaction, the digital asset identifier, and any other suitable information. In some embodiments, the ledger may contain a copy of the digital asset.

[0192] 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 (e.g., the transfer of value from a user to a resource provider) may be considered official and guaranteed.

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

[0194] In some embodiments, the ledger may not be updated (e.g., 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 management node computer 550) collects and validates proposed transactions and periodically groups them together to form a new block proposal. Other designated block signers (e.g., the management node computer 550) approve the proposed block with their signatures. All network members may know the identities of the block signers, and a 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.

[0195] 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 management node computer when needed.

[0196] 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.

[0197] 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 management node computer 550.

[0198] 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 management 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 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.

[0199] 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 receiving node computer 545 may also confirm that the value being transferred is properly owned by the user (e.g., whether the receiving node computer 545 has a complete ledger view or other access to the user's account records).

[0200] In some embodiments, the receiving node computer 545 may also update the ledger. Thus, in some embodiments, the receiving node computer 545 may not maintain its own ledger and may instead refer to the ledger of the management node computer when needed.

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

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

[0203] In some embodiments, the receiving institution computer 540 may have 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 may trust the digital signature provided by the digital asset, the receiving institution computer 540 may trust the management node computer 550, the receiving institution computer 540 may 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 may be kept confidential. Moreover, even if the transfer is initiated deceptively, the management node computer 550 can still ensure the security of the funds. Additionally, a smart contract for the transfer of funds can be enforced, thereby providing further assurance to the receiving institution computer 540 that it will receive the value indicated in the digital asset.

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

[0205] 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.

[0206] 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. Thus, only £980 may be credited to the resource provider's account.

[0207] 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.

[0208] 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.

[0209] In step S530, at a later time, a settlement of the digital asset value may be made 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 enterprise ID, amount, etc.) may be obtained from the digital asset.

[0210] 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 there is no need 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).

[0211] Settlement can continue by debiting the digital asset value (or re-presented settlement value) from a first account (e.g., a first settlement account) associated with the sending institution computer 560 at the central bank, and this value can be credited to a second account (e.g., a second settlement account) associated with the 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 may exist specifically for the settlement process. The first account may be at a first central bank location in a first country (e.g., the United States), while the second account may 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).

[0212] 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 the 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.

[0213] As a result, settlement may not need to be carried out through multiple corresponding bank relationships. In fact, funds can be settled between the receiving institution computer 540 and the sending institution computer 560 through the central bank. In addition, 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 set aside resources for multiple corresponding accounts or otherwise interact with multiple correspondent banks. In some embodiments, each financial institution can maintain multiple accounts in a central settlement entity to conduct transactions in different currencies. For example, the sending institution computer 560 can have multiple (e.g., 1 - 20) accounts, each for a different currency type. As a result, the sending institution computer 560 can settle transactions with the receiving institution computer 540 using the most appropriate currency. For example, the sending institution computer 560 may have an account with a pound value and can directly settle with the receiving institution computer 540 in pounds.

[0214] 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 be carried out through one or more correspondent banks in a first country (e.g., the United States), international correspondent bank relationships, and one or more correspondent banks in a second country (e.g., England).

[0215] In some embodiments, the digital asset may be or include 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 may cause the settlement process to be performed with the next batch of settlements or at a specific time of day. As explained above, the smart contract may be executed by the administrative node computer 550, an administrative entity, a central bank (which may receive the smart contract from the administrative node computer 550), or any other suitable party. After settlement, the digital asset may be destroyed (e.g., deleted or marked as settled). Also, the digital asset may be digitally signed to indicate that settlement is complete, and the transaction record may be stored (e.g., in a database list or a blockchain ledger).

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

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

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

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

[0220] Additionally, as mentioned above, one or more additional nodes (e.g., management nodes, issuer nodes, and / or recipient nodes) may 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. For example, when a certain node accesses the central ledger, or when ledger updates are sent to a certain node, the block body may be removed or obfuscated from certain blocks. Thus, in some embodiments, the ledger may not be fully public, as access may be restricted and filtered based on viewing entities.

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

[0222] In such a case, the sending institution computer 560 may send a transaction request to the interaction platform. The interaction platform may then generate the digital asset (instead of the issuer node computer 565), or the interaction platform may request the generation of the digital asset (e.g., by nodes in the asset transfer network). Additionally, the interaction platform (instead of the issuer node computer 565) may 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 may also perform some of the functions of the management node computer 550, such as providing a second digital signature.

[0223] Next, the interaction platform may provide the digital asset and the corresponding digital signature to the asset transfer network to announce the transaction. For example, the interaction platform may provide the digital asset and the 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 may be distributed among the nodes and provided to the recipient node computer 545.

[0224] Embodiments of the present invention have many advantages. For example, 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 reduces additional communication and removes the secrecy of various unknown correspondent bank relationships present in decentralized traditional systems.

[0225] 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. This trust can be further enhanced by knowing that network validators (such as administrative nodes) can be restricted, known, predefined, and operated by trusted parties. A distributed ledger can instill confidence in each participating entity having the same information about the protocols and transfers that have taken place. Similarly, a digital asset with a digital signature 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.

[0226] This high level of network trust and digital signature of digital assets can sufficiently reduce transaction risk to allow the receiving financial institution to make the value of the digital assets received in the recipient's account immediately available, even if the value has not been settled. This means that after initiating a transfer, the transferred value is almost immediately available. Thus, regardless of when and how settlement occurs, embodiments allow funds to be available much faster (e.g., immediately available versus 3 - 7 days available) than traditional transfer methods, which may not make funds available for withdrawal until the transfer is complete.

[0227] The use of a central settlement service entity (such as a central bank) advantageously allows for a centralized settlement process. For example, in some embodiments, 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 (such as 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 bank 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 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 bank relationships, which traditionally could involve twenty or more relationships.

[0228] Figure 6 Additional details showing an example of the asset transfer network 600. Figure 6 Provides an expanded view of the asset transfer network process. For example, a detailed representation of the data center 650 is shown in the center of the figure, which in some embodiments may be similar or identical to the management node computer. Figure 6 Also shown is the data center 650 interacting with other entities, such as the sending institution computer 660 and the receiving institution computer 650. Figure 6 Each component shown in can represent a computer, a software module, a process being implemented, or a cloud-based service.

[0229] As mentioned above, in some embodiments, the data center 650 can represent the management node computer. Additionally, in some embodiments, in addition to representing the management node computer, the data center 650 shown in Figure 6 can also encompass other components and / or functions with respect to Figure 1 described, such as the interaction platform 154. For example, the data center 650 can represent the management entity described above and can include some or all of the functions provided by or associated with the management entity. Accordingly, the data center 650 shown in Figure 6 can alternatively be referred to as a management computer, a network computer, or a transaction processing computer. In some embodiments, the data center 650 shown in Figure 6 can also represent Figure 1 other nodes shown in, not just the management node computer 150, such as the issuer node computer 165 and / or the recipient node computer 145.

[0230] Figure 6 A series of steps of the process executed by the data center 650 are also shown. The components in the asset transfer network 600 can be described in conjunction with the process.

[0231] For example, the asset transfer network 600 includes a sending institution computer 660, which can interact with the data center 650 in various ways. As shown by arrow 1, the sending institution computer 660 can register with the asset transfer network. The data center 650 can first execute an authentication process 651. This can include verifying the identity of the sending institution and providing access credentials (e.g., username and password) to the sending institution computer 660. The sending institution computer 660 can then execute a login process 653 to access the asset transfer network. After a successful login, the sending institution computer 660 can then access the user interface 654 (as shown by arrow 1.1) to interact with the data center 650.

[0232] In some embodiments, before being able to send digital assets, the sending institution computer 660 may first complete the login process 650F. As shown by arrow 1.2, the sending institution computer 660 may provide any necessary information to the data center 650. As shown by arrow 1.3, the login may include risk analysis, compliance screening, collection of user data (e.g., information about the sending institution computer 660 and / or the clients of the sending institution), and providing information about the digital asset network program to the sending institution computer 660. The login process 650F may be performed by and / or be similar to the registration module 150F shown in Figure 2 In addition, the risk analysis component may be performed by the risk management computer 157 shown in Figure 1 and / or the risk module 150H shown in Figure 2 .

[0233] As shown by arrows 1.4 and 1.5, once a response is received and the login is completed, the data center 650 may store information about the sending institution computer 660 in the database 656. Thus, in some embodiments, the database 656 may be similar to the user database 150q shown in Figure 2 .

[0234] As shown by arrow 1.6, the data center 650 may cause an account (e.g., create a new account and / or digital asset) to be established for the sending institution computer 660 via the creation module 650X. For example, the creation module 650X may create an account identifier (e.g., enterprise ID) that can represent the sending institution computer 660 during a digital asset transfer. As shown by arrow 1.7, this account information may also be stored in the database 656.

[0235] In some embodiments, after successful registration and login, the sending institution computer 660 may initiate a digital asset transfer. As shown by arrows 2 and 2.1, the sending institution computer 660 may log in and access the user interface of the data center 650. As shown by arrow 2.2, the sending institution computer 660 may request a digital asset transfer by providing information about the digital asset transfer (e.g., recipient, amount, etc.) to the transaction processing module 650P.

[0236] The transaction processing module 650P may then verify the transaction request (e.g., similar to Figure 2150J in the verification module 150J), and determine any fees and / or exchange rates applicable to the digital asset transfer. Then, in step 2.3, the data center 650 can notify the receiving institution computer 660 to credit the recipient account (e.g., the resource provider account) with the final amount (e.g., the digital asset amount minus any fees after currency conversion). In addition, as shown by arrow 2.4, the transaction details can be stored in the database 656. Accordingly, the database 656 can be connected to the database shown in FIG. Figure 1 Similar to the transaction repository 156 in .

[0237] After the transaction details are ready, the information can be passed to the digital asset preparation module 650M, as shown by arrow 2.5. The digital asset preparation module 650M can then generate digital assets based on the transaction details and temporarily store the digital assets in the database 656, as shown by arrow 2.6. Accordingly, the digital asset preparation module 650M can be similar to the one shown in FIG. Figure 2 The digital asset preparation module 650M may also prepare the digital asset for storage in the blockchain ledger by providing the digital asset to the recording module 650Q of the blockchain application interface 650V, as shown by arrow 2.7. Arrow 2.8 may be a receipt confirmation and / or digital signature prompt.

[0238] As shown by arrow 2.10, the digital asset preparation module 650M can prompt the hardware security module 650P for one or more digital signatures. For example, the hardware security module 650P can generate a digital signature using a private key associated with the data center 650. In some embodiments, the hardware security module 650P can also generate a digital signature using a private key associated with the sending organization computer 660. Accordingly, the hardware security module can be similar to Figure 2 The key database 150P and / or signature module 150K in the digital asset preparation module 650M. The digital signature can be returned to the digital asset preparation module 650M, as shown by arrow 2.11.

[0239] As shown by arrow 2.12, the digital signature and / or the completed digital asset can be provided to the recording module 650Q. At this point, the blockchain application interface 650V can forward the digital asset and digital signature to the blockchain application 650D. The blockchain application 650D can update the blockchain ledger with the new digital asset (e.g., which can include creating a new block) and create a smart contract based on the digital asset. For example, Figure 6As shown, the blockchain application 650D can create digital records that show a commitment of a value from a sending institution account (or a specific user account within a set of user accounts associated with the sending institution) to a receiving institution account (or a specific user account within a set of user accounts associated with the receiving institution). Accordingly, the blockchain application 650D can be similar to the update ledger module 150L and / or the ledger database 150D).

[0240] In some embodiments, as Figure 6 shown, the transfer of value from a sending institution to a receiving institution can be achieved by using a data center (or other central entity) as a mediator. For example, the value can be transferred from the sending institution account to the data center account, and then the value can be transferred from the data center account to the receiving institution account.

[0241] Once the digital asset is recorded in the blockchain ledger, the data center 650 can store a copy of the digital asset and / or the block in the database 656 (e.g., similar to the transaction library 156 shown in Figure 1 ), as shown by arrow 2.13. Additionally, the data center 650 can send a message to the receiving institution computer 640 (or the recipient node computer) notifying that the digital asset has been processed and guaranteeing the transaction value. In some embodiments, the receiving institution computer 640 (or the recipient node computer) can also access a copy of the blockchain ledger to detect the newly recorded digital asset (e.g., by viewing a read-only restricted view version of the blockchain ledger stored by the blockchain application 650D).

[0242] As shown by arrow 4, in some embodiments, the sending institution computer 660 can contact the data center 650 in a different manner. For example, the sending institution computer 660 can run an issuer node and can generate digital assets and / or generate digital signatures (e.g., using a separate hardware security module). The sending institution computer 660 or the issuer node computer can send the prepared digital assets and digital signatures to the data center 650, as shown by arrow 4. An interface (e.g., adapter 658) can receive the digital asset and forward it to the transaction processing module 650P. The digital asset transfer process can proceed as described above, except that the data center 650 can skip the steps of generating digital assets and digital signatures associated with the sending institution. Moreover, the data center 650 can verify the authenticity of the received digital signature (e.g., similar to the verification module 150G in Figure 2 ).

[0243] Subsequently, after publishing the digital asset to the ledger and notifying the relevant parties, data center 650 can coordinate the settlement of the digital asset value. For example, after a set amount of time has passed, or when the smart contract is otherwise triggered, settlement service 655 may cause the value to be settled between the sending institution's account and the receiving institution's account. Accordingly, settlement service 655 can be similar to the settlement service computer 155 shown in Figure 1 In some embodiments, settlement service 655 can obtain information about the new digital asset from digital asset preparation module 650M, as shown by arrows 3.1 and 3.2. Settlement service 655 can update database 656 to indicate that settlement has been initiated, as shown by arrow 3.3. Settlement service 655 can then cause the value to be transferred and notify receiving institution computer 640 that the value has been settled (e.g., at the central bank), as shown by arrow 3.4. Finally, settlement service 655 can update database 656 to indicate that the digital asset value has been successfully settled, as shown by arrow 3.5.

[0244] Network topology

[0245] Figure 7 Figure showing an example network topology that can be used with embodiments of the present invention. Embodiments of the present invention allow network processes, such as registration, digital asset creation, ledger update, and ledger storage, to be distributed. Figure 7 Example configurations for achieving this network distribution and redundancy are provided.

[0246] Figure 7 Includes routing computer 770, first data center 750, second data center 850, and key management computer 780. Routing computer 770 can initially receive a digital asset transfer request (e.g., from a sending institution computer or an issuer node computer) through firewall 775. Routing computer 770 can then determine which data center should process the digital asset and forward the digital asset transfer request to the determined data center.

[0247] In some embodiments, the data center can be the same as or similar to the management node computer (e.g., as described in Figure 1 , 2 and 6), and each data center can be referred to as a management node computer. For example, similar to the management node computer, the data center can manage the asset transfer network by processing transactions (e.g., validating and signing digital assets) and maintaining a transaction ledger (e.g., a blockchain). Additionally, as explained above regarding the data center in Figure 6 the data center can instead represent the management entity described above and can further include some or all of the functions provided by the management entity. For example, the data center can also cover regarding Figure 1Other components and / or functions described, such as the interaction platform 154. Thus, the data center can alternatively be referred to as a management center, a network center, or a transaction processing center (where each can include one or more server computers). In some embodiments, the data center can also represent Figure 1 other nodes shown in, such as the issuer node computer 165 and / or the recipient node computer 145.

[0248] As Figure 1 and Figure 4 shown, the asset transfer network can include multiple management node computers. Similarly, Figure 7 include multiple data centers. Incorporating multiple data centers into the asset transfer network provides several advantages. For example, the burden of processing incoming digital assets can be divided among the data centers, allowing for the rapid processing of digital assets. The multiple data center locations provide multiple possible destinations for incoming digital asset requests, and the routing computer 770 can intelligently route each incoming digital asset to the most appropriate data center. For example, the routing computer 770 can send a digital asset request to the data center with the shortest backlog (e.g., to evenly distribute the processing load), to the data center closest to the requester (e.g., in the case where the data centers are geographically distributed), or to a specific data center based on any other suitable consideration. Thus, digital assets can be verified, signed, published to the blockchain ledger, and otherwise processed more efficiently.

[0249] Additionally, each data center can store and maintain a separate copy of the blockchain ledger. Thus, blockchain ledger security is increased through redundancy.

[0250] Although digital assets are initially processed by a single data center, the data centers can share information about newly approved digital assets (e.g., or newly created blocks) with each other. For example, the first data center 750 can provide an updated message about a new digital asset and / or a new blockchain block to the second data center 850. The first data center 750 can also receive a similar updated message from the second data center 850 about a new digital asset or block created or completed at the second data center 850. Thus, both data centers can store a complete copy of the transaction ledger, even though each data center only processes a portion of the digital assets.

[0251] In addition, when the second data center 850 receives a ledger update from the first data center 750, the second data center 850 can verify each new digital asset and / or block before updating its own ledger. Thus, each digital asset and / or block can be verified and approved by each data center, providing more opportunities to detect improper digital assets and behaviors. Therefore, there are additional defenses after the digital assets are initially verified and recorded in the blockchain blocks of the first data center 750.

[0252] Various data centers can be combined to create a complete ledger centrally managed by a network operator. However, separating individual data centers and placing them in different locations allows transaction processing and block creation to be distributed. Thus, the transaction processing throughput increases when maintaining an immutable ledger. The blockchain ledger data is distributed for redundancy but remains under the control of a single central network operator (and thus is not vulnerable to malicious changes).

[0253] Figure 7 A network with distributed data centers is depicted, which can independently create blockchain blocks and then update them one by one to synchronize their respective blockchain records. For illustrative purposes, Figure 7 it is described in the context of transferring digital assets. However, the embodiments are equally applicable to any other suitable communication and / or record-keeping network that can utilize distributed data centers. For example, distributed data centers can be applied to an asset transfer network that facilitates the transfer of any suitable type of digital asset (or other value), such as access credentials, event tickets, property rights, currency, game points, mobile phone minutes, digital media, currency, etc.

[0254] More generally, distributed data centers can be used to record any appropriate type of data element. For example, data elements representing updated medical information, information about newly issued academic qualifications, exam results, vehicle registration data, signature waivers, and / or any other suitable type of recordable information can be traced and recorded. Any suitable type of digital record can be used to track the new data elements. For example, instead of a blockchain ledger, the data elements can be stored in a simple list format.

[0255] Although Figure 7 two data centers (i.e., the first data center 750 and the second data center 850) are shown, any suitable number of data centers can be included in the asset transfer network. Including additional data centers can further improve network efficiency and ledger redundancy.

[0256] As Figure 7 shown, the first data center 750 can include multiple components. These components can be similar to Figure 2 the management node computer components shown and / or similar to Figure 6The data center components shown in. Alternative description Figure 2 and Figure 6 all components in Figure 7 for illustrating how multiple distributed data centers operate in the same manner in an asset transfer network. Figure 7 The components of the first data center 750 shown in include a processing computer 750A that includes one or more processing applications, a rules computer 750E, a signature computer 750K, a ledger database 750D, a key database 750P, one or more additional databases (e.g., database computer 750C and database computer 750Q), an encryption computer 750N, and any other suitable hardware or software modules. Embodiments allow each component to take the form of a separate server computer. Alternatively, in some embodiments, one or more of these components may take the form of software modules executed on one or more server computers. In any case, as a whole, the first data center 750 may be referred to as the first data center computer. Similarly, the second data center 850 may be referred to as the second data center computer.

[0257] The processing computer 750A may include a hardware processor and / or software module for receiving and processing digital asset transfer requests. For example, the processing computer 750A may receive and verify digital assets, obtain a digital signature of the digital assets, add the digital assets to the ledger (e.g., create a new blockchain block containing the digital assets), and perform any other suitable tasks for processing digital assets. The processing computer 750A may also facilitate network registration of other entities. In some embodiments, the processing computer 750A may perform any of the activities described above with respect to the management node computer. For example, the processing computer 750A may perform activities associated with Figure 2 some or all of the modules included in the computer-readable medium of

[0258] The processing computer 750A may include one or more processing application modules, which are represented by App1, App 2, App 3, and App n in Figure 7 These application modules may represent different hardware processors or virtual machines for receiving and processing different digital asset transfer requests. Different processing application modules may simultaneously process multiple incoming digital assets. The processing application modules may divide processing tasks to facilitate load balancing.

[0259] In some embodiments, the processing computer 750A may include instructions for sending information about record updates (e.g., new blocks) to the second data center 850 after creating a new block or otherwise adding new digital assets to the transaction ledger. Accordingly, the processing computer 750A may perform with respect to Figure 2The functions described for the updated ledger module 150L in. These ledger updates can be distributed after each digital asset is minted, after each block is created, every second, every 10 seconds, every minute, or at any other suitable time interval. Embodiments allow new blocks to contain information about a single digital asset, ten digital assets, each digital asset created within a specific time period, and / or any other suitable number of digital assets.

[0260] Additionally, in some embodiments, the processing computer 750A can include instructions to receive information about newly completed digital assets and / or blocks from the second data center 850 and verify these digital assets and / or blocks. For example, the processing computer 750A can verify the authenticity of each digital asset in a block by verifying the accompanying digital signature. The processing computer 750A can also verify each blockchain block by verifying the block header. For example, the processing computer 750A can confirm that the block header is the output of a hashing algorithm when some or all of the block body data is input into the hashing algorithm. The processing computer 750A can further confirm that each block is correctly related to the previous block. For example, the processing computer 750A can ensure that the link to the previous block, such as the previous block header, is included in the block body.

[0261] The rules computer 750E can include digital asset processing instructions and may include logic and rules specifically associated with the first data center 750. In some embodiments, the rules computer 750E can store instructions used by the processing computer 750A. For example, the rules computer 750E can store instructions similar or identical to Figure 2 the instructions of one or more modules included in the computer-readable medium in. In some embodiments, the rules computer 750E can also include transaction settlement instructions or can interact with a settlement service (e.g., Figure 1 the settlement service computer 155 in).

[0262] The ledger database 750D can store information about processed and published digital assets. For example, a blockchain ledger can be stored in the ledger database 750D. In some embodiments, the ledger database 750D can be similar or identical to Figure 2 the ledger database 150D in.

[0263] The key database 750P may include one or more encryption keys associated with one or more entities. For example, the key database 750P may include the private key of the first data center 750 used to create digital signatures. The key database 750P may also include one or more public keys associated with other entities (e.g., the issuer node and the recipient node) used to verify digital signatures and digital assets. In some embodiments, the key database 750P may take the form of a hardware security module (HSM). In some embodiments, the key database 750P may be the same as or similar to Figure 2 the key database 150P in

[0264] The signature computer 750K may be configured to create digital signatures using private keys and / or verify digital signatures using public keys. The signature computer 750K may be used to digitally sign digital assets, blockchain blocks, the entire blockchain ledger, and / or any other information that needs to be verified. In some embodiments, the signature computer 750K may access the encryption keys stored in the key database 750P. In some embodiments, the signature computer 750K may be the same as or similar to Figure 2 the signature module 150K in

[0265] The encryption computer 750N may perform any suitable encryption services. For example, ledger updates sent to the second data center 850 may be encrypted, and similarly, ledger updates received from the second data center 850 may be decrypted.

[0266] The database computers 750C and 750Q may be used to store any suitable information. For example, the database computer 750C may store a backup ledger of transactions (e.g., similar to Figure 6 the database 656 in Figure 2 while the database computer 750Q may store user data (e.g., similar to Figure 2 the user database 156Q in

[0267] In some embodiments, the first data center 750 and the second data center 850 may include similar components and / or functions. Accordingly, in some embodiments, any description of the first data center 750 equally applies to the second data center 850, and any description of the second data center 850 equally applies to the first data center 750.

[0268] The key management computer 780 can control the distribution and exposure of encryption keys. For example, when a sending institution (or any other suitable entity) registers with the asset transfer network, a key pair associated with the sending institution can be established. The key management computer 780 can distribute information about the new key pair to one or more data centers. For example, the sending institution can register with the network via the first data center 750. The key management computer 780 can obtain the key pair from the first data center 750 and provide it (along with other transaction details) to the second data center 850. As a result, the first data center 750 and the second data center 850 can verify the digital signatures created by the sending institution and otherwise process the digital asset transfer requests received from the sending institution.

[0269] According to an embodiment of the present invention, it may be about Figure 8 Describe a method 800 for processing transactions and combining digital records in an asset transfer network having multiple data centers. The method describes storing digital assets in a blockchain ledger. However, embodiments may also be used to record other types of data elements.

[0270] As explained above, a sending institution computer, an issuer node computer, or any other suitable entity may submit a digital asset transfer request to send a digital asset to a recipient. In some embodiments, the issuer node computer may create a digital asset, digitally sign the digital asset, and include the digital asset and the signature in the request to obtain verification and approval of the digital asset from the network administrator (e.g., as described in step S508 with respect to Figure 5 ).

[0271] At step S805, similar to step S510 in Figure 5 , the routing computer 770 may receive the digital asset transfer request through the firewall 775. For example, in some embodiments, all digital asset transfer requests may be sent directly to the routing computer 770. In other embodiments, the digital asset transfer requests may be sent to a data center (e.g., the closest data center), and each data center may include a routing module.

[0272] At step S810, the routing computer 770 may determine the data center for processing the digital asset transfer request. The determination may be based on many factors. For example, the routing computer 770 may send the digital asset transfer request to the closest data center (e.g., to achieve faster transmission and processing). The routing computer 770 may instead determine the load balancing priority and send the digital asset transfer request to the data center with the most available processing capacity or the most available processing application module.

[0273] In some embodiments, the routing computer 770 may also assign a priority level to incoming digital asset transfer requests. For example, a digital asset transfer request associated with a particular entity (e.g., a particular sending institution, issuer node, user, recipient, etc.) may be given a higher priority for the fastest processing.

[0274] Additionally, in some embodiments, the routing computer 770 may determine whether to process or reject a digital asset transfer request. For example, requests that are incorrectly formatted or associated with an unknown requester may be immediately rejected.

[0275] In step S815, the routing computer may transmit the digital asset transfer request to the determined data center. For example, the digital asset transfer request may be sent to the first data center 750. In some embodiments, the routing computer 770 can only transmit digital asset transfer requests to the first data center 750 and not to any other data center. The first data center 750 may then process the request and later provide information about the processed digital assets to other data centers.

[0276] In step S820, the first data center 750 may verify the digital asset, digital signature, and / or any other suitable information. For example, the first data center 750 may also confirm that the sending entities (e.g., issuer node computer and sending institution computer) are properly registered and compliant with the processing rules. In some embodiments, step S820 may be similar to Figure 5 step S512 in

[0277] In some embodiments, the digital asset transfer request may not include a digital asset. In such a case, step S820 may include generating a digital asset and / or generating an additional digital signature associated with the sending entity.

[0278] In step S825, the first data center 750 may generate a second digital signature of the digital asset (e.g., using the private key associated with the first data center 750). The first data center 750 may also create a smart contract and / or perform any other suitable transaction processing tasks. In some embodiments, step S830 may be similar to Figure 5 step S514 in

[0279] Accordingly, the first data center computer may process the first digital assets that indicate the transfer of value from the sender to the recipient by performing steps S820 - S825 and any other suitable steps.

[0280] In step S830, the first data center 750 can add digital assets to a transaction ledger, which can be stored locally at the first data center 750 (e.g., in the ledger database 750D). For example, the first data center 750 can create a new blockchain block with a block body and a block header. The block body can contain record information (e.g., information about the digital assets) and optionally additional digital assets processed during a similar time period. The block body can also contain a reference to the previous block, such as the previous block header. In some embodiments, some or all of the block body information can be used to generate the block header. For example, the block body can be input into a hashing algorithm, an encryption algorithm, and / or any other suitable data manipulation process, and some or all of the output can be used as the block header. In some embodiments, step S830 can include a ledger construction process similar to that described in Figure 5 step S516.

[0281] For description purposes, this step can be regarded as creating the first block of the first blockchain. However, the term first does not necessarily mean the start of the blockchain. Instead, the first blockchain can be an existing blockchain with multiple existing blocks, and the first block can be appended to the end of the existing blockchain.

[0282] In step S835, the first data center 750 can send a response to the requester of the digital asset transfer (e.g., the issuer node computer or the sending institution computer). For example, the first data center 750 can send a binary response indicating whether the digital asset has been successfully processed (e.g., and added to the transaction ledger) or rejected. In some embodiments, step S830 can be similar to Figure 5 step S516.

[0283] Additionally, the first data center 750 can send a message to the recipient (e.g., the recipient node computer or the receiving institution computer) notifying that the digital asset has been processed, which indicates that a value will be provided to the recipient. In some embodiments, this aspect of step S830 can be similar to Figure 5 step S520. However, the first data center 750, rather than the issuer node computer, may send the message. Accordingly, the sender and the recipient can be notified that the digital asset has been published to the blockchain ledger, and optionally that a smart contract has been established.

[0284] At this point, the digital asset can have been fully processed and the ledger updated locally at the first data center 750. However, to maintain a unified transaction ledger across the network, the first data center 750 can continue to update one or more other data centers with information about the digital asset and / or other ledger updates.

[0285] In step S840, the first data center 750 may transmit a message having information about the most recent ledger update to the second data center 850. For example, the message may include information identifying the first data center 750 (e.g., to distinguish it from other data centers), information about new digital assets, information about new blocks (e.g., block headers and / or block body data), a timestamp, a return address, and / or any other suitable information. The message may also include a request for information about the most recent blockchain ledger update at the second data center 850. In some embodiments, the first data center 750 may encrypt some or all of the ledger update information for transmission (e.g., using a symmetric key or the public key of the second data center 850). Accordingly, the first data center computer may send a message to the second data center computer indicating that a first block has been created for a first blockchain, where the message includes the block header, the block body, and / or any other suitable information.

[0286] In step S845, the second data center 850 may receive ledger update information from the first data center 750 and then verify the transaction information or perform any other suitable processing. For example, the second data center 850 may verify each digital signature associated with the new digital assets (e.g., using the relevant public key). The second data center 850 may also confirm that the block header is the correct hash of the digital asset information, the previous block header, and / or other suitable block body information. The second data center 850 may further verify that the previous block indicated in the current block body is the correct and expected previous block. In some embodiments, the second data center 850 may first decrypt the update message from the first data center 750 (e.g., using the corresponding symmetric key or private key).

[0287] In some embodiments, where the second data center 850 may verify the digital assets and / or blocks, the second data center 850 may not repeat all of the transaction processing performed by the first data center 750. For example, the second data center 850 may not check that each entity associated with the digital asset is registered in the asset network and complies with the network rules. Additionally, the second data center 850 may not create another digital signature for the digital assets and / or blocks. However, in other embodiments, the second data center 850 may fully repeat the transaction processing and perform some or all of these steps.

[0288] In step S850, the second data center 850 can add digital assets and / or blocks to its locally stored transaction ledger, or otherwise update the ledger with ledger update information received from the first data center 750. For example, the second data center 850 can copy the blocks received from the first data center 750 and add them to its own blockchain ledger. This can be considered as creating a second block (e.g., because it is for a different blockchain), but the second block is the same as the first block. As described below, the second data center 850 can add the entire block (e.g., both the header and the body) to the blockchain, or the second data center 850 can use only the block header.

[0289] In some embodiments, the second data center 850 can create a new transaction block that includes one or more digital assets received from the first data center 750. The new block can include additional digital assets processed by the second data center 850, or can include the digital assets received from the first data center 750. In some embodiments, the second data center 850 can also generate additional digital signatures (e.g., using the second data center 850 private key) to indicate that the information received from the first data center 750 has been verified and approved by the second data center 850. Accordingly, the second data center computer can add the first block header, block body, and / or digital asset record to the second blockchain.

[0290] In some embodiments, if the second data center 850 is unable to verify the digital assets, block headers, or block bodies received from the first data center 750, the second data center 850 can reject the ledger update information and not add it to the second data center 850 ledger. In this case, the second data center 850 can also notify the first data center 750 that the ledger update has been rejected, and the first data center 750 can then review its own transaction ledger and potentially identify and remove (or flag) improper transaction records.

[0291] As explained above, the second data center 850 can also receive and process digital asset transfer requests, create new blocks, and provide ledger updates to the first data center 750. In other words, the second data center computer can process the second digital asset and then record the second digital asset by creating another block in the second blockchain. This new block can be referred to as the third block because it is created after the first block (on the first blockchain) and the second block (a copy of the first block of the second blockchain). The second data center can then send a second message to the first data center computer, the second message indicating that the second digital asset is recorded in the third block of the second blockchain. When the first data center computer receives the second message from the second data center computer, the first data center computer can update the first blockchain ledger by adding a fourth block (which can be a copy of the third block (e.g., the header and / or body)).

[0292] As a result, the first data center 750 and the second data center 850 can update their local transaction ledgers to match, even if the digital assets are initially received and processed at only one data center. Each data center can contain a transaction ledger with the same list of digital assets. For example, each data center can have a similar blockchain with the same list of blocks (e.g., headers and / or bodies). Accordingly, each data center can have a complete list of all digital assets and / or blocks created across the digital asset network.

[0293] In some embodiments, each data center can have the same blockchain ledger with a set of matching digital asset records. In other embodiments, each data center can have a blockchain ledger that contains all digital assets, but different blockchain ledgers can have the digital assets and / or blocks listed in different orders. Accordingly, the block headers may also have different values (e.g., if the headers are generated based on the digital assets recorded in the block).

[0294] In some embodiments, the data centers can achieve fully matching blockchain ledgers (e.g., with the same headers, the same order of digital assets, etc.) by alternating when they send each other ledger updates. For example, the first data center 750 can send a ledger update (e.g., with the first block) to the second data center 850, then the second data center 850 can send a ledger update (e.g., with the second block) to the first data center 750, then the first data center 750 can send another update (e.g., with the third block) to the second data center 850, and so on. These updates can alternate in a regular, periodic pattern (e.g., every 10 seconds, 30 seconds, 1 minute, 10 minutes, etc.), and the blocks can reference each other in the appropriate order.

[0295] In other words, the second data center 850 can add the exact first block received from the first data center 750 to its own ledger. Subsequently, the second data center 850 can create a second block (e.g., within the last minute) based on the digital assets it processes locally and add the second block to its ledger. The second block can reference the first block (e.g., by generating the second block header partially based on the first block header) such that the second block is after the first block in the blockchain. The second data center 850 can then send the second block to the first data center 750. Once the first data center 750 receives the second block and adds it to its blockchain ledger, the cycle can repeat. For example, the first data center 750 can wait to create a third block (e.g., based on newly processed digital assets) until it receives the second block and adds it to the ledger. Once the second block is added, the third block can be created such that it references the second block. The first data center 750 can then send the third block to the second data center 850, and the process can continue to cycle in this way. As a result, the first data center 750 and the second data center 850 can have blockchain ledgers arranged in the same order.

[0296] As explained above, there can be additional data centers, such as a third data center. In this case, the first data center 750 can distribute ledger updates directly or indirectly to each additional data center. For example, the first data center 750 can send ledger update messages directly to each data center. Alternatively, the first data center 750 can send a single ledger update message directly to the second data center 850, and the second data center can then forward the ledger update message to the third data center (and so on). The ledger update message sent to the second data center 850 can include instructions to forward the update to the third data center.

[0297] In some other embodiments, different data centers can have slightly different configurations. For example, different data centers may have different rules and procedures for processing digital assets, building blockchains, and / or sharing ledger information. The data center rules can be adjusted based on the data center processing capabilities, location, affiliation, or any other suitable reason. For example, network end users, specific financial institutions, or any other suitable entity may wish to limit the privacy of ledger information or otherwise wish to enhance data center operations.

[0298] For illustrative purposes, Figure 9 a diagram of an asset transfer network with different groups of data centers is shown. Figure 9 It includes three groups (A, B, and C), and each group contains two data centers.

[0299] In some embodiments, the groups can be separated based on processing capabilities and database storage capacity. For example, Group A can include data centers configured for processing large volumes of digital assets and, thus, can receive a larger number of digital asset transfer requests (e.g., from a routing computer). Additionally, Group A can include data centers that can store, reference, and otherwise manage a more detailed blockchain ledger. In contrast, Group B can include data centers that can process fewer digital asset requests and can only manage a more limited blockchain ledger. Thus, Group B may not contain comprehensive transaction data for every digital asset in the blockchain ledger or may not contain all block bodies.

[0300] In other embodiments, the groups can be separated based on geographical location. For example, Group A can include data centers located in China, Group B can include data centers located in the United States, and Group C can include data centers located in the United Kingdom. Alternatively, the groups can be separated based on the institutions to which they belong. For example, Group A can include data centers associated with a first financial institution, Group B can include data centers associated with a second financial institution, and Group C can include data centers associated with a third financial institution. Any other suitable type of grouping can be made, such as grouping based on government and private affiliations, based on transaction types (e.g., person-to-business, person-to-person, and business-to-business), and the like.

[0301] Different groups of data centers can contain different transaction processing rules and procedures. For example, the data centers in Group A can be configured to process a specific quantity or type of digital assets or digital assets associated with a certain region. Accordingly, if an incoming request is associated with an entity in a certain region or if the incoming request has any other specific quality designed for Group A, the routing computer 770 can decide to send certain digital asset transfer requests to the data centers in Group A.

[0302] In addition, the way two data centers within the same group interact with each other may be different from the way a third data center in a different group interacts with each other. For example, Group B may not be configured to receive and store ledger updates using comprehensive transaction details or complete block information (e.g., due to processing or storage limitations). Additionally, Group A can be associated with entities (e.g., organizations, service providers, or regions) that do not wish to share transaction data outside the group. Accordingly, the first data center 750 and the second data center 850 in Group A can be configured to share transaction data with each other but not with other data centers in other groups. For example, information in the body of a block or digital asset, such as the date and time of transfer, the transfer amount, and the identification information of the transfer participants (e.g., the sender and recipient of the transfer amount), may not be shared outside the group.

[0303] In some embodiments, although the transaction data and the block body may not be shared, the block header can still be shared with data centers outside Group A because the block header may not convey meaningful transaction information. For example, the block header can be a hashed version of the transaction data (e.g., the block body), where the transaction data cannot be derived from the one-way hash. In some embodiments, subsequent blocks or block headers can be generated partially based on the previous block header. Accordingly, sharing the block header enables all data centers (regardless of group affiliation) to continue building a synchronized blockchain.

[0304] Accordingly, in some embodiments, the data centers in Group A can send ledger updates to other data centers in other groups, but the transaction data or the block body can be removed (or obfuscated) in a similar manner as described above with respect to the light nodes and the filtered ledger. However, here, when the data centers of the first group (e.g., the management nodes) are viewing ledger data created at the data centers of the second group (as compared to when a non-management entity (e.g., the issuer node or the recipient node) is viewing the ledger), the transaction data or the block body is removed. In other words, a single central entity maintaining the ledger may restrict itself from viewing certain transaction data and block body information. This is possible because the single central entity can be implemented as a group of distributed data centers with different functions, purposes, and / or affiliations.

[0305] According to an embodiment of the present invention, it can be described with respect to Figure 10 Method 1000 for distributing limited ledger updates to data centers with different rules or different affiliations is described. The method describes storing digital assets in a blockchain ledger and sharing some information between blockchain ledgers. However, embodiments can also be used to record other types of data elements and share some information between the records.

[0306] In Method 1000, the data centers in Group A may share transaction data (e.g., block body data) with each other, but not with the data centers of other groups, as described above. Accordingly, as described above for steps S805 - S850 in Method 800, the first data center 750 can receive and process a digital asset transfer request, create a new block of the blockchain, and share information about the processed digital asset and the new block with the second data center 850 (which is in Group A). The first data center 750 can then prepare to send a ledger update to the third data center 950 in Group B, but can first adjust the ledger update message (e.g., by removing the transaction data from the message).

[0307] In step S855, the first data center 750 may remove transaction data from the ledger update message. For example, the first data center 750 may remove digital asset information from the ledger update message, such as information identifying the sender or recipient, transfer value, time and date, and / or any other suitable information. This may include removing some or all of the block body data from the message. However, the first data center 750 does not remove the block header (or other suitable transaction identifier or transaction group identifier).

[0308] In step S860, the first data center 750 may send the ledger update message with the removed transaction data to the third data center 950. For example, the first data center 750 may send the block header, but not the block body, to the third data center 950. As a result, the third data center 950 may receive the block header (or other suitable ledger entry identifier) without the block body (or other meaningful digital asset information), thus leaving group A. Even if the block header is calculated based on the block body (e.g., using a one-way hash and / or encryption), the third data center 950 may not be able to derive the block body from the block header (e.g., due to the one-way hash, or because the third data center 950 does not have access to the decryption necessary key).

[0309] In step S865, the third data center 950 may verify the block header and / or other ledger update information received from the first data center 750. For example, the third data center 950 may confirm that the header has an appropriate length or pattern, or verify it using a zero-knowledge proof.

[0310] In some embodiments, the third data center 950 may receive a digital signature created by the first data center 750 to obtain a digital asset or block, and the third data center 950 may verify the digital signature using the public key associated with the first data center 750. However, the third data center 950 cannot perform the same type of verification or many verification steps as those performed by the second data center 850 in Figure 8 step S845 because the third data center 950 may not have access to the block body.

[0311] In step S870, the third data center 950 may add the block header to its locally stored ledger. For example, the third data center 950 may create a new block for the local blockchain. The new block may contain the received block header, but not the block body (e.g., because it was not provided). In some embodiments, the new block may have only a header (e.g., it may be the same as the received header), and the new block may not have any information in its block body.

[0312] The block header can be used as a link to connect future blocks to the blockchain. For example, when the third data center 950 generates a subsequent block for a locally processed digital asset, the subsequent block header can be generated partially based on the block header received from the first data center 750.

[0313] For example, at step S875, the third data center 950 can complete the processing of one or more local digital assets and add them to the local transaction ledger. This may include generating additional blocks for the local blockchain based on the locally processed digital assets. In some embodiments, the block body can contain information about the locally processed digital assets, the previous block header (which is the header received from the first data center 750), a timestamp, information identifying the third data center 950 as the block creator, and / or any other suitable information. Then, the embodiment allows the block header of the block to be created by hashing, encrypting, or otherwise manipulating some or all of the information in the block body. As a result, the block header received from the first data center 750 is referenced by the subsequent block and is hereby incorporated into the string of blocks and block headers of the third data center 950 blockchain.

[0314] Accordingly, the blockchain of the third data center 950 can continue to be constructed using the correct references to the previous blocks, and the blockchain can be complete, containing some link information (e.g., headers) about each block created in the network, even if the block body data is removed. Although the blockchain ledgers stored in different data centers may not exactly match due to the lack of digital asset information (e.g., missing block bodies), they may at least have matching block headers.

[0315] The third data center 950 may later wish to refer to the blockchain of the first data center. For example, the third data center 950 may seek to obtain removed transaction data or block bodies, or confirm the release of a specific digital asset (e.g., in response to a transaction dispute).

[0316] At step S880, the third data center 950 can send a request for the transaction data or the entire block body to the first data center 750. The third data center 950 can indicate that it wishes to receive transaction data that occurred on a certain day (or other suitable time range) or transaction data that matches certain specific information (e.g., transactions between a specific sender and receiver or transactions containing a specific enterprise ID).

[0317] In step S885, the first data center 750 may decide whether to provide transaction data (or the entire block body) 950 to the third data center. For example, the first data center 750 may analyze rules regarding the amount of information that can be released upon request (e.g., restrictions based on the type of requesting data center, restrictions related to the age of the transaction, etc.). The first data center 750 may also determine whether it has the required transaction data (e.g., a transaction with specified parameters).

[0318] In step S890, the first data center 750 may send the requested transaction data (or the entire block body) to the third data center 950 (if it is determined that this action is acceptable). In other embodiments, instead of sending the actual digital asset record or block body, the first data center 750 may send a binary response that indicates whether a digital asset with specified parameters exists in the ledger.

[0319] In an alternative embodiment, instead of removing the block body, the block body (or transaction data) may be obfuscated. For example, in step S855, the first data center 750 may obfuscate the block body. This may include encrypting some or all of the block body, hashing the block body, replacing the block body with false or meaningless information, or otherwise obfuscating the recorded information. Then, in step S870, the third data center 950 may add the block header and the obfuscated block body to its blockchain ledger. In some embodiments, if the block body is encrypted, the third data center 950 may obtain the key for decrypting the block body. For example, in step S890, the first data center 750 may provide the key for viewing the block body information.

[0320] Thus, using separate data centers can allow a single asset transfer network to have different customizable features and be used in different groups, even if the groups do not wish to share transaction information or block bodies with other groups. For example, a group may effectively run a local blockchain (e.g., maintained by one or more data centers of the group). The block headers and other non-restricted information may still be shared outside the group for some or all transactions, but the block body may not be shared. Accordingly, each data center may still contain a set of master block headers that are bound together with different local blockchain ledgers, while the actual block bodies with transaction record information may be kept within the group.

[0321] As explained above, the embodiments allow these types of local and restricted blockchain ledgers to be used for any type of application or entity that benefits from enhanced local privacy. For example, certain financial institutions may wish to protect information regarding customer transactions. Accordingly, the financial institution may maintain its own blockchain ledger and distribute only the block headers (and non-sensitive transaction data) to a central network operating entity or other institutions.

[0322] As mentioned above, different groups of data centers may have ordered strings of matching blockchain headers. However, since each data center may only have a partial view of the entire set of block bodies, different groups of data centers may not have an exactly matching blockchain ledger.

[0323] An example of synchronizing while having only a partially matching blockchain ledger is shown in Figure 11 . Six consecutive blocks in the blockchain are shown. The blocks may represent a network-wide blockchain ledger. While the blockchain ledger may represent all transactions in the network, each data center can construct its own copy of the blockchain and may have a limited view of the transaction data within the blockchain ledger.

[0324] Figure 11 Two versions of the same blockchain are shown, the blockchain constructed by the first data center 750 and the blockchain constructed by the third data center 950. As shown, the blockchain of the first data center contains the block bodies of blocks 1, 3, and 5. This may be the result of the first data center 750 having generated blocks 1, 3, and 5.

[0325] In contrast, the third data center 950 does not have the block bodies of blocks 1, 3, and 5. This may be the result of the first data center 750 having sent a ledger update message to the third data center 950 that contains the block headers but not the block bodies. Similarly, the blockchain at the third data center 950 may contain the block bodies of blocks 2, 4, and 6, while the blockchain at the first data center 750 may not contain these block bodies.

[0326] In other embodiments, one of the data centers can be configured to share block bodies. For example, in some embodiments, although the third data center 950 did not receive the block bodies from the first data center 750, the third data center 950 can share its block bodies with the first data center 750. This would result in the first data center 750 having all the block bodies, while the third data center 950 would still have half of the block bodies.

[0327] As Figure 11 shown, although both blockchains have an incomplete view of the block bodies, both blockchains contain the entire set of block headers. This is because, in some embodiments, both data centers can provide each other with the block headers they generate. This allows both data centers to maintain a complete and dynamic list of block headers, even if they do not generate some of the block headers.

[0328] Figure 11The arrows in [description] illustrate that the first data center 750 can send Header 1 to the third data center 950, and the third data center 950 can send Header 2 to the first data center 750, and so on. The additional arrows illustrate how each header is used as part of the block body in subsequent blocks, and then how subsequent blocks are used to generate subsequent headers. For example, the third data center 950 can incorporate Header 1 (received from the first data center 750) into the block body of Block 2. Then, the third data center 950 can create the block header of Block 2 based on its block body. As a result, through data center collaboration, each block in the blockchain can reference the previous block.

[0329] In some embodiments, although data centers may not share sensitive transaction information, in addition to the current block header, data centers can also share the previous block header. Thus, a data center can send a portion of the block body along with the block header. For example, when the third data center 950 sends Header 2 (generated by the third data center 950) to the first data center 750, the third data center 950 can also include Header 1 (generated by the third data center 950) in the message. As a result, the first data center 750 can confirm that Header 2 belongs to the block after Block 1, where the first data center 750 stops here. Otherwise, when assembling blockchain blocks, the first data center 750 can simply trust (e.g., based on a programmed update message synchronization) that Header 2 belongs to the subsequent block and reference Block 1.

[0330] In Figure 11 [description], two data centers alternate block generation for every other block. However, embodiments allow data centers to trade off block generation in other ways and patterns. For example, the first data center 750 can generate two or more blocks in a row and then send the headers of the two blocks to the third data center 950. The third data center 950 can wait to generate a new block until it receives an update from the first data center 750.

[0331] In addition, more data centers can participate in this blockchain update process. For example, if another data center is added to Figure 11 [description], then each data center can generate every other two blocks.

[0332] As explained above, embodiments of the present invention allow distributed data centers to record any suitable type of data element. For example, data elements representing updated medical information, information on newly released academic qualifications, exam results, vehicle registration data, signature waivers, and / or any other suitable type of recordable information can be traced and recorded. Any suitable type of digital record can be used to record the new data elements. Any suitable type of data element record can be shared between data centers, but some data centers can only publish record identifiers without recording information.

[0333] One embodiment of the present invention relates to a method. The method includes processing a first data element by a first data center computer and creating a first record of the first data element in a first database. The method further includes sending a message indicating that the first record has been created to a second data center computer. The second data center computer updates a second database based on the message.

[0334] Another embodiment of the present invention relates to a first data center computer configured to perform the above method.

[0335] Another embodiment of the present invention relates to a method. The method includes processing a first data element by a first data center computer and creating a first record of the first data element in a first database. The method further includes sending a first message indicating that the first record has been created to a second data center computer. The method further includes: receiving a second message from the second data center computer, the second message indicating that a second record of a second data element has been created by the second data center computer; and updating the first database based on the second message. The method further includes: receiving the first message from the first data center computer by the second data center computer, the first message indicating that the first record has been created; and updating the second database based on the first message. The method further includes: processing a second data element; creating a second record of the second data element in the second database; and sending the second message to the first data center computer indicating that the second record has been created.

[0336] Another embodiment of the present invention relates to a system that includes a first data center computer and a second data center computer configured to perform the above method.

[0337] Another embodiment of the present invention relates to a method. The method includes processing a first digital asset by a first data center computer, the first digital asset indicating a transfer of a value from a sender to a recipient. The method further includes: recording the first digital asset in a first database; and sending a message to a second data center computer, the message indicating that the first digital asset has been recorded. The second data center computer updates a second database based on the message.

[0338] In some embodiments, the message sent to the second data center computer includes a digital asset, and the second data center records the first digital asset in the second database. Additionally, the first database and the second database include a set of matching digital asset record sets.

[0339] In other embodiments, recording the first digital asset in the first database includes generating a first block for the first blockchain, the first block including a header and digital asset information. The message sent to the second data center computer includes the header but does not include the digital asset information. The second data center generates a second block for the second blockchain, the second block including the header but not including the digital asset information. Thus, the first block and the second block include the same header. The first database and the second database may include a set of matching block headers but do not include a set of matching digital asset information. The header may also be generated based on the hash of the digital asset information. The digital asset information may include information about the value, information about the sender, and information about the recipient. The value may include access rights.

[0340] The method may further include the first data center computer receiving a second digital asset from the second data center computer. The second data center computer processes the second digital asset and adds the second digital asset to the second database. The method also includes verifying the second digital asset and recording the second digital asset in the first database. The method may further include receiving a first digital asset, where the first digital asset is initially received and processed only by the first data center computer and where the second digital asset is initially received and processed only by the second data center computer. Additionally, the second data center computer may verify the first digital asset before recording the first digital asset in the second database.

[0341] Another embodiment of the invention relates to a first data center computer configured to perform the above method.

[0342] Another embodiment of the invention relates to a method that includes a first data center computer processing a first digital asset that indicates a transfer of a value from a sender to a recipient. The method also includes recording the first digital asset in a first database and sending a first message indicating that the first digital asset has been recorded to a second data center computer. The method further includes: receiving a second message from the second data center computer, the second message indicating that a second digital asset has been recorded by the second data center computer; and updating the first database based on the second message. The method additionally includes the second data center computer receiving the first message from the first data center computer, the first message indicating that the first digital asset has been recorded; and then updating the second database based on the first message. The second data center computer may also process the second digital asset, record the second digital asset in the second database, and send a second message indicating that the second digital asset has been recorded to the first data center computer. The first database and the second database may include matching data.

[0343] In some embodiments, the first message sent to the second data center computer includes a first digital asset, and the second data center records the first digital asset in a second database. Additionally, the second message includes a second digital asset, and updating the first database based on the second message includes recording the second digital asset in the first database. Additionally, the first database and the second database include a set of matching digital asset records.

[0344] In other embodiments, recording the first digital asset in the first database includes generating a first block for a first blockchain, the first block including a header and digital asset information. The message sent to the second data center computer includes the header but does not include digital asset information. The second data center generates a second block for a second blockchain, the second block including the header but not including digital asset information. Thus, the first block and the second block include the same header. The first database and the second database may include a set of matching block headers but do not include a set of matching digital asset information. The header may also be generated based on a hash of the digital asset information. The digital asset information may include information about a value, information about a sender, and information about a recipient. The value may include access rights.

[0345] The method may further include the first data center computer receiving a second digital asset from the second data center computer. The second data center computer processes the second digital asset and adds the second digital asset to the second database. The method also includes verifying the second digital asset and recording the second digital asset in the first database. The method may further include receiving a first digital asset, where the first digital asset is initially received and processed only by the first data center computer, and where the second digital asset is initially received and processed only by the second data center computer. Additionally, the second data center computer may verify the first digital asset before recording the first digital asset in the second database.

[0346] Another embodiment of the present invention relates to a system that includes a first data center computer and a second data center computer configured to perform the above method.

[0347] A computer system that can be used to implement any entity or component described herein will now be described. Subsystems in the computer system are interconnected via a system bus. Additional subsystems include a printer, keyboard, fixed disk, and 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 connected to the computer system by any number of means known in the art, such as a serial port. For example, a serial port or external interface can be used to connect a computing device to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via the system bus allows the central processor to communicate with each subsystem, control the execution of instructions from system memory or the fixed disk, and exchange information between subsystems. System memory and / or the fixed disk can embody computer-readable media.

[0348] 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 can 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 can 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 can be implemented by firmware or a dedicated processor, integrated circuit, etc.

[0349] Any software component or function described in this application can be implemented as software code executed by a processor using any suitable computer language (e.g., Java, C++, or Perl, for example), using, for example, traditional or object-oriented techniques. The software code can 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 can reside on or inside a single computing device and can be present on or inside different computing devices within a system or network.

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

[0351] 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 creating a record, the method comprising: creating, by a first data center computer, a first record in a first database, the first record comprising a first digital asset and a first record identifier; sending, by the first data center computer, a first message to a second data center computer, the first message indicating that the first record has been created, the first message comprising the first record identifier but not the first digital asset, wherein the second data center computer creates a second record in a second database, the second record comprising the first record identifier but not the first digital asset, and wherein the second data center computer does not receive the first digital asset; receiving, by the first data center computer, a second message from the second data center computer, the second message indicating that a third record has been created by the second data center computer, the second message comprising a third record identifier of the third record but not a second digital asset of the third record, and wherein the first data center computer does not receive the second digital asset; and creating, by the first data center computer, a fourth record in the first database, the fourth record comprising the third record identifier but not the second digital asset.

2. The method according to claim 1, wherein the first record identifier is a first hash, the third record identifier is a third hash, and the method further comprises: generating, by the first data center computer, the first hash based on the first digital asset, wherein the second data center computer generates the third hash based on the second digital asset and the first hash.

3. The method according to claim 1, wherein the first record identifier identifies the first record but does not provide any information about the first digital asset.

4. The method according to claim 1, wherein the first digital asset is received only by the first data center computer, and the second digital asset is received only by the second data center computer.

5. The method according to claim 1, wherein the first database and the second database have a common record identifier, but the record identifiers are in different orders.

6. The method according to claim 1, wherein the first database and the second database have a set of matching record identifiers in a matching sequence.

7. A first data center computer, comprising: a processor; and a non-transitory computer-readable medium comprising code executable by the processor to implement a method for creating a record, the method comprising: creating a first record in a first database, the first record comprising a first digital asset and a first record identifier; Send a first message to a second data center computer, the first message indicating that the first record has been created, the first message including the first record identifier but not including the first digital asset, wherein the second data center computer creates a second record in a second database, the second record including the first record identifier but not including the first digital asset, and wherein the second data center computer does not receive the first digital asset; Receive a second message from the second data center computer, the second message indicating that a third record has been created by the second data center computer, the second message including the third record identifier of the third record but not including the second digital asset of the third record, and wherein the first data center computer does not receive the second digital asset; and Create a fourth record in the first database, the fourth record including the third record identifier but not including the second digital asset.

8. The first data center computer according to claim 7, wherein the first database includes a first blockchain, the second database includes a second blockchain, the first record is a first block including a first block header and a first block body, the first block body including the first digital asset, the first block header including the first record identifier, the second record is a second block including a second block header, the second block header being the same as the first block header, the third record is a third block including a third block header and a third block body, the third block header including the third record identifier, the third block body including the second digital asset, the fourth record is a fourth block including a fourth block header, and the fourth block header being the same as the third block header.

9. The first data center computer according to claim 7, wherein the method further comprises: Generating, by the first data center computer, the first record identifier based on the first digital asset, wherein the second data center computer generates the third record identifier based on the second digital asset and the first record identifier.

10. The first data center computer according to claim 7, wherein the first digital asset includes information regarding a value transfer from a sending entity to a receiving entity.

11. The first data center computer according to claim 7, which further comprises: Receiving, by the first data center computer, a first digital asset transfer request including the first digital asset, wherein the first digital asset transfer request is received by the first data center computer from a routing computer, wherein the second data center computer has received a second digital asset transfer request including the second digital asset.

12. A method for creating a record, the method comprising: The second data center computer receives a first message from the first data center computer, the first message indicating that a first record has been created by the first data center computer at a first database, the first message including a first record identifier of the first record but not including a first digital asset of the first record, and wherein the second data center computer does not receive the first digital asset; The second data center computer creates a second record in a second database, the second record including the first record identifier but not including the first digital asset; The second data center computer creates a third record in the second database, the third record including a third record identifier and a second digital asset; And The second data center computer sends a second message to the first data center computer, the second message indicating that the third record has been created, the second message including the third record identifier of the third record but not including the second digital asset of the third record, wherein the first data center computer creates a fourth record in the first database, the fourth record including the third record identifier but not including the second digital asset, and wherein the first data center computer does not receive the second digital asset.

13. The method according to claim 12, wherein the first database includes a first blockchain, the second database includes a second blockchain, the first record is a first block including a first block header and a first block body, the first block body includes the first digital asset, the first block header includes the first record identifier, the second record is a second block including a second block header, the second block header being the same as the first block header, the third record is a third block including a third block header and a third block body, the third block header includes the third record identifier, the third block body includes the second digital asset, the fourth record is a fourth block including a fourth block header, and the fourth block header is the same as the third block header.

14. The method according to claim 12, wherein the first data center computer generates the first record identifier based on the first digital asset, and the method further includes: The second data center computer generates the third record identifier based on a second digital asset and the first record identifier.

15. The method according to claim 12, wherein the first record identifier is a first hash, and the third record identifier is a second hash.

16. The method according to claim 12, wherein the first record identifier identifies the first record but does not provide any information about the first digital asset, and the third record identifier identifies the third record but does not provide any information about the second digital asset.

17. The method according to claim 12, wherein the first digital asset is received by the first data center computer in a first transfer request, and the method further includes: The second transfer request including the second digital asset is received by the second data center computer from the routing computer, wherein the second transfer request is not received by the first data center computer, and wherein the first database and the second database do not have a set of matching digital assets.

18. The method according to claim 12, wherein the first database and the second database have a common record identifier, but the record identifiers are in different orders.

19. The method according to claim 12, wherein the first database and the second database have a set of matching record identifiers in a matching sequence.

20. The method according to claim 12, wherein the first digital asset includes information about a first value transfer from a first sending entity to a first receiving entity, and the second digital asset includes information about a second value transfer from a second sending entity to a second receiving entity.

Images