System and method for recording data representing multiple interactions

Abstract

A method for combining multiple interactions into a single record entry is disclosed. A data package representing a set of interactions can be created, and each entity associated with the interaction can view the data package. Each entity can indicate consent to the interaction by digitally signing the data package. Once signed by each participating entity, the data package can be stored in a record, such as a blockchain.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2018 / 027455, international application date April 13, 2018, application number 201880027081.0 entering the Chinese national phase, and name “System and method for recording data representing multiple interactions”.

[0002] Cross-reference to related applications

[0003] This application is a non-provisional of and claims the benefit of the filing date of U.S. Provisional Application No. 62 / 490,502, filed April 26, 2017, the entire contents of which are incorporated herein by reference for all purposes. Background Art

[0004] The blockchain network is designed so that multiple endpoint computers within the network can submit new information. When a computer submits new information to the blockchain, it is stored immutably. This way of storing information is useful in many scenarios.

[0005] For example, roommates can decide how to divide dorm cleaning duties. Roommate 1 might promise to sweep the floor. Roommate 2 might promise to take out the trash. To seal the agreement, both roommates can record their promises on the blockchain. That way, if either roommate disputes the other's promise, they can resolve the dispute by referring to the blockchain record.

[0006] However, blockchain technology is currently unsuitable for recording all types of information. For example, in some cases, multiple actors may work sequentially or otherwise contribute to the completion of a single project. However, in typical blockchain technology, each actor has a separate private key, meaning they can only make promises related to their own actions, not those of others. Therefore, a blockchain can only store each person's promise to complete a portion of a project, making it impossible to simply record the completion of the entire project.

[0007] For example, a house construction project is often divided into multiple phases, each completed by different operators. A groundskeeper might prepare the foundation, a plumber might install plumbing, an electrician might install wiring, a roofer might cover the roof, and so on. At best, each operator might enter their own promise to complete their task into the blockchain. This results in many different blockchain entries related to the house construction project, which are disconnected and difficult to track. As a result, it's difficult to verify the completion of each individual task, as well as the overall completion of the house.

[0008] Embodiments of the invention address these and other problems, individually and collectively. Summary of the Invention

[0009] Embodiments of the present invention provide systems and methods for merging multiple record entries into one entry and allowing multiple parties to contribute to a single record.

[0010] A first node computer may create a data package that defines multiple interactions, each associated with a different entity. For example, the data package may indicate a first interaction associated with the first node computer, a second interaction associated with the second node computer, a third interaction associated with the third node computer, and so on. The data package may contain several separate interactions that, when executed together, form a single, complete project.

[0011] Embodiments allow each node computer to individually receive, analyze, and approve a data packet. Each node computer can use its unique private key to generate a digital signature for the data packet. In some embodiments, digitally signing a data packet can indicate that the node computer agrees with the information in the data packet. Thus, the digital signature can serve as evidence that the node computer is committed to performing one or more operations indicated in the data packet.

[0012] Once each node computer associated with a data packet has approved the data packet and digitally signed it, the data packet and the generated digital signature can be added to the blockchain record.

[0013] One embodiment of the present invention relates to a method. The method includes receiving, by a management node computer, data representing multiple interactions from a first node computer. The multiple interactions include a first interaction associated with the first node computer and a second interaction associated with the management node computer. The method also includes receiving a first digital signature associated with the data representing the multiple interactions. The first digital signature is generated using a first private key associated with the first node computer. Additionally, the first digital signature indicates that the first node computer consents to the first interaction. The method also includes generating a second digital signature using a second private key associated with the management node computer. The second digital signature indicates that the management node computer consents to the second interaction. The method also includes creating a block of a blockchain, the block including the data representing the multiple interactions.

[0014] Another embodiment of the present invention relates to a management node computer configured to execute the above method.

[0015] Another embodiment of the present invention relates to a method, comprising generating, by a first node computer, data representing a plurality of interactions. The plurality of interactions include a first interaction associated with the first node computer and a second interaction associated with a management node computer. The method further comprises generating a first digital signature using a first private key. The first digital signature is associated with the data representing the plurality of interactions. In addition, the first digital signature indicates that the first node computer agrees with the first interaction. The method further comprises transmitting the data representing the plurality of interactions and the first digital signature to a management node computer. The management node computer then generates a second digital signature using a second private key, and the second digital signature indicates that the management node computer agrees with the second interaction. The management node computer also creates a block of a blockchain, the block including the data representing the plurality of interactions.

[0016] Another embodiment of the present invention relates to a first node computer configured to execute the above method.

[0017] More details about embodiments of the present invention can be found in the detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0021] Figure 4 An example of a node in a network according to an embodiment of the present invention is shown.

[0022] Figure 5 An example of atomic transaction according to an embodiment of the present invention is shown.

[0023] Figure 6 A block diagram illustrating account association according to an embodiment of the present invention.

[0024] Figures 7A-7C Shown is a flow chart illustrating a method for recording multiple interactions together simultaneously according to an embodiment of the present invention. DETAILED DESCRIPTION

[0025] Embodiments of the present invention provide systems and methods for simultaneously recording multiple interactions and allowing multiple parties to contribute to a single record. A first node computer (e.g., or other record submission entity) can generate a data packet containing information about multiple interactions. The first node computer can then transmit the data packet to each party responsible for one of the interactions (e.g., a management node). Each responsible party can then generate a digital signature for the data packet, their digital signature indicating that they guarantee that any interaction they are responsible for will be completed. Once each responsible party has approved and digitally signed the data packet, the data packet and digital signature can be added to the blockchain record.

[0026] Thus, several interactions can be recorded together, rather than submitted and recorded separately. Because a single record is validated and entered where multiple records might have previously been, recordkeeping efficiency is improved and record processing bandwidth is reduced. Additionally, data packages can contain information about related interactions, such as the different transfer steps in a payment transaction or the individual tasks that facilitated a construction project. Thus, a single data package can be used to record multiple parts of a larger project. This means better organization of record systems and allows entire projects to be identified by locating a single record entry.

[0027] Additionally, in some embodiments, a data packet may not be recorded (e.g., recorded in a blockchain record) until all responsible parties have approved and digitally signed it. This means that a responsible operator may not irreversibly commit to proceeding with an operation until every other operator has committed to theirs. For example, if a first operator digitally signs a data packet (e.g., indicating a pending commitment) and a second operator refuses to sign, the data packet can be deleted without being recorded, releasing the first operator from their pending commitment. Similarly, a project plan may not be finalized until each operator has committed to their portion. Thus, some operators may agree to a first draft of the plan, but not all. The plan may be iteratively revised until every operator agrees (e.g., by digitally signing) to the details outlined in the data packet before the plan is finalized and permanently recorded. Thus, embodiments of the present invention facilitate the creation of interaction records and plans by allowing individual operators to initially tentatively commit and then permanently commit once all operators agree.

[0028] Additional features that may be included in embodiments of the present invention are described in International Application No. US2017 / 046364 and International Application No. US2017 / 059744, which are incorporated herein by reference in their entirety for all purposes.

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

[0030] An “interaction” can include an activity, exchange, or communication. Examples of interactions include performing a task (e.g., installing a pipeline), transferring value (e.g., a payment transaction or transferring access rights), and providing updated information (e.g., medical records, academic records, etc.).

[0031] "Value" can include an amount of money, an asset, or a set of information that has value. For example, value can include a monetary amount, access rights, or login credentials. Value can change ownership by transferring it from one owner to a second owner. Examples of value transfers include payment transactions that transfer currency, such as game credits or mobile phone minutes, and property transfers that transfer event tickets or property deeds.

[0032] A "data packet" may refer to a collection of digital information. For example, a data packet may be information in a binary format. In some embodiments, a data packet may contain information about anything that may be described in a record (e.g., an interaction). For example, a data packet may contain any suitable type of digital information, such as activity data, ownership data, product status data, project update data, etc. Embodiments allow a data packet to contain data representing multiple interactions. For example, a data packet may contain digital information about multiple interactions, such as two or more payment transactions or two or more construction activities.

[0033] The term "node" may refer to a connection point. In some embodiments, a node may be a physical electronic device that is capable of creating, receiving, or transmitting data. In other embodiments, a node may be a software module on a computing device that is a connection point in a communication network. In some embodiments, a node may be a computing device within a record-keeping network. A node may create data packets, transfer data packets, receive data packets, verify data packets, access central records, and / or perform any other suitable function. Different types of nodes may be capable of performing different groups of functions in a record-keeping network. In some embodiments, a node may be associated with and / or operated by a financial institution computer (e.g., a bank), a payment processor computer, a third-party computer, or any other suitable entity.

[0034] A "record" can refer to evidence of one or more interactions. A digital record can be an electronic document of an interaction. A record can include a record identifier and record information. For example, the record information can include information describing one or more interactions and / or information associated with the interactions (e.g., a digital signature). The record information can also include multiple data packets, each of which contains different data describing a different number of interactions. A record identifier can be a number, title, or other data value used to identify a record. A record identifier can be non-descriptive in that 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 trade ledger, etc. Another example of a record is a block in a blockchain. A single block can be a single record, and a blockchain can 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.

[0035] The term "transaction ledger" may refer to a compilation of data from previous transactions. A transaction ledger may be a database or other comparable file structure that can be configured to store data from all previous transactions, including the date and time of the transaction, the transaction amount, and identification information of the participants in the transaction (e.g., the sender and recipient of the transaction amount). In some embodiments, the transaction ledger may be in the form of an electronic ledger (e.g., a blockchain), where data stored in the electronic ledger is immutable.

[0036] A "blockchain" can be a database that maintains a continuously growing list of records that is tamper-proof and revision-proof. A blockchain can contain multiple blocks of interaction records recorded on one or more nodes. 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 to the hash of the previous block. In other words, the interaction records in the blockchain can be stored as a series of "blocks," or a permanent file containing a record of several transactions that occurred within a given time period. After the block is completed and verified, it can be appended to the blockchain by the appropriate node. In embodiments of the present invention, the blockchain can be distributed, and a copy of the blockchain can be maintained at each node in the blockchain network.

[0037] A "key pair" can include a pair of associated encryption keys. For example, a key pair can include a public key and a corresponding private key. In a key pair, a first key (e.g., a public key) can be used to encrypt a message, while a second key (e.g., a private key) can be used to decrypt the encrypted message. In addition, a public key can verify a digital signature created with a corresponding private key. Public keys can be distributed throughout a network so that messages signed with the corresponding private key can be verified. The public and private keys can be in any suitable format, including formats 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 will be appreciated by those skilled in the art, other means can also be used to generate the key pair.

[0038] The term "digital signature" may refer to an electronic signature of a message. A digital signature may be a numeric data value, an alphanumeric data value, or any other type of data including a graphical representation. A digital signature may be a unique data value generated from a message and a private key using an encryption algorithm. In some embodiments, a verification algorithm employing a public key may be used to verify the signature.

[0039] An "enterprise identifier" may include an identifier for a user. For example, the enterprise identifier may be a globally unique identifier for an end user that submits new record information to a node in the recordkeeping network, or a globally unique identifier for an end user that receives information regarding new record information (e.g., a value transfer) from a node. In some embodiments, the enterprise identifier may also indicate a specific node associated with the user. The enterprise identifier may include alphanumeric characters, special characters, and any other suitable symbols.

[0040] An "address identifier" may include an identifier for a participant. For example, an address identifier may represent a node or service provider in a network. In some embodiments, communications may be directed to a specific node by including the address identifier for that node. An address identifier may include a string of characters, such as letters, numbers, etc. For example, an address identifier may be a string of 5, 10, 15, or any other suitable number of characters. In some embodiments, a public key associated with a participant may serve as the participant's address identifier.

[0041] A "category identifier" may include a data value representing a particular type of record. A category identifier may be used to identify any suitable category of recordable information. For example, a category identifier may be configured to identify medical information type records, academic qualification type records, product identifier type records, employee data type records, activity type records (e.g., construction activities, pipeline construction activities, etc.), various types of value transfer records (e.g., dollar payments, pound payments, RMB payments, digital copyright data transfers, property deed transfers, event ticket transfers, game points transfers, energy tax credit transfers, mobile phone airtime transfers, etc.), or any other suitable type of record. Categories may be divided in any suitable manner. In some embodiments, a category identifier may also indicate that a specific participant is authorized to create and / or receive data packets for records of the type described. A category identifier may include a string of characters, such as letters, numbers, etc. For example, an address identifier may be a string of 5, 10, 15, or any other suitable number of characters.

[0042] A "server computer" can include a powerful computer or a cluster of computers. For example, a server computer can be a mainframe, a cluster of minicomputers, or a group of servers operating as a unit. In one example, a server computer can be a database server coupled to a network server. The server computer can be coupled to a database and can include any hardware, software, other logic, or combination thereof for servicing requests from one or more client computers.

[0043] Figure 1 A system 100 is shown that includes several components. System 100 includes a record network managed by a management node computer 150. A first node computer 165, a second node computer 145, and any other suitable number of node computers participate in the network. A first user computer 110 operated by a first user (not shown) can submit record update instructions through first node computer 165, and a second user computer 130 operated by a second user (not shown) can receive record updates through second node computer 145. All computers shown in system 100 can be in operative communication with each other via any suitable communication channel or communication network. Suitable communication networks can be any one and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); Operational Mission as a Node on the Internet (OMNI); 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.), etc.

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

[0045] System 100 can be configured to create and maintain any suitable type of record. Management node computer 150 can manage the recordkeeping process by providing a number of services. For example, management node computer 150 can construct new blocks for the blockchain, containing updated record information. Management node computer 150 can also register nodes and end users and regulate the behavior of participating nodes to ensure that records are secure and reliable. Management node computer 150 can also verify new data packets and notify participating nodes of new interactions and blocks.

[0046] When the management node computer 150 can build and maintain records, the first node computer 165 and the second node computer 145 can submit new information to the management node computer 150 for recording. The first node computer 165 and the second node computer 145 can do this by creating and submitting data packets with various types of interactions. The first node computer 165 and the second node computer 145 can create data packets based on interaction instructions received from the first user computer 110 and / or the second user computer 130.

[0047] although Figure 1 Specifically described are a first node computer 165 and a second node computer 145, but the system 100 may include any suitable number of additional node computers (e.g., Figure 1 In addition, the first node computer 165 and the second node computer 145 can communicate with other user computers other than the first user computer 110 and the second user computer 130. In addition, the system 100 can include more than one management node computer 150 to manage the recording network.

[0048] The system 100 can be used to process, approve, and record any suitable type of information. For example, the system 100 can be used to record information about new interactions, such as new projects and activities, new value transfers, new medical patient data, new academic achievements, etc.

[0049] Furthermore, the system can combine multiple interactions into a single data packet, which can then be combined into a single blockchain record. For example, instead of submitting separate data packets for different interactions, the first node computer 165 can submit a single data packet containing information about multiple interactions. As described below, multiple nodes can provide their digital signatures to indicate approval of such a data packet, and the data packet can be delayed until each associated node provides its digital signature.

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

[0051] Record database 150C can store records. For example, data packets received from nodes in the network can be inserted into records and stored in record database 150C. In some embodiments, the records can take the form of a blockchain with block records, each block containing one or more data packets representing one or more interactions.

[0052] Node database 150D may include information about nodes, such as first node computer 165 and second node computer 145. For example, node database 150D may include an identifier, such as an address identifier and one or more category identifiers, associated with first node computer 165. Node database 150D may also include information about restrictions, such as spending limits, associated with different nodes.

[0053] The user database 150P may contain information about registered end users, such as a first user and a second user, and devices associated with the users (e.g., the first user computer 110 and the second user computer 130). This may include enterprise identifiers, as well as information about nodes associated with the users. For example, the enterprise identifier of the second user computer may be associated with an address identifier of the second node computer and a specific category identifier.

[0054] Key database 150Q can store encryption keys. For example, key database 150Q can contain the public key of each node and the private key associated with management node computer 150. In some embodiments, key database 150Q can take the form of a hardware security module (HSM).

[0055] The computer-readable medium 150E may include a registration module 150F, a verification module 150J, a signature module 150K, a record update module 150L, ​​a settlement module 150M, and any other suitable software modules. The computer-readable medium 150E may also include code that is executable by the processor 150A to implement a method, the method comprising: receiving data representing a plurality of interactions from a first node computer, the plurality of interactions including a first interaction associated with the first node computer and a second interaction associated with a management node computer; receiving a first digital signature associated with the data representing the plurality of interactions, the first digital signature being generated using a first private key associated with the first node computer and indicating that the first node computer agrees to the first interaction; generating a second digital signature using a second private key associated with the management node computer, the second digital signature indicating that the management node computer agrees to the second interaction; and creating a block of a blockchain, the block including the data representing the plurality of interactions.

[0056] The registration module 150F may include code that causes the processor 150A to register a node computer to join the network of record. For example, the registration module 150F may contain logic that causes the processor 150A to evaluate whether an entity is eligible for registration and what risk level to assign to the new entity. The risk level may be influenced by whether the entity is a well-known and reliable organization; whether it has established settlement accounts or other settlement processes; whether it is located in a risky country, etc. In addition to assigning risk levels, the management node computer 150 may also issue activity limits for the node based on the risk profile. The activity limits may include, for example, maximum transaction threshold limits and / or velocity limits, such as limits on the number of payment transactions or total transaction value that can be submitted within a certain time period (e.g., a day, a week, or a month).

[0057] The registration module 150F may also include instructions for generating and assigning a unique address identifier to a newly registered node. Additionally, there may be instructions for generating and assigning keys to newly registered nodes. For example, the management node computer 150 may generate a key pair for a node. The management node computer 150 may store public keys and provide private keys to node computers.

[0058] The registration module 150F may further include instructions for registering an end user. For example, the management node computer 150 may receive information about a new user from a node (e.g., name, address, account number, phone number, company profile, etc.), store the user information, and then assign a unique company identifier to the user. In some embodiments, the company identifier may include a subset of characters that indicates an associated node or address identifier of the node.

[0059] Verification module 150J may include code that causes processor 150A to verify a new data packet so that the data packet can be entered into the record. For example, verification module 150J may include logic that causes processor 150A to check that the data packet containing the address identifier and the class identifier are both valid and associated with the same node computer, and that the new data packet has not exceeded and will not currently exceed a limit associated with the submitted class identifier.

[0060] Verification module 150J may further include logic that causes processor 150A to verify that all entities associated with the data packet (e.g., one or more nodes and one or more users) have registered with the network and have been screened for eligibility. Management node computer 150 may also assess transaction risk, for example, by assessing the transaction speed of one or more parties involved, or by determining whether any warnings have been issued by the submitting node.

[0061] The verification module 150J may further include code that causes the processor 150A to verify the authenticity of one or more digital signatures. For example, the verification module 150J may contain logic that causes the processor 150A to use the public key of the node computer to verify the authenticity of the digital signature associated with the node computer.

[0062] Signature module 150K may include code that causes processor 150A to generate a digital signature. For example, signature module 150K may contain logic that causes processor 150A to generate a digital signature for a data packet using the management node's private key. The management node computer's digital signature can be used to indicate the authenticity of the data packet and provide assurance that the transfer is valid and trustworthy.

[0063] In some embodiments, a data packet may contain information about more than one interaction, and the digital signature of the management node computer may indicate that the management node computer 150 has committed to completing any interaction indicated as the management node computer's responsibility. For example, a data packet may describe two transactions, a first transaction comprising a first payment made by the first node computer 165 (e.g., to the management node computer 150) and a second transaction comprising a second payment made by the management node computer 150 (e.g., to the second node computer 145). Thus, even if the payer (e.g., the first node computer 165) does not complete the first payment, the digital signature of the management node computer may prove that the management node computer 150 will complete the second transaction and deliver the promised value to the recipient.

[0064] Additionally, each digital signature can activate a smart contract. For example, a first smart contract can hold first node computer 165 accountable for a first transaction, and a second smart contract can hold management node computer 150 accountable for a second transaction. After a certain amount of time, the smart contract can automatically initiate a settlement process. In some embodiments, management node computer 150 can force a settlement between two accounts at a central bank.

[0065] The record update module 150L may include code that causes the processor 150A to maintain and update the record set. For example, the record update module 150L may contain logic that causes the processor 150A to record information about new interactions (e.g., as indicated in a new data packet). In some embodiments, the record update module 150L may include instructions for including a new data packet having data representing multiple interactions (e.g., and associated digital signatures) in the next blockchain block.

[0066] The record update module 150L may further include instructions for notifying all parties associated with the interaction described in the new data packet when the data packet is created. For example, when verifying and signing a new payment transaction, the management node computer 150 may send information about the new payment transaction to a receiving node (e.g., the second node computer 145) and / or a user computer.

[0067] In some embodiments, participating node computers may not maintain separate sets of records, but instead may reference centrally maintained records maintained by management node computer 150. For example, first node computer 165 and second node computer 145 may each be a lightweight node. In this case, management node computer 150 may provide these nodes with real-time access to the central record, or management node computer 150 may provide regular record updates (e.g., updates may be sent every 10 seconds, every 1 minute, every 5 minutes, etc.). Thus, other nodes may be aware of new interactions immediately or soon after they are recorded.

[0068] In some embodiments, participating node computers may not be able to see all record information; they may only be able to view filtered records or records with permission. For example, when accessing records at management node computer 150, first node computer 165, second node computer 145, first user computer 110, and / or second user computer 130 may only be able to view interaction records associated with them (e.g., transactions to which they are a party). For example, second node computer 145 may be able to view all block headers, but may only be able to view block bodies and interaction records associated with it.

[0069] In some embodiments, there may be multiple management node computers 150, each of which receives and processes different data packets with information about different interactions and then updates its own records. These different management node computers can communicate with each other to share new records and confirm that their records contain the same interactions.

[0070] The settlement module 150M may include code that causes the processor 150A to settle the promised value between accounts. For example, the settlement module 150M may contain logic that causes the processor 150A to debit the first node's settlement account at the central bank for the amount indicated in the interaction record and credit the second node's settlement account for the same amount (or an amount less an assessed fee).

[0071] In some embodiments, settlement can be performed in multiple steps (e.g., due to the use of multiple transactions to transfer value). For example, a first settlement may include debiting a first amount indicated in a first interaction record from a settlement account of a first node and crediting the same first amount to a settlement account of a management node. Then, a second settlement may include debiting a second amount indicated in a second interaction record from a settlement account of a management node and crediting the same second amount to a settlement account of a second node. As a result, value is transferred from the first node to the second node via the management node.

[0072] In some embodiments, the second amount may be less than the first amount (e.g., due to transfer fees or exchange rates). In addition, the second amount may be settled using a different currency than the first amount (e.g., the first transaction may be settled between accounts in USD, while the second transaction may be settled in RMB). Figure 5-6 Describe other settlement details.

[0073] Return Reference Figure 1 As mentioned above, the first node computer 165 may participate in the record network by creating and submitting a new data packet with new interaction data to update the record on behalf of one or more users.

[0074] Figure 3 An example of a first node computer 165 according to some embodiments of the present invention is shown in The first node computer 165 includes a processor 165A, a network interface 165B, an identifier database 165C, a key database 165E, and a computer-readable medium 165F.

[0075] The identifier database 165C may store information about the identifier of the first node computer, such as an address identifier and one or more category identifiers. The identifier database 165C may also contain information about one or more users, such as an enterprise identifier, an associated category type, and / or a user account.

[0076] The key database 165E may store encryption keys. For example, the key database 165E may contain a private key associated with the first node computer 165 and a public key associated with the management node computer 150. In some embodiments, the key database 165E may take the form of a hardware security module (HSM).

[0077] The computer-readable medium 165F may include a registration module 165G, a user registration module 165K, a data packet module 165L, a node lookup module 165M, a value analysis module 165N, a signature module 165P, a record submission module 165Q, and any other suitable software modules. The computer-readable medium 165F may also include code that is executable by the processor 165A to implement a method, the method comprising: generating data representing a plurality of interactions, the plurality of interactions comprising a first interaction associated with a first node computer and a second interaction associated with a management node computer; generating a first digital signature using a first private key, the first digital signature associated with the data representing the plurality of interactions, the first digital signature indicating that the first node computer agrees to the first interaction; and transmitting the data representing the plurality of interactions and the first digital signature to the management node computer, wherein the management node computer generates a second digital signature using a second private key, the second digital signature indicating that the management node computer agrees to the second interaction, and wherein the management node computer creates a block of a blockchain, the block comprising the data representing the plurality of interactions.

[0078] Registration module 165G may include code that causes processor 165A to register with management node computer 150 to participate in the recording network. For example, registration module 165G may contain logic that causes processor 165A to send a registration request message containing information about the first node, such as an address, a bank identifier, a settlement account, and / or any other suitable information. Registration module 165G also includes instructions to receive and store an address identifier, a management node public key, a first node private key, one or more category identifiers, and any other suitable registration information from management node computer 150.

[0079] The user registration module 165K may include code that enables the processor 165A to facilitate registration of the end user. For example, the user registration module 165K may include logic that causes the processor 165A to provide user information (e.g., name, residential and / or business address, date of birth, telephone number, account number, account username, account password, email address, government-issued identification number, such as a driver's license number, passport number, or social security number) to the management node computer 150. The first node computer 165 may also receive and store a business identifier for the first user computer 110 from the management node computer 150 and provide the business identifier to the first user computer 110.

[0080] Data packet module 165L may include code that causes processor 165A to generate a new data packet. For example, data packet module 165L may contain logic that causes processor 165A to receive instructions from first user computer 110 and, based on the instructions, create a data packet for one or more interactions. The data packet may include any suitable information for entering a new record into the ledger. In the example of a payment transaction, the data packet may include information regarding the sending account, the receiving account, the money being sent, the money being received, and / or any other suitable information.

[0081] In some embodiments, a data packet can be created to contain information detailing multiple transactions. For example, a data packet can describe a first transaction (e.g., a first sender, a first recipient, a first currency type, a first amount, etc.) and a second transaction (e.g., a second sender, a second recipient, a second currency type, a second amount, etc.). Accordingly, the first node computer 165 can generate a data packet describing the multiple steps for transferring value to the recipient. As described below, the parties involved in the transfer can agree to the details in the data packet by providing a digital signature.

[0082] Node lookup module 165M may include code that causes processor 165A to identify a node based on a user. For example, node lookup module 165M may include logic that causes processor 165A to identify a second node computer based on the second user computer being indicated as the recipient of a transaction. For example, the address identifier of the second node may be identified based on a subset of characters contained in the second user's business identifier, or the address identifier may be associated with the second user's business identifier in a database (e.g., a database accessed at management node computer 150). Node lookup module 165M may also include instructions for adding the identified address identifier to a new data packet.

[0083] The value analysis module 165N may include code that causes the processor 165A to determine the value of the interaction. For example, the value analysis module 165N may contain logic that causes the processor 165A to determine a first amount in a first currency to be deducted from the first user computer 110 in order to deliver a second amount in a second currency to the second user computer 130. This determination may include looking up a current foreign exchange rate and calculating a transfer fee (e.g., both the current foreign exchange rate and the transfer fee may be provided by the management node computer 150). The amount to be debited in the first currency, the amount to be credited in the second currency, the currency exchange rate, and / or the assessed fee may be included in the new data packet.

[0084] Signature module 165P may include code that causes processor 165A to create a digital signature. For example, signature module 165P may contain logic that causes processor 165A to apply a private key and a mathematical algorithm to a data packet, thereby generating a digital signature for the data packet. The digital signature of the first node computer can serve as evidence that it is indeed the first node computer 165 that created and submitted the data packet. The digital signature of the first node computer can also indicate the first node computer's commitment to one or more interactions specified in the data packet. For example, by signing the data packet, the first node computer 165 may commit to completing a first payment transaction, in which a first value is transferred from the first node to the management node.

[0085] The record submission module 165Q may include code that causes the processor 165A to submit a new data packet with a new interaction for recording. For example, the record submission module 165Q may contain logic that causes the processor 165A to send the new data packet, the associated digital signature, and / or any other suitable information to the management node computer 150.

[0086] In some embodiments, first node computer 165 can provide additional services to users beyond submitting new data packets with new interactions within the recording network. For example, first node computer 165 can be a computer associated with a financial institution, hospital, government agency, academic institution, mobile phone service provider, or any other suitable service provider. Accordingly, in some embodiments, first node computer 165 can maintain an account on behalf of the user. The account can store identification information, medical records, academic records, financial information, or any other suitable details, depending on the type of service provider.

[0087] In embodiments where the first node computer 165 is associated with a financial institution, the first node computer 165 can store value on behalf of the user. The first node computer 165 can also provide value (e.g., provide payment) on behalf of the user. An example of a financial institution is an issuer, which generally refers to a corporate entity (e.g., a bank) that issues and maintains an account (e.g., a bank account) for a user.

[0088] In some embodiments, the first node computer 165 may represent a plurality of associated computers. For example, the functionality described above for network participation and functionality associated with banking services may be divided among several cooperating computers.

[0089] Return Reference Figure 1 As mentioned above, the second node computer 145 can participate in the recording network. In some embodiments, the second node computer 145 can verify the authenticity of the new data packet and can notify the second user computer 130 about the new interaction data in the data packet.

[0090] The second node computer 145 can verify that the new data packet is authentic in one or more ways. For example, the second node computer 145 can verify that the digital signature of the first node computer and the signature of the management node computer are both authentic (e.g., using their corresponding public keys).

[0091] In some embodiments, the second node computer 145 may only verify the authenticity of the signature of the management node computer, as the second node computer 145 may be affected by the operations of the management node. For example, the signature of the first node computer may only guarantee that the first node delivers value to the management node, which may not directly affect the second node. In contrast, the signature of the management node computer may only guarantee that the management node delivers value to the second node. Accordingly, the second node may only be related to the operations and signatures of the management node, and not to the operations and signatures of the first node.

[0092] In some embodiments, the second node computer 145 may verify the authenticity of the interaction and / or data packet by accessing a central record (e.g., a blockchain record) and confirming that the interaction and / or data packet has been added to the record.

[0093] The second node computer 145 is primarily described herein as a node that receives information about new interactions (e.g., via data packets) on behalf of the second user computer 130. However, in some embodiments, the second node computer 145 may include some or all of the functionality described above with respect to the first node computer 165. For example, the second node computer 145 may submit data packets with new interaction data to the recording network on behalf of the second user computer 130 or other associated users. Similarly, in some embodiments, the first node computer 165 may include some or all of the functionality described with respect to the second node computer 145 (e.g., the first node computer 165 may receive and verify data packets on behalf of the first user computer 110).

[0094] Similar to the first node computer 165, the second node computer 145 may also be associated with a service provider, such as a bank. Thus, the second node computer 145 may host a second user account and may store and receive value on behalf of the second user. For example, the second node computer 145 may be associated with an acquirer, which is typically a corporate entity (e.g., a commercial bank) that has a business relationship with a particular resource provider or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may encompass such a single-entity issuer-acquirer.

[0095] In some embodiments, the second node computer 145 can have a high level of trust: for example, due to two valid digital signatures, due to the data packet being included in a blockchain record, due to the data packet containing several associated identifiers (e.g., category identifiers and / or address identifiers), or due to any other suitable evidence, the promised value will be delivered. Thus, the second node computer 145 can make the value indicated in the received data packet immediately available (e.g., withdrawable) in the second user's account, even if the value has not yet been settled and received. Furthermore, because the management node can be a large, trusted central entity, the second node can have a high level of trust in the management node. As described above, the second node may only need to trust the management node because, if the first node does not follow up, the second node will not be affected. Accordingly, even using the management node's digital signature alone can provide a high level of trust for the second node.

[0096] As described above, multiple nodes can participate in the record network, and each node can send and receive data packets containing interaction data on behalf of multiple users. Users can be individuals, businesses, record update administrators of organizations, or any other suitable type of user. For example, the first user can be an individual, and the second user can be a resource provider (e.g., a merchant) participating in a transaction and selling goods or services or providing access to goods or services.

[0097] In some embodiments, an end user can be associated with multiple business identifiers. For example, a different business identifier can be assigned to a user for each different currency and bank associated with the user. A first user can have multiple accounts at the first node computer 165, each account in a different currency. Accordingly, the first user computer 110 can store a different business identifier for each currency type used by the first node computer 165. The first user can also participate in transactions using another account at a different bank node and have another business identifier associated with this additional bank.

[0098] Figure 4 In some embodiments, as shown in FIG. Figure 4 As shown, several nodes may be able to provide and receive data packets with interaction data within the recording network. An example transfer is shown in which a first node computer 165 is providing a data packet with interaction data (e.g., for a payment transaction) to a second node computer 145. As shown, the first node computer 165 can send the data packet to the management node computer 150, which can then forward the data packet to the second node computer 145. The management node computer 150 can also verify the data packet and digitally sign it before sending it to the second node computer 145. The recording network can include any other suitable number of node computers (e.g., which can act as senders and receivers) as well as additional management node computers. Each management node computer can maintain an interaction ledger of data packets that have been transferred between nodes, and the management node computers can update each other to maintain a synchronized ledger.

[0099] As mentioned above, in some embodiments, the recordkeeping system can utilize a blockchain. Each block in the blockchain can contain information about one or more interactions (e.g., from one or more data packets). The blockchain ledger can be altered only upon detection. This ensures that any tampering with information related to a transaction, such as an attempt to reallocate transaction value to an inappropriate entity, remains undetected. A block header and a block body containing transaction information (e.g., and any other suitable information) can together constitute a block.

[0100] As mentioned above, in some embodiments, data packets and record entries can contain information about multiple interactions. This can allow a single data packet and record entry to contain information about all necessary steps to complete an event (e.g., a payment transaction or project). For example, a construction project may involve several activities performed by several entities (e.g., plumbing by a plumber, electrical work by an electrician, etc.). When creating building plans and obtaining commitments from each worker, it would be beneficial to have a single data packet and record entry that describes each activity and reflects each worker's commitment, rather than having separate records for each activity and worker. In another example, a first node may not be able to send a payment directly to a second node (e.g., because they have no direct relationship). Alternatively, it may be necessary to split the payment into multiple component transactions (which may be referred to as atomic transactions), with a management node acting as an intermediary to facilitate the transfer of payment value. Similarly, it is more efficient to describe all atomic transactions together in a single data packet rather than recording them separately. Figure 5 An example of combining atomic transactions to transfer value from a sender to a receiver is shown in FIG.

[0101] Figure 5 The atomic transaction example in illustrates a technique for transferring value from a first node computer 165 to a second node computer 145, where the first node computer 165 and the second node computer 145 do not necessarily have a direct relationship or direct communication line. The net value transfer is accomplished using two separate, split transactions (referred to as atomic transactions). The first row represents the first atomic transaction. As shown in the first row, the first sub-transaction includes the first node computer 165 sending a first value V1, and the management node computer 150 receiving the first value V1. The second row represents the second transaction, where the management node computer 150 sends a second value V2, and the second node computer 145 receives the second value V2. Through the combination of atomic transactions, the first node computer 165 is able to effectively send the second value V2 to the second node computer 145. In some embodiments, the first value V1 and the second value V2 can be the same amount and / or the same currency. In other embodiments, they can be different currencies, and an exchange fee can be assessed during the conversion.

[0102] To initiate the transfer of value to the second node computer 145, the first node computer 165 may generate a data packet. The data packet may define two atomic transactions. For example, the data packet may include Figure 5The data packet may include information about the different transactions shown. In other words, the data packet may specify which entity is responsible for sending each value, which entity is to receive each value, the amount sent in each transaction, the type of currency (or other value category) used in each transaction, the specific accounts from which funds are withdrawn and to which funds are deposited, and / or any other suitable information. The data packet may also include information about possible exchange rates and / or conversion fees (e.g., information that may be maintained by the management node), both of which may be reflected in the difference between the first value V1 and the second value V2. The data packet may be verified and recorded and may serve as a promise of value. The actual transfer of value (e.g., settlement) may occur later.

[0103] like Figure 5 As shown, a data packet can be digitally signed by each entity responsible for the operations defined in the data packet. For example, as shown in the first row, first node computer 165 can provide a digital signature for the data packet, which indicates that the first node is committed to sending a first value V1 to management node computer 150. Additionally, as shown in the second row, management node computer 150 can provide a second digital signature (e.g., if management node computer 150 approves the transaction), which indicates that the management node is committed to sending a second value V2 to second node computer 145. Once all operators (e.g., first node computer 165 and management node computer 150) have signed the data packet, the data packet (or the transaction defined in the data packet) and the associated digital signature can be recorded in the ledger (e.g., published to a blockchain) to record both transactions.

[0104] Each atomic transaction can then be settled. For example, a first value, V1, can be withdrawn from the first node's account and credited to the management node's account, and a second value, V2, can be withdrawn from the management node's account and credited to the second node's account. Thanks to the management node's commitment, even if the first settlement fails, the second settlement can still be executed.

[0105] As mentioned above, other types of interactions can also be recorded together in a single data package. For example, a general contractor might draft plans for building a house. The general contractor might assign tasks to each type of skilled worker (e.g., architect, plumber, electrician, roofer, carpenter, mason, etc.), and each task might be defined in a data package. Each worker can review the data package and agree to the defined tasks and terms by providing a digital signature. If all workers agree and sign, the plan can be considered finalized, as there are no objections. Accordingly, the completed data package can be stored in a record (e.g., a blockchain record) so that information representing the promised activity cannot be manipulated, and interested parties can refer to the record and review what each worker agreed to (and confirm that the overall project will be complete when each task is completed).

[0106] For value transfers (e.g., payment transactions), settlement can occur in a variety of ways. Figure 6 Some settlement techniques are described, wherein a block diagram of a settlement account is shown. Figure 6 Several management node settlement accounts 605 are shown, including a first account 605A, a second account 605B, a third account 605C, and a fourth account 605D. These can represent accounts in different currencies, accounts in different regions, or backup accounts. For example, the first account 605A can contain US dollars, thus enabling the sending and receiving of value in US dollars, while the second account 605B can contain RMB, thus enabling the sending and receiving of value in RMB. Additional management node accounts 605 may also be included.

[0107] Figure 6 It also includes several settlement accounts associated with different nodes. For example, a first node account 610 may be associated with a first node computer 165, and a second node account 620 may be associated with a second node computer 145. A third node account 630, a fourth node account 640, a fifth node account 650, a sixth node account 660, a seventh node account 670, and an eighth node account 680 may each be associated with one or more additional node computers.

[0108] In some embodiments, all settlement accounts are funded and maintained at a central bank. The central bank may be associated with, in communication with, and / or operated by the management node. Thus, the management node computer 150 may control the settlement of transactions by communicating with the central bank. Other embodiments may alternatively use proxy accounts (e.g., accounts established between different nodes without a central bank), as well as other alternative settlement arrangements.

[0109] Figure 6 Each node account is shown connected (e.g., like a hub with spokes) to a central administrative node account 605. This demonstrates how the administrative node account 605 can serve as a common connection between different node accounts.

[0110] For example, a first node may not have a direct relationship with a second node, but may transfer value to the second node with the help of a management node and through the use of atomic transactions. The central bank may reduce the first transaction value from the first node account 610 and increase the first transaction value from the management node account (e.g., first account 605A). The central bank may then reduce the second transaction value from the management node account (e.g., second account 605B) and increase the second transaction value from the second node account 620.

[0111] Thus, the management node account 605 enables efficient transfer of payments from the first node account 610 to the second node account 620. Additionally, the use of multiple management accounts 605 enables payments to be withdrawn from the first node account 610 in a first currency (e.g., because the management node's first account 605A can receive value in the first currency) and credited to the second node account 620 in a second currency (e.g., because the management node's second account 605B can send value in the second currency).

[0112] In some embodiments, the system can utilize a net settlement practice. For example, at the end of the day, all transactions between the first node computer 165 and the second node computer 145 can be combined to determine a net amount that the first node computer 165 owes the second node computer 145 (and vice versa). For example, the first node computer 165 may owe the second node computer 145 a net amount of RMB 100,000. In the case of atomic transactions, this can actually mean determining a first net value (e.g., the net value of all atomic transactions between the first node computer 165 and the management node computer 150) and a second net value (e.g., the net value of all corresponding atomic transactions between the management node computer 150 and the second node computer 145). For example, the first node computer 165 may owe the management node computer 150 a net value of US$17,000, and the management node computer 150 may owe the second node computer 145 a net value of RMB 100,000. Once the net position is determined, a set of atomic settlement transactions can be conducted to transfer the net transaction value (e.g., a first settlement transaction between the first node account 610 and the management node's first account 605A, and a second settlement transaction between the management node's second account 605B and the second node account 620).

[0113] This netting transaction can occur between each node in the network. For example, netting can also be performed between the first node account 610 and the third node account 630, and a similar process can be repeated to transfer the net value from the first node account 610 to the third node account 630 (e.g., by using the management node account and atomic settlement transaction).

[0114] In some embodiments, the system can utilize a network-wide multilateral settlement practice in which a net position is calculated between each node account and the rest of the network. For example, a first node account 610 may have a net negative position relative to a second node account 620 (e.g., $95,000 payable), a net positive position relative to a third node account 630 (e.g., $27,000 receivable), and a net positive position relative to a third node account 630 (e.g., $43,000 receivable). Instead of settling each of these positions separately, they can all be combined so that a single lump sum transfer can be made between the first node account 610 and the first account 605A of the management node (e.g., sending $25,000). Similarly, a single lump sum transfer can be used to settle the positions of other node accounts.

[0115] In some embodiments, such multilateral settlement may not require a central administrative node account 605. For example, instead of determining the network's gross position between each node account and the central administrator account 605, the net position between all node accounts as a group may be determined (e.g., the first node account 610 is due $25,000, the second node account 620 is due RMB 13,000, the third node account 630 is due $9,600, etc.), and then they may be simultaneously credited or debited based on their respective net positions (e.g., without using the administrative node account 605 as an intermediary step).

[0116] Can be about Figures 7A-7C Method 700 according to an embodiment of the present invention will be described. Reference will also be made to some elements in other figures. In an embodiment of the present invention, the steps shown in method 700 may be performed sequentially or in any suitable order. In some embodiments, one or more of the steps may be optional.

[0117] The various messages described below can use any suitable form of communication. In some embodiments, the request or response can be in an electronic message format, for example, an email, a short message service (SMS) message, a multimedia message 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 point to any suitable location, for example, an email address, a telephone 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, for example, an email message and an SMS message.

[0118] In step S101, the first node computer 165 transmits a registration request message to the management node computer 150. The registration request message may include information about the first node computer 165 (e.g., address, organization name, bank identifier) ​​and / or any other suitable information. The registration request may also request permission to act as a node and to send and / or receive data packets containing new interaction data, as well as request permission to create data packets containing interaction data of a particular category.

[0119] In step S102, management node computer 150 registers first node computer 165 to participate in the recording network. Management node computer 150 may perform a risk analysis to verify whether first node computer 165 is sufficiently trusted to participate in the recording network. Management node computer 150 may then issue an address identifier and one or more category identifiers to first node computer 165.

[0120] The management node computer 150 may store information about the first node computer 165 (e.g., address identifier, bank name, etc.) and transmit a registration response message to the first node computer 165 indicating successful registration of the first node computer 165. The response message may include an address identifier and / or an issue identifier.

[0121] At this point, the management node computer 150 may also provide any suitable software (eg, a software development kit) to the first node computer 165 for interacting with the recording network.

[0122] At this time, or at any other suitable time, the first node computer 165 may also establish a settlement account at a central bank (e.g., a bank managed by the management node computer 150), or otherwise establish a settlement agreement (e.g., using a correspondent bank with a central settlement account). The first node computer 165 may indicate in the registration response message that a settlement account has been established for one or more currency types.

[0123] By registering with the management node computer 150 and establishing a settlement account, the first node computer 165 effectively establishes a direct interaction relationship with the management node computer 150. The first node computer 165 and the management node computer 150 can communicate directly, issue payment promises to each other, and transfer funds to each other using the settlement account, thereby establishing mutual trust.

[0124] Second node computer 145 can create a similar trust relationship by registering and establishing a settlement account with management node computer 150. Thus, management node computer 150 can become a common link between first node computer 165 and second node computer 145, such that management node computer 150 can facilitate the transfer of value from first node computer 165 to second node computer 145 (e.g., using two atomic transaction steps) even when first node computer 165 and second node computer 145 do not have a direct relationship or otherwise trust each other.

[0125] Additionally, after registration, the first node computer 165 can facilitate the end user's registration. The first user may want to use the network of record and can use the first user computer 110 to transmit a registration request to the first node computer 165, along with the currency type the first user wants to use for transactions.

[0126] In step S103, the first node computer 165 may transmit a registration request message on behalf of the first user to the management node computer 150. The first node computer 165 may provide the management node computer 150 with any suitable information about the first user, such as name, address, organization information, payment account information (e.g., balance and currency type), credit score, etc.

[0127] At step S104 , the management node computer 150 may determine whether to enroll the first user (eg, based on the risk profile). The management node computer 150 may also generate and issue an enterprise identifier for the first user computer 110 .

[0128] In some embodiments, the enterprise identifier may only be used for a certain record category and for data packets submitted by the first node computer 165. Additionally, in some embodiments, a subset of the enterprise identifier (e.g., 5 characters) may be formatted to indicate an association with the first node computer 165 and / or a record category.

[0129] The management node computer 150 may transmit the new enterprise identifier of the first user computer back to the first node computer 165. Next, at step S105, the first node computer 165 may store the enterprise identifier (e.g., associated with the first user's account) and forward the enterprise identifier to the first user computer 110.

[0130] After registering and obtaining the business identifier, the first user computer 110 can now initiate the recording of new interaction data. For example, if the business identifier is associated with the use of currency, the first user computer 110 can now send a payment to another user through the blockchain network.

[0131] At step S106, the first user computer 110 transmits a record request to the first node computer 165. For example, the first user computer 110 may submit a request to send a payment to the second user computer 130. The record request may include an enterprise identifier of the first user computer, an enterprise identifier of the recipient (e.g., the second user computer), and record update information for a specific record category.

[0132] In the case of a payment transaction, the record update information may include the currency type used as the payment source, the currency type delivered to the recipient, and the amount of currency delivered to the recipient. For example, a first user may wish to send a payment of 1,000 Singapore dollars to a second user, but the first user may wish to make the payment from a US dollar account.

[0133] In step S107, first node computer 165 determines the node associated with second user computer 130 so that the data packet containing the interaction data can be addressed to the node. For example, in some embodiments, first node computer 165 may communicate with management node computer 150 to query the node and / or recipient associated with the enterprise identifier of the second user computer and to verify the enterprise identifier of the second user computer. In some embodiments, first node computer 165 may use a locally stored lookup table to identify the node associated with the enterprise identifier of the second user computer. In other embodiments, first node computer 165 may resolve the enterprise identifier of the second user computer to determine the address identifier of the second node computer.

[0134] At step S108, first node computer 165 generates data representing a plurality of interactions. The data may be formatted into data packets that can be entered into a record. The plurality of interactions may include a first interaction associated with first node computer 165 (e.g., transferring a first value from a first node to a management node) and a second interaction associated with management node computer 150 (e.g., transferring a second value from a management node computer to a second node computer). These two interactions may be combined to complete the payment transfer requested by first user computer 110.

[0135] For example, the first node computer 165 may determine that in order to send a payment of 1,000 Singapore dollars to the second user (or the second user's bank), two transactions are required. The first node computer 165 may also determine the amount of source funds required to send the payment (e.g., based on an exchange rate and / or conversion fee). The first transaction may be used to extract source funds (e.g., $779) from the first node's account and provide those funds to the management node account. The second transaction may be used to extract delivery funds (e.g., 1,000 Singapore dollars) from the management node account and provide the funds to the second node's account. Thus, a data packet may contain data representing multiple interactions designed to efficiently transfer value from the first node computer to the second node computer.

[0136] The data packet may include any suitable information for describing the multiple atomic transactions. For example, in addition to the account, amount, currency type, etc. mentioned above, the data packet may also include the enterprise identifier of the first user computer, the enterprise identifier of the second user computer, the address identifier and / or category identifier of the first node computer, the address identifier and / or category identifier of the second node computer, and / or any other suitable information.

[0137] In step S109, the first node computer 165 generates a first digital signature associated with the data representing the plurality of interactions. For example, the first node computer 165 may generate a one-way hash using some or all of the information in the data packet and then encrypt the hash using a private key (e.g., a first private key associated with the first node computer 165). The hash data value and / or the digital signature may be attached to the data packet, thereby making data tampering of the data packet obvious. The presence of the first digital signature may indicate that the first node computer 165 agrees with the information in the data packet (e.g., the first interaction). Since the data packet may contain information about the first payment sent by the first node computer 165, the first digital signature may indicate that the first node computer 165 has committed to provide the first payment (or otherwise guarantees that the payment will be provided).

[0138] In step S110 , the first node computer 165 transmits data representing the plurality of interactions and the first digital signature to the management node computer 150 for verification and entry into the blockchain record.

[0139] In step S111, the management node computer 150 may verify the digital signature and / or hash value of the first node computer. For example, the management node computer 150 may perform a checksum procedure on the hash value. This may include generating a second hash value based on the data packet and checking that the second hash value matches the received hash value. The management node computer 150 may verify the digital signature using the public key of the first node computer. If the hash or digital signature cannot be verified, the management node computer 150 may reject the data packet.

[0140] The management node computer 150 can also verify that the class identifier and address identifier of the first node computer are both valid and associated with the first node computer 165. The management node computer 150 can also verify that the class identifier is used correctly. For example, if the data packet contains transaction data for sending value from a US dollar account, the management node computer 150 can verify that the class identifier of the first node computer is still associated with the use of US dollars.

[0141] If step S111 and any other appropriate verification steps have been successfully completed, the management node computer 150 may regard the data packet as valid and may be confident that the first node computer 165 will follow through with the promised first payment.

[0142] At step S112, management node computer 150 generates a second digital signature for the data packet (e.g., using a private key associated with management node computer 150). The presence of the second digital signature may indicate that management node computer 150 agrees with the information in the data packet (e.g., the second interaction). Because the data packet may include information about the second payment sent by management node computer 150, the second digital signature may indicate that management node computer 150 has committed to provide the second payment (or otherwise guarantees that the second payment will be provided). In some embodiments, the second digital signature may indicate that the second value will be transferred even if the first value is not transferred (e.g., because first node computer 165 failed to deliver the first value).

[0143] In step S113, management node computer 150 may add information about the interaction (and / or the entire data packet) to the record. For example, management node computer 150 may create a new block of the blockchain that contains data representing multiple interactions (e.g., along with one or more other new data packets) and a digital signature. Thus, a single record entry can be used to record multiple related transactions. Furthermore, a single entry into the blockchain ledger can indicate that two (or more) different entities have committed to two (or more) different interactions. Data packets and record entries may also contain information indicating that different atomic transactions are designed to work together to achieve a specific result.

[0144] At step S114 , the management node computer 150 may transmit a copy of the data packet to the second node computer 145 (e.g., to notify the second node computer 145 of the transaction). The management node computer 150 may also make the blockchain record accessible to the second node computer 145.

[0145] In step S115, the second node computer 145 can verify the authenticity of the data packet. For example, the second node computer 145 can confirm that the data packet has been entered into the blockchain record (e.g., by accessing the blockchain record at the management node computer 150). The second node computer 145 can also verify that the data packet contains two digital signatures: one from the first node computer 165 and one from the management node computer 150. The second node computer 145 can also check that the management node computer 150 (or other trusted entity) is the management node computer responsible for providing the final value to the second node computer 145, and that the management node computer 150 has explicitly agreed to deliver the final value (e.g., through a digital signature). The second node computer 145 can also verify the digital signature (e.g., using an appropriate public key). All of these verifications combined can create a high level of confidence in the authenticity of the data packet, as well as a high level of confidence that the promised interaction will be completed (e.g., even if there is a problem with the first node computer 165).

[0146] At step S116, the second node computer 145 may update its local records based on the data packet. For example, the second node computer 145 may credit the second user's bank account with the promised transaction value (e.g., as indicated in the data packet). Because a high level of trust may exist in the interaction, the second node computer 145 may credit the second user's account so that funds can be withdrawn before the transaction value between the management node account and the second node account is actually settled.

[0147] Later, a number of steps may be taken to settle the transaction value specified in the data packet. The management node computer 150 may send instructions (e.g., data packets) to the central bank so that the central bank can perform the settlement (e.g., as described above with respect to Figure 6 In some embodiments, the central bank computer may access records maintained by the management node computer 150 (e.g., a blockchain ledger) and may analyze the records to determine the settlement transactions to be completed. The central bank computer may review instructions and / or data packets to determine two (or more) planned payment transactions to be completed.

[0148] At step S117, a first transaction may be executed. For example, the central bank computer may perform a funds transfer as specified in the first transaction in the data packet. This may include debiting a first value from the first node's settlement account and then crediting the same first value to the management node's settlement account.

[0149] At step S118, a second transaction may be executed. For example, the central bank computer may perform a funds transfer as specified in the second transaction in the data packet. This may involve debiting a second value from the management node's settlement account and then crediting the same second value to the second node's settlement account. As described above, the second value may have a different amount and / or currency than the first value.

[0150] Accordingly, while the interaction (eg, payment) is promised and agreed upon by the first node computer 165 and the management node computer 150, the actual transfer activity may be performed by the central bank computer (or other suitable entity).

[0151] As mentioned above about Figure 6 As described, embodiments also allow for batch settlement (e.g., at the end of the day) for multiple transactions associated with multiple data packets. Additionally, multilateral settlement can be performed by calculating the net position between each node and the rest of the network, eliminating the need for separate settlements for each node-to-node pair.

[0152] Embodiments of the present invention have many advantages. For example, in embodiments of the present invention, a single data packet can be used to define multiple interactions. Instead of recording sets of interactions separately and having to repeat the recording process for each interaction, multiple interactions can be defined, processed, and recorded together. For example, a data packet can be created to contain information about several interactions (e.g., instead of just one interaction), and the data packet can be passed to each participating entity so that it can be reviewed, approved, and / or digitally signed by each participating entity (e.g., instead of just one entity) before being recorded. Thus, the work of recording sets of interactions is consolidated and reduced, the efficiency of recording interactions is improved, and the bandwidth used when processing a set of interactions is reduced.

[0153] Additionally, related sets of interactions can be recorded as bundles, allowing related data to be grouped together. This improves the organization and accessibility of the entire record. For example, in the example of a construction project, a single data package representing the entire project can be created, and this data package can contain information about the multiple tasks required to complete the project. Each operator can review and approve the data package (e.g., digitally sign the data package), and the data package and associated digital signature can then be entered into the blockchain record. Thus, all tasks for a construction project can be found by looking up a single data package in the blockchain record. This makes it easy to review each task, verify that all necessary tasks to complete the project have been assigned, and verify that each operator has committed to completing the assigned tasks (e.g., by checking their digital signatures).

[0154] Embodiments of the present invention also advantageously enhance the trustworthiness of blockchain ledgers. A central trusted administrator can register each node and end user, track participant behavior (e.g., detecting unusual activity), and ensure that participants do not exceed spending limits. Furthermore, each data packet can be digitally signed by both the submitting and management nodes, and the management node can enter new data packets into the secure blockchain. Receiving nodes can thus be assured that numerous security checks have been completed, that data packets have not been erased or altered, and that they are legitimate and trustworthy.

[0155] Furthermore, in instances where a record entry contains a promise to pay, the receiving node can be confident that the promised value will be delivered for a number of reasons. For example, the payment transaction can be split into two atomic transactions, and the ultimate delivery of the value to the receiving account can be the responsibility of the management node. The receiving node may have a direct relationship with the management node and a high level of trust in the management node (e.g., as opposed to the potentially unknown sending node), and therefore can be confident that the management node will follow through with the final payment even if the original sending node does not follow through with the first payment step.

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

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

[0158] Any software components or functions 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), 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 drive or floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium can reside on or within a single computing device and can be present on or within different computing devices within a system or network.

[0159] While certain exemplary embodiments have been described in detail and shown in the drawings, it is to be understood that such embodiments are merely illustrative of the invention and not restrictive, and that the invention is not limited to the specific arrangements and constructions shown and described, since various other modifications may occur to those skilled in the art.

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

Claims

1. A method comprising: receiving, by a second node computer, a data packet defining a plurality of interactions, the plurality of interactions comprising a first interaction associated with a first node computer and a second interaction associated with a management node computer, wherein the first interaction comprises sending a first value from a first account associated with the first node computer to a second account associated with the management node computer, wherein the second interaction comprises sending a second value from the second account associated with the management node computer to a third account associated with the second node computer, and wherein the management node computer creates a block of a blockchain, the block comprising the data packet; receiving, by the second node computer, a digital signature associated with the data packet, the digital signature being generated using a private key associated with the management node computer, the digital signature indicating a protocol for interaction between the management node computer and the second; as well as The digital signature is verified by the second node computer using a public key associated with the management node computer, the public key corresponding to the private key.

2. The method of claim 1, wherein the plurality of interactions are designed to, in combination, send the second value from the first node computer to the second node computer.

3. The method of claim 1 , wherein the digital signature is a second digital signature, the private key is a second private key, and the method further comprises: A first digital signature associated with the data packet is received by the second node computer, the first digital signature being generated using a first private key associated with the first node computer, and the first digital signature indicating a protocol of the first node computer and the first interaction.

4. The method of claim 3, wherein the public key is a second public key, and further comprising: The first digital signature is verified by the second node computer using a first public key associated with the first node computer, the first public key corresponding to the first private key.

5. The method of claim 1 , further comprising: The second node computer verifies that the data packet has two digital signatures.

6. The method of claim 1 , further comprising: The second node computer verifies that the data packet is entered into the block chain.

7. The method of claim 1, wherein the data packet is received from the management node computer, and the data packet is generated by the first node computer.

8. The method of claim 1 , further comprising: The second node computer updates a local record based on the data packet.

9. The method of claim 1 , further comprising: In response to verifying the digital signature, a third value is provided by the second node computer to a fourth account associated with the user, wherein the third value is equal to the second value.

10. The method of claim 9, wherein providing the third value to the fourth account associated with the user occurs before receiving the second value from the second account associated with the management node computer. The method of claim 1 , wherein the first value is the same as the second value.

12. The method of claim 1, wherein the digital signature indicates that the second value will be sent even if the first value is not sent.

13. The method of claim 1, wherein the management node computer generates the digital signature by digitally signing at least some information of the data packet using the private key.

14. The method of claim 1, wherein the block further comprises the digital signature.

15. The method of claim 1, wherein the data packet is a first data packet, the plurality of interactions is a first plurality of interactions, and the block further comprises a second data packet defining a second plurality of interactions different from the first plurality of interactions.

16. A second node computer, comprising: processor; as well as A computer-readable medium comprising code executable by the processor for implementing the method according to any one of claims 1 to 15.

17. A first node computer, comprising: processor; as well as A computer-readable medium comprising code executable by the processor for implementing a method comprising: generating a data packet defining a plurality of interactions, the plurality of interactions comprising a first interaction associated with the first node computer and a second interaction associated with a management node computer, wherein the first interaction comprises sending a first value from a first account associated with the first node computer to a second account associated with the management node computer, and wherein the second interaction comprises sending a second value from the second account associated with the management node computer to a third account associated with a second node computer; generating a first digital signature associated with the data packet using a first private key, the first digital signature indicating a protocol for the first node computer to interact with the first node; as well as The data packet and the first digital signature are sent to the management node computer, wherein the management node computer generates a second digital signature using a second private key, the second digital signature indicating a protocol of interaction between the management node computer and the second, and wherein the management node computer creates a block of a block chain, the block including the data packet.

18. The first node computer of claim 17, wherein the plurality of interactions are designed to, in combination, send the second value from the first node computer to the second node computer.

19. The first node computer of claim 17 or claim 18, wherein the first digital signature activates a first contract associated with the first interaction, and wherein the second digital signature activates a second smart contract associated with the second interaction.

20. The first node computer according to claim 17 or claim 18, wherein generating the first digital signature comprises digitally signing at least some information of the data packet using the first private key.

Images