RU2772232C2 - Systems and methods for creating multiple records on the basis of an ordered smart contract - Google Patents

Abstract

FIELD: multiple records creation.

SUBSTANCE: invention relates to methods and computers for creating multiple records based on an ordered smart contract. The method receives, by means of the administrative host computer, a smart contract indicating that an ordered set of interactions will take place in response to an ordered set of events, wherein the smart contract indicates that each interaction in the ordered set of interactions corresponds to an event in the ordered set of events, wherein the smart contract indicates that each interaction in the ordered set of interactions will take place in response to the corresponding event only if the corresponding event occurs within a particular order of events; receiving, by means of the administrative node computer, a first notification that a first event of the ordered set of events has occurred; verifying by the smart contract-based administrative node computer that the first event must occur first within the ordered set of events; determining by the administrative node computer based on the smart contract that the first interaction from the ordered set of interactions should take place in response to the first event; in response to the first event from the ordered set of events, transmitting by means of the computer of the administrative node to the computer of the second node an instruction to generate the first data packet for the first interaction from the ordered set of interactions, and the smart contract indicates that the first interaction will take place in response to the first event; receiving by means of the administrative node computer from the computer of the second node the first data packet for the first interaction; generating, by means of the administrative node computer, a first block for the block chain, the first block including a first data packet for the first interaction; receiving, by means of the administrative node computer, a second notification that a second event from the ordered set of events has occurred; verifying by the smart contract-based administrative node computer that the second event should occur second within the ordered set of events; determining by the administrative node computer based on the smart contract that a second interaction from the ordered set of interactions is to take place in response to the second event; in response to the second event from the ordered set of events, sending from the computer of the administrative node to the computer of the second node an instruction to generate a second data packet for the second interaction from the ordered set of interactions, and the smart contract indicates that the second interaction will take place in response to the second event; receiving by the administrative node computer from the second node computer a second data packet for a second interaction; and generating, by means of the administrative node computer, a second block for the block chain, the second block including a second data packet for the second interaction.

EFFECT: invention ensures the orderly formation of blocks for the block chain.

10 cl, 11 dwg

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is an international application and claims priority of the filing date of U.S. Provisional Application No. 62/519802, filed June 14, 2017, which is incorporated herein by reference in its entirety for all purposes.

BACKGROUND OF THE INVENTION

[0002] Blockchain record systems are designed to securely record information. When a computer submits new information to the block chain (blockchain), the information becomes irrevocably stored.

[0003] Typically, block chain record systems allow anyone to add new data to the block chain. This open access can be useful because it allows multiple users to contribute to a record, rather than just one. However, open access in blockchain record systems can create vulnerabilities related to receiving incorrect data and/or having disorganized records.

[0004] To illustrate, consider a physical dispatch process that involves three different transport segments. The first segment may represent a transport from point A to point B, the second segment may represent a transport from point B to point C, and the third segment may represent a transport from point C to point D. When the transport segment completes, a new block chain entry may be set up to monitor the progress of a shipment. However, in the case of a typical block chain record system, it is possible to record that the second transport segment is completed before recording that the first transport segment is completed. This makes the recording intelligible and inaccurate, since the second segment cannot physically be completed before the first segment.

[0005] Whether such entry was fraudulent or accidental, it causes the block chain entry to become disorganized and potentially incorrect. An error of this kind cannot be corrected, since once information has been added to the block chain, it cannot be changed.

[0006] At best, the first transport segment could be completed, but it has not yet been reported. That segment could be reported at a later time. However, the block chain will now still show that the second segment was completed at an earlier time than the first segment.

[0007] Embodiments of the present invention address these and other problems individually and collectively.

SUMMARY OF THE INVENTION

[0008] Embodiments of the present invention provide systems and methods for creating a smart contract (smart contract) that specifies a specific order for a set of events, as well as new records to be created in response to events. The smart contract thus provides a filter for new entries fed into the block chain entry. If an event appears to occur out of order, or a new record item is otherwise served out of order, the record may be rejected and not added to the block chain. As a result, block chain records are created and maintained in an organized and consistent manner.

[0009] One embodiment of the present invention is directed to a method. The method includes receiving a smart contract indicating that the ordered set of interactions will take place in response to the ordered set of events, and in response to the first event from the ordered set of events, sending an instruction to generate the first data packet for the first interaction from the ordered set of interactions to the computer of the second node. . The smart contract specifies that the first interaction will take place in response to the first event. The method also includes receiving the first data packet for the first interaction from the computer of the second node and generating the first block for the block chain. The first block contains the first data packet for the first interaction. The method further includes transmitting an instruction for generating a second data packet for a second interaction from the ordered interaction set to the computer of the second node in response to a second event from the ordered event set. The smart contract specifies that the second interaction will take place in response to the second event. The method also includes receiving a second data packet for the second interaction from the computer of the second node and generating a second block for the block chain. The second block contains the second data packet for the first interaction.

[0010] Yet another embodiment of the present invention is directed to an administrative node computer adapted to perform the method described above.

[0011] Yet another embodiment of the present invention is directed to a method including generating a smart contract indicating that an ordered set of interactions will take place in response to the ordered set of events, and generating a first data packet for a first interaction from the ordered set of interactions in response to the first an event from an ordered set of events. The smart contract specifies that the first interaction will take place in response to the first event. The method also includes transmitting the first data packet to the administrative node computer. The administrative host computer generates the first block for the block chain, and the first block contains the first data packet. The method further includes generating a second data packet for a second interaction from the ordered set of interactions in response to a second event from the ordered set of events. The smart contract specifies that the second interaction will take place in response to the second event. The method also includes sending the second data packet to the administrative node computer. The admin host computer creates a second block for the block chain, and the second block contains the second data packet.

[0012] Another embodiment of the present invention is directed to a second node computer adapted to perform the method described above.

[0013] Additional details regarding embodiments of the present invention can be found in the DETAILED DESCRIPTION section and in the figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG. 1 shows a block diagram of a system according to an embodiment of the present invention.

[0015] FIG. 2 is a block diagram of an administrative node computer according to an embodiment of the present invention.

[0016] FIG. 3 is a block diagram of a second node computer according to an embodiment of the present invention.

[0017] FIG. 4 shows an example of a smart contract according to an embodiment of the present invention.

[0018] FIG. 5A-5G are block diagrams illustrating a method for creating records based on an ordered smart contract, in accordance with embodiments of the present invention.

IMPLEMENTATION OF THE INVENTION

[0019] Embodiments of the present invention provide systems and methods for creating an ordered smart contract. A smart contract may contain details about the sequence of expected future events and may specify the order in which they are expected to occur. The smart contract may further contain details about the sequence of entries to be created in response to events. Each event can have one or more corresponding entries.

[0020] The smart contract may be enforced by the administrative node computer. The admin host computer can also generate the blockchain entry and thus can act as a gatekeeper, ensuring that the entries are only created as specified by the smart contract. As a result, block chain records are created in an organized and meaningful way.

[0021] In some embodiments, different node computers may send notifications to the administrative node computer when different events occur. Each node computer could pre-register with the record keeping network by communicating with the administrative node computer, and the administrative node computer could provide each node computer with a unique private key for future communications. As a result, each event notification can be digitally signed using a private key so that the administrative host computer can verify the authenticity of the notification. The notification can serve as a trigger for the subsequent creation of a record (for example, based on a smart contract).

[0022] In some embodiments, events may be services and new entries may be specific to payment transactions provided for the services. For example, a data packet may be created with information defining a payment transaction, and the data packet may be written to a block chain. In this way, a smart contract can ensure that payments are made only if the corresponding service or task is done within a predetermined order.

[0023] Embodiments also apply to other types of events and records. For example, events may contain tasks associated with a medical procedure, such as surgery, and new entries may represent updates to the surgical log or patient medical data. As another example, events can contain specific tasks within a construction project (for example, build a foundation, install plumbing, install electrical wiring, etc.), and new entries can represent updates to the status of the project. Thus, the embodiments may apply to any suitable process in which events or activities are to occur in a specific order and/or in which events or activities are performed by different entities.

[0024] Additional features that may be included in embodiments of the present invention are described in international application US2017/046364, in international application US2017/059744 and in international application US2018/027455, each of which is incorporated by reference herein throughout in its entirety for all purposes.

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

[0026] An "event" may include a moment when something happens, an episode, or a moment when something happens. More specifically, an event may be an action, activity, or task performed by an actor. Examples of events include sending a package or viewing a package, creating an insurance policy, digging under a foundation under construction, performing a medical examination, and any other appropriate type of work done.

[0027] "Interaction" may include an exchange or communication. Exemplary interactions include transferring a value (eg, a payment transaction or transferring access privileges) and providing updated information (eg, medical records, educational records, etc.).

[0028] A "smart contract" may be computer-executable instructions adapted to instruct a processor to enforce a policy, agreement, or obligation. A smart contract can be used to represent an agreement between two or more parties in which the terms of the smart contract are written in computer language as a set of instructions. Smart contracts may contain a set of policies that must be enforced in order for a transaction to take place between two or more parties. A smart contract can be distributed among one or more blockchain network nodes, which can automatically execute smart contracts.

[0029] In some embodiments, a single smart contract may comprise computer-executable instructions adapted to direct the processor to enforce a plurality (eg, two or more) of policies, agreements, or obligations. Such a smart contract can be used to represent an agreement between two or more sets of two or more parties. Within a smart contract with multiple policies, each policy can include an event. When an event is fired, the corresponding interaction can be fired. Thus, a smart contract may define a set (eg, two or more) of events, as well as a set of interactions that should take place when specific events occur. This type of smart contract may contain information specifying that events (and/or corresponding interactions) must be performed in a specific order. If events do not fire according to a predefined order, one or more interactions may not fire.

[0030] "Data Packet" may refer to a collection of digital information. For example, a data packet may be information that exists in a binary format. In some embodiments, the data packet may contain information about something that can be described in the record. For example, a data packet may contain any suitable type of digital information, such as ownership data, product status data, project update data, payment transaction data, etc.

[0031] The term "node" may refer to a connection point. In some embodiments, a node may be a physical electronic device that is configured to create, receive, or transmit data. In other embodiments, a node may be a software module on a computing device, where the software module is a connection point in a communications network. In some embodiments, the node may be a computing device in a record keeping network. The node may be configured to create a data packet, transmit a data packet, receive a data packet, validate a data packet, access a central record, and/or perform any other suitable function. Different types of nodes may be configured to perform different sets of functions in the recording network. In some embodiments, the node may be associated with and/or controlled by a financial institution (eg, bank), payment processor computer, third party computer, or any other suitable entity.

[0032] "Record" may refer to evidence of one or more interactions. The digital record may be an electronic documentation of the interaction. The entry may contain an entry identifier and entry information. For example, the entry information may contain information describing one or more interactions and/or information associated with the interactions (eg, a digital signature). The record information may comprise a plurality of different data packets, with each data packet having different data describing a different interaction. The entry identifier may be a number, name, or other data value used to identify the entry. The entry identifier may be insignificant in the sense that it may not represent any meaningful information about the entry information in the entry. Examples of records include medical records, education records, transaction records in a transaction ledger, etc. Another example of a record is a block in a blockchain. A single block may be a single entry, and a block chain may be a sequence of entries. The block chain header is an example of a record identifier, and the body of the block chain is an example of record information.

[0033] The term "transaction registry" may refer to a collection of data from previous transactions. A transaction ledger may be a database or other comparable file structure that can be adapted to store data from all previous transactions, including the date and time of the transaction, the amount of the transaction, and identification information for 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 (eg, blockchain) in which the data already stored in the electronic ledger is immutable.

[0034] A "chain of blocks" may be a database that maintains an ever-growing list of records that is protected from falsification and revision. A block chain may contain a number of blocks of interaction records recorded on one or more nodes. Each block in the block chain can also contain a timestamp and a link to the previous block. For example, each block may contain the hash of the previous block or be appended to it. In other words, blockchain interaction records can be stored as a sequence of "blocks" or persistent files that include a record of a number of transactions occurring over a given period of time. Blocks can be attached to the blockchain by the proper node after it completes the block and the validity of the block is confirmed. In embodiments of the present invention, the block chain may be distributed, and a copy of the block chain may be maintained at each node in the block chain network.

[0035] A "key pair" may include a pair of associated encryption keys. For example, a key pair may contain a public (public) key and a corresponding private key. In a key pair, the first key (eg, the public key) may be used to encrypt the message, while the second key (eg, the private key) may be used to decrypt the encrypted message. Additionally, the public key may be configured to verify the digital signature created with the corresponding private key. The public key may be distributed over the network in order to allow verification of messages signed with the corresponding private key. The public and private keys may be in any suitable format, including those based on public key cryptographic algorithm (RSA) or elliptic curve cryptography (ECC). In some embodiments, the key pair may be generated using an asymmetric key pair algorithm. However, the key pair may also be generated using other means, as one skilled in the art will appreciate.

[0036] The term "digital signature" may refer to an electronic signature for a message. A digital signature may be a numerical 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 public key validation algorithm may be used to verify the signature.

[0037] The "work identifier" may provide an identifier for the user. For example, the operational identifier may be a generally unique identifier for an end user who submits new entry information to a node in a record keeping network, or for an end user who receives information about new entry information (eg, value translation) from a node. In some embodiments, the work identifier may also indicate the specific node with which the user is associated. The working identifier can contain alphanumeric characters, special characters, and any other suitable character.

[0038] The "address identifier" may provide an identifier for the participant. For example, an address identifier may represent a host or service provider on a network. In some embodiments, a message may be directed to a specific node by having a node address identifier. The address identifier may contain a string of characters such as letters, numbers, etc. For example, the 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 be used as an identifier of the participant's address.

[0039] A "class identifier" may contain a data value that represents a particular record type. The class identifiers may be used to identify any suitable class of information being recorded. For example, a class identifier can be adapted to identify records related to a medical information type, records related to an educational credential type, records related to a product identifier type, records related to an employee data type, records related to an activity type. (e.g. construction activities, plumbing activities, etc.), records of value transfers of various types (e.g., US dollar payments, British pounds payments, Chinese yuan payments, digital rights data transfers, property document transfers, event tickets, game credit transfers, energy credit transfers, mobile phone minute transfers, etc.) or any other suitable type of record. The classes may be separated in any suitable way. In some embodiments, the class identifier may also indicate that a particular participant is authorized to create and/or receive data packets for a record of that type. The class identifier may contain 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.

[0040] A "server computer" may include a powerful computer or a cluster of computers. For example, a server computer may be a large mainframe computer, a cluster of minicomputers, or a group of servers that function as one unit. In one example, the server computer may be a database server connected to a web server. The server computer may be connected to the database and may contain any hardware, software, other logic, or a combination of the previous to serve requests from one or more client computers.

[0041] In FIG. 1 shows a system 100 containing a number of components. The system 100 includes a recording network that is under the administrative control of the administrative host computer 150 . First node computer 165 , second node computer 145 , third node computer 123 , fourth node computer 124 , fifth node computer 125 , sixth node computer 126 , seventh node computer 127 , eighth node computer 128 , ninth node computer 129 , and any other suitable series of computers nodes participate in the network. The first user's computer 110 , under the control of the first user (not shown), may issue record update instructions via the first node computer 165 , the second user's computer 130 , under the control of the second user (not shown), may issue record update instructions through the second node's computer 145. node, and computers of other users (e.g., third user computer 133 , fourth user computer 134 , fifth user computer 135 , sixth user computer 136 , seventh user computer 137 , eighth user computer 138 , ninth user computer 139 ) may also issue write update instructions. through the computers of their associated nodes. Additionally, the computers of the various nodes may inform the computers of their associated users about updates to the records that have been submitted.

[0042] All of the computers shown in system 100 may be in operative communication with each other via any suitable communication channel or communication network. Suitable communication networks may be any and/or combination of the following: direct interconnection; Internet; local area network (LAN); city computer network (MAN); operational missions and nodes on the Internet (OMNI); secure regular connection; wide area network (WAN); a wireless network (eg, using, but not limited to, protocols such as WAP, I-mode, and/or the like); and/or the like.

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

[0044] System 100 may be adapted to create and maintain records of any suitable types. The administrative host computer 150 may administer the record keeping process by providing a number of services. For example, the administrative host computer 150 may construct new blocks for the block chain, where the new blocks contain updated record information. The administrative node computer 150 can also register nodes and end users, as well as regulate the behavior of participating nodes to maintain records in a secure and reliable manner. The administrative node computer 150 may further check for new data packets and inform participating nodes of new interactions and blocks.

[0045] Additionally, the administrative host computer 150 may facilitate the creation of sequentially ordered records, as defined by one or more smart contracts. For example, the administrative host computer 150 may accept and enforce smart contracts. This may include monitoring when a smart contract policy has been satisfied and, if successful, creating a new entry based on the satisfied policy.

[0046] Since the administrative node computer 150 can build and maintain an ordered set of records, computers of different nodes can supply new information to the administrative node computer 150 for recording. For example, the first node computer 165 and the second node computer 145 may create and supply data packets describing the interactions of the various classes. These data packets may be created and served based on interaction instructions received from the first user's computer 110 and/or the second user's computer 130 , or based on triggering events as defined in the smart contract.

[0047] Additionally, one or more node computers may be configured to generate and/or submit smart contracts. For example, the second node computer 145 may create a smart contract that defines one or more events that may take place in the future, as well as the expected order for the events. Additionally, the smart contract may define one or more records to be created in response to events. The second node computer 145 may transmit the smart contract to the administrative node computer 150 , which may manage and enforce the smart contract. For example, the administrative host computer 150 may instruct the second host computer 145 to create and serve a data packet representing a particular interaction after a particular trigger event has occurred. As a result, the construction of records (for example, interactions) can be carried out in a predetermined order.

[0048] Although in FIG. 1 specifically illustrates nine different node computers, system 100 may include any suitable number of node computers. Additionally, each node computer may communicate with more than just one user computer. For example, the first node computer 165 may communicate with other users' computers in addition to the first user's computer 110 . Additionally, system 100 may include more than one administrative host computer 150 for administering the recording network.

[0049] System 100 may be used to process, approve, and record any suitable type of information. For example, system 100 can be used to record information about new interactions, such as new projects and activities, new value conversions, new patient medical data, new educational advances, and so on.

[0050] An example of an administrative host computer 150 according to some embodiments of the present invention is shown in FIG. 2 . The administrative 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 , a smart contract database 150R , and a machine-readable medium 150E .

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

[0052] The node database 150D may contain information about nodes such as the first node computer 165 , the second node computer 145 , and other node computers shown in FIG. 1 . For example, the node database may contain identifiers associated with the first node computer 165 , such as an address identifier and one or more class identifiers. The node database 150D may also contain information about restrictions, such as cost limits, associated with different nodes.

[0053] The user database 150P may contain information about registered end users such as the first user, the second user, as well as devices associated with the users (e.g., the first user's computer 110 , the second user's computer 130 , and other users' computers shown in FIG . .1 ). It may contain work identifiers, as well as information about which node the user is associated with. For example, the second user's work computer ID may be associated with the second node's computer address ID as well as a specific class ID.

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

[0055] The smart contract database 150R may store one or more smart contracts. For example, smart contract database 150R may store a copy of a smart contract served by a node computer that specifies one or more events and one or more corresponding interactions. The smart contract database 150R may further store information describing the occurrence of a given smart contract, such as which events and/or interactions have already taken place and an indication of the next expected event. Additionally, one or more digital signatures associated with a given smart contract may be stored.

[0056] The computer-readable medium 150E may include a registration module 150F , a validation module 150J , a signature module 150K , a record update module 150L , a calculation module 150M , a smart contract module 150N , and any other suitable software module. Computer readable medium 150E may also include code executable by processor 150A for implementing a method including receiving a smart contract indicating that an ordered set of interactions will take place in response to an ordered set of events; in response to the first event from the ordered set of events, sending instructions to the computer of the second node to generate the first data packet for the first interaction from the ordered set of interactions, and the smart contract indicates that the first interaction will take place in response to the first event; receiving from the computer of the second node the first data packet for the first interaction; generating a first block for the block chain, the first block containing the first data packet for the first interaction; in response to the second event from the ordered set of events, sending to the computer of the second node an instruction to generate a second data packet for the second interaction from the ordered set of interactions, and the smart contract indicates that the second interaction will take place in response to the second event; receiving from the computer of the second node the second data packet for the second interaction; and generating a second block for the block chain, the second block containing the second data packet for the first interaction.

[0057] The registration module 150F may contain code that causes the processor 150A to register the node computers to join the recording network. For example, registration module 150F may contain logic that causes processor 150A to evaluate whether or not a subject can be registered, as well as what level of risk to assign to a new subject. The level of risk may be affected by whether the entity is a well-known and trusted entity, whether it has approved a checking account or other settlement processes, whether it is located in a high-risk country, etc. In addition to assigning a risk level, the administrative node computer 150 may issue activity limits for a host based on a risk profile. Activity limits may include, for example, maximum transaction threshold limits and/or turnover rate limits, such as a limit on the number of payment transactions or total transaction value that can be submitted within a given time period (eg, day, week, or month).

[0058] The registration module 150F may also contain instructions for generating and assigning a unique address identifier for the newly registered node. Additionally, there may be instructions for generating and distributing keys for the newly registered node. For example, the administrative host computer 150 may generate a key pair for the host. The administrative host computer 150 may store the public key and provide the private key to the host computer.

[0059] The registration module 150F may further include instructions for registering end users. For example, the administrative site computer 150 may receive information about a new user (eg, name, address, account number, telephone number, business entity corporate profile, etc.) from the site, store the user information, and then assign a unique work ID to the user. In some embodiments, the implementation of the working identifier may contain a subset of characters that indicate the associated node or node address identifier.

[0060] The validation module 150J may comprise code that causes the processor 150A to validate the new data packet so that the data packet can be entered into the records. For example, validation module 150J may include logic that causes processor 150A to verify that a data packet contains an address identifier and a class identifier that are both valid and associated with the same host computer, and verify that the limits associated with the filed class identifier, have not been exceeded and are not currently exceeded by the new data packet.

[0061] Validation module 150J may further comprise 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) are registered on the network and have been validated. The administrative node computer 150 may also evaluate the risk of a transaction, for example, by estimating the transaction turnover rate of one or more involved parties, or by determining whether the originating node has any warnings issued.

[0062] Validation module 150J may further comprise code that directs processor 150A to validate one or more digital signatures. For example, validation module 150J may include logic that causes processor 150A to use the host computer's public key to authenticate the digital signature associated with that host computer.

[0063] Signing module 150K may contain code that directs processor 150A to generate digital signatures. For example, signing module 150K may contain logic that causes processor 150A to generate a digital signature for a data packet and/or smart contract using the administrative node's private key. The digital signature of the administrative host computer may serve to indicate the authenticity of the data packet and may provide assurance that the translation is valid and valid.

[0064] The record update module 150L may contain code that causes the processor 150A to maintain and update the record set. For example, record update module 150L may include logic that causes processor 150A to record information about a new interaction (eg, as specified in a new data packet). In some embodiments, the record update module 150L may contain instructions for including a new data packet in the next block of the block chain.

[0065] The record update module 150L may further include instructions for informing parties associated with the interactions described in the data packet if a new data packet is created. For example, if a new payment transaction is validated and signed, the administrative node computer 150 may send information about the new payment transaction to the receiving node (eg, second node computer 145 ) and/or user computers.

[0066] In some embodiments, the participating node computers may not maintain a separate set of records and may instead refer to the centrally maintained records of the administrative node computer 150 . For example, each of the first node computer 165 and the second node computer 145 may be a light node. In such a case, the administration site computer 150 may provide these sites with real-time access to central records, or the administration site computer 150 may provide regular updates to the records (e.g., updates may be sent every 10 seconds, 1 minute, 5 minutes, etc.) . As a result, other nodes may be aware of new interactions immediately or shortly after the interactions are recorded.

[0067] In some embodiments, the participating node computers may not see all of the entry information, and they may instead have a filtered or resolved view of the entries. For example, the first node computer 165 , the second node computer 145 , the first user computer 110 , and/or the second user computer 130 can only view records of interactions with which they are associated (e.g., transactions in which they are involved), in the case of accessing records on the computer 150 of the administrative node. For example, the second node computer 145 can view all of the block headers, but can only view the main parts of the blocks and interaction records with which it is associated.

[0068] In some embodiments, there may be multiple administration node computers 150 , each receiving and processing different data packets with information about different interactions, and then updating their own records. These different administrative host computers can communicate with each other to share new entries and to confirm that their entries include the same interactions.

[0069] Calculation module 150M may include code that causes processor 150A to calculate the provisioned value between counts. For example, settlement module 150M may include logic that causes processor 150A to deduct the first node's central bank checking account for the amount specified in the interaction record and credit the second node's checking account with the same amount (or the same amount minus the accrued fees) .

[0070] In some embodiments, the settlement may occur in multiple steps (eg, as a result of translating a value using multiple atomic transactions). For example, the first settlement may include debiting the settlement account of the first node of the first amount and accruing the settlement account of the administrative node of the same first amount. Then the second settlement may involve debiting the (same or different) settlement account of the administrative node of the second amount, and then accruing the same second amount to the settlement account of the second node. As a result, the value is transferred from the first node to the second node through the administrative node.

[0071] The smart contract module 150N may contain code that causes processor 150A to accept, validate, store, and/or execute a smart contract. In some embodiments, a smart contract can either be added to a blockchain record or stored in a smart contract database. The smart contract module 150N may contain logic that causes the processor 150A to obtain a digital signature for each responsible party specified by the smart contract (eg, each party providing a payment) and verify each digital signature using the corresponding public keys. In some embodiments, the administrative node computer 150 may reserve funds in checking accounts (eg, a node checking account at a central bank) based on smart contract payments. Additionally, smart contract module 150N may include logic that causes processor 150A to send messages to each party associated with the smart contract when the smart contract is executed.

[0072] The smart contract module 150N may further comprise code that causes processor 150A to determine whether an event specified in the smart contract has occurred. This may include receiving a message notifying that an event has occurred (eg, from the actor that caused the event) and verifying the attached digital signature. Additionally, the smart contract module 150N may contain logic that causes the processor 150A to initiate a response based on an event according to the smart contract. This may include sending an instruction to the host computer to generate a data packet to update the records database.

[0073] Returning again to FIG. 1 , the second node computer 145 may, as mentioned above, participate in the recording network by creating and submitting new data packets with new interaction data in order to update the recordings by one or more users. Additionally, the second node computer 145 can create and submit a smart contract to the write network so that other nodes can trust that future data packets will be created.

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

[0075] The identifier database 145C may store information about the identifiers of the second node's computer, such as an address identifier and one or more class identifiers. The ID database 145C may also contain information about one or more users, such as work IDs, an associated class type, and/or a user account.

[0076] Key database 145E may store encryption keys. For example, the key database 145E may contain a private key associated with the second node computer 145 as well as a public key associated with the administrative node computer 150 . In some embodiments, key database 145E may take the form of a hardware security module (HSM).

[0077] The computer-readable medium 145F may include a registration module 145G , a user registration module 145K , a data packet module 145L , a node search module 145M, a value analysis module 145N , a signature module 145P , a record submission module 145Q , a smart contract module 145R , a confirmation module 145T reality and any other suitable software module. Computer readable medium 145F may also include code executable by processor 145A for implementing a method including: generating a smart contract indicating that an ordered set of interactions will take place in response to an ordered set of events; in response to a first event from the ordered set of events, generating a first data packet for the first interaction from the ordered set of interactions, wherein the smart contract indicates that the first interaction will take place in response to the first event; transmitting the first data packet to the administrative node computer, the administrative node computer generating a first block for the block chain, the first block containing the first data packet; in response to a second event from the ordered set of events, generating a second data packet for a second interaction from the ordered set of interactions, wherein the smart contract indicates that the second interaction will take place in response to the second event; and transmitting the second data packet to the administrative host computer, the administrative host computer creating a second block for the block chain, the second block containing the second data packet.

[0078] The registration module 145G may contain code that causes the processor 145A to register with the administrative node computer 150 to participate in the recording network. For example, registration module 145G may include logic that causes processor 145A to send a registration request message containing information about the second node such as address, bank ID, checking account, and/or any other pertinent information. The registration module 145G also contains instructions for receiving and storing the address identifier, the public key of the administrative node, the private key of the second node, one or more class identifiers, and any other suitable registration information from the computer 150 of the administrative node.

[0079] User registration module 145K may contain code that directs processor 145A to facilitate end user registration. For example, user registration module 145K may include logic that causes processor 145A to provide user information (e.g., name, address of residence and/or business, date of birth, telephone number, account number, account username, account password, address e-mail, government-issued identification number such as driver's license number, passport number or social security number, etc.) to the administrative node computer 150 . The second node computer 145 may also receive and store the work ID for the second user computer 130 from the administrative node computer 150 and provide the work ID to the second user computer 130 .

[0080] Data packet module 145L may contain code that causes processor 145A to generate a new data packet. For example, data packet module 145L may include logic that causes processor 145A to receive an instruction from second user computer 130 and/or administrative host computer 150 and create a data packet for interaction based on the instruction. The data packet may contain any relevant information for entering a new registry entry. In the example of payment transactions, the data packet may contain information about the sending account, the receiving account, the class type of the currency being sent, the class type of the currency being received, the currency exchange rate, and/or any other suitable information.

[0081] Node lookup module 145M may contain code that causes processor 145A to identify a node based on a user. For example, node lookup module 145M may include logic that causes processor 145A to identify third node computer 123 based on third user computer 133 specified as the recipient of the transaction. For example, the third node's address identifier may be identified based on a subset of characters included in the third user's operational identifier, or the address identifier may be associated with the third user's operational identifier in a database (eg, a database available on the administrative host computer 150 ). The node lookup module 145M may also contain instructions for adding the identified address identifier to the new data packet.

[0082] Value analysis module 145N may include code that directs processor 145A to determine a value for interaction. For example, value analysis module 145N may include logic that causes processor 145A to determine a first amount in a first currency to be charged to a second user in order to deliver a second amount in a second currency to a third user. This determination may include searching for the current foreign exchange rate and calculating transfer fees (eg, both of which may be provided by the administrative node computer 150 ). The amount deducted in the first currency, information about the amount accrued in the second currency, the exchange rate and/or the fees charged may be included in the new data package.

[0083] Signing module 145P may contain code that instructs processor 145A to create a digital signature. For example, signing module 145P may include logic that directs processor 145A to apply a private key and mathematical algorithm to a data packet, such that a digital signature is generated for the data packet. The digital signature of the second node computer can serve as proof that the second node computer 145 actually created and submitted the data packet.

[0084] The write submission module 145Q may contain code that causes the processor 145A to submit a new data packet with new interactions to be written. For example, entry feeder 145Q may include logic that causes processor 145A to send a new data packet, an associated digital signature, and/or any other pertinent information to administrative host computer 150 .

[0085] The smart contract module 145R may contain code that directs the processor 145A to generate a smart contract. A smart contract may contain information about an ordered sequence of events and an ordered sequence of responses (eg, interactions). The smart contract module 145R may also contain logic that causes the processor 145A to communicate with other parties (e.g., the first node computer 165 ) associated with the smart contract to reach a consensus on the details of the smart contract, to digitally sign the smart contract, and to communicate the smart contract. contract to the central administrator. In some embodiments, smart contract module 145R may contain code that directs processor 145A to perform tasks associated with the new smart contract, such as reserving funds in an account based on payments defined in the smart contract.

[0086] In addition to creating and sending data packets (eg, to send a payment to a third node computer), the second node computer 145 may also be configured to authenticate data packets submitted by other nodes. For example, the first node computer 165 may submit a data packet to the administrative node computer 150 (eg, to send a payment to the second node computer), and the second node computer 145 may verify that the data packet is genuine.

[0087] For example, the computer-readable medium may include a validation module 145T , which may contain code that causes processor 145A to validate a new data packet. The second node computer 145 can validate that the new data packet is genuine in one or more ways. For example, the second node computer 145 can verify that both the sending node computer digital signature and the administrative node computer signature for the data packet are authentic (eg, using their respective public keys). In some embodiments, the second node computer 145 may authenticate the interaction and/or data packet by accessing a central record (eg, block chain records) and confirming that the interaction and/or data packet was added to the records. The second node computer 145 may also inform the second user computer 130 of new interaction data in the data packet.

[0088] In some embodiments, the second node computer 145 may provide additional services to the user in addition to communicating with the recording network. For example, second node computer 145 may be a computer associated with a financial institution, hospital, law enforcement agency, educational institution, mobile phone service provider, or any other suitable service provider. Accordingly, in some embodiments, the second node computer 145 may support an account on the part of the user. An account may store identification information, medical records, educational records, financial information, or any other pertinent details depending on the type of service provider.

[0089] In embodiments where the second node computer 145 is associated with a financial institution, the second node computer 145 may store a value from the user's side. The second node computer 145 may also be configured to provide a value (eg, provide a payment) and/or receive a value (eg, receive a payment) from the user. An example of a financial institution is an issuer, which can generally refer to a business entity (eg a bank) that opens and maintains an account (eg a bank account) for a user. Another example of a financial institution is an acquirer, which can typically be a business entity (eg, a commercial bank) that has a business relationship with a particular resource provider or other entity. Some entities may act as both an issuer and an acquirer. Some embodiments may cover such single issuer-acquirer entities.

[0090] In some embodiments, when the first node computer 165 (or another node) sends a payment data packet to the second node computer 145 , the second node computer 145 may have a high level of confidence that the secured value will be delivered. For example, the computer 145 of the second node can be sure of the value due to two valid digital signatures due to the interaction data being included in the block chain record, due to the fact that the data packet includes several associated identifiers (for example, a class identifier and/or an identifier address), or as a result of any other suitable evidence. As a result, the second node computer 145 can make the value indicated in the received data packet immediately available for use (eg, available for withdrawal) in the account of the second user, even if the value has not yet been calculated and received. Additionally, the second node may have a high level of trust in the administrative node, since the administrative node may be a large, trusted central entity.

[0091] In some embodiments, the second node computer 145 may characterize a plurality of connected computers. For example, the functionality described above for network participation and the functionality associated with banking services may be shared among multiple shared computers.

[0092] Returning again to FIG. 1 , computers of other nodes (e.g., first node computer 165 , third node computer 123 , fourth node computer 124 , fifth node computer 125 , sixth node computer 126 , seventh node computer 127 , eighth node computer 128 , ninth node computer 129 ) may, as mentioned above, participate in the recording network. For example, each node's computer may be registered with the recording network, each node's computer may be associated with a unique address identifier, and each node's computer may be associated with a different private key. Likewise, each user (for each user's computer) can be registered and associated with a unique work ID.

[0093] In some embodiments, the implementation of one or more computers of other nodes may have some or all of the functionality described above in relation to the computer 145 of the second node. For example, one or more node computers may be adapted to receive information about a new interaction (eg, via a data packet) from an associated user computer. Additionally, one or more node computers may submit data packets with new interaction data to the recording network from the associated user computer. Additionally, each node's computer can digitally sign messages using a private key.

[0094] Like the computer 145 of the second node, each of the computers of the other nodes may be associated with a different bank or other suitable service provider. As a result, the computer of each node can host the user's account and can store and receive the value from the user's side and send the value from the user's side.

[0095] The user may be an individual, an enterprise, an organization record update administrator, or any other suitable type of user. For example, the first user may be an individual and the second user may be a resource provider (eg, merchant) who is involved in transactions and may sell goods or services or provide access to goods or services. Additionally, all of the third to ninth users may be different service providers that facilitate aspects of international shipping, such as a freight service, a customs authority, an insurance contract developer, a port service, a storage service, or any other suitable entity. Such users can perform tasks that appear in the dispatch of goods.

[0096] An example smart contract 400 is shown in FIG. 4 . As shown, the smart contract 400 may contain a smart contract identifier 401 such as an alphanumeric code or the like. The smart contract 400 may contain information about a sequence of predefined trigger events 403 and a sequence of predefined responses 404 . In some embodiments, each response may be paired with a specific trigger event such that the response occurs after that trigger event. Additionally, smart contract 400 can set order 402 for trigger events 403 and responses 404 . If a certain trigger event occurs out of order, the corresponding response may not take place and/or any other responses may be cancelled.

[0097] Embodiments of the present invention allow the application of smart contracts with ordered events to any suitable process and/or record keeping scenario. In this example, launch events 403 comprise a sequence of activities, each of which is performed by a different actor (eg, a different user or user's computer). Also in this example, the 404 responses provide for the generation of a sequence of data packets. The data packet may contain information to be entered into an entry (eg, a block chain entry).

[0098] As described in more detail below, the triggering event may include receiving a notification that an activity has been performed. For example, a predefined actor may send a notification message that an activity has been committed, and the notification message may be considered valid (and thus trigger a response) if it is accompanied by a digital signature associated with the actor (e.g., the actor's computer). ).

[0099] As mentioned above, in some embodiments, the recording system may use a blockchain. Each block in the block chain may contain information about one or more interactions (eg, from one or more data packets). A ledger in the form of a block chain cannot be changed imperceptibly. This ensures that no tampering with transaction-related information, such as an attempt to overwrite the value of a transaction to the wrong entity, goes unnoticed. Together, the block header and the body of the block, which contains transaction information (eg, and any other pertinent information), may form a block.

[0100] Embodiments of the present invention improve the process of creating and organizing a blockchain by introducing an ordered smart contract. A smart contract can effectively act as a gatekeeper for new elements of the block chain, ensuring that inappropriate entries (e.g. out of order) are not introduced into the block chain. This preventive measure is useful because once data is entered into the blockchain, it usually cannot be deleted.

[0101] A method 500 according to embodiments of the present invention may be described with reference to FIG. 5A–5G . References are also made to some of the elements shown in other figures. The steps shown in method 500 may be performed sequentially or in any suitable order in embodiments of the present invention. In some embodiments, one or more steps may be optional.

[0102] Any suitable form of communication may be used in the various messages described below. In some embodiments, the request or response may be in an electronic message format such as an email message, a short message service (SMS) message, a multimedia messaging service (MMS) message, a Hypertext Transfer Protocol (HTTP) request message, a transmission control protocol packet ( TCP), submission from a web form. The request or response may be directed to any suitable location, such as an email address, telephone number, Internet Protocol (IP) address, or Uniform Resource Locator (URL). In some embodiments, the request or response may contain a combination of different message types, such as both email messages and short message services.

[0103] The first user (eg, the customer) and the second user (eg, the supplier) may agree to the interaction. The interaction may include the first user providing a payment (eg, $1,500,000) to a second user in exchange for goods. The first user and the second user may be located in different locations (eg, different countries), and thus the second user may arrange for the goods to be delivered to the first user.

[0104] A number of service providers may be involved in the delivery of goods, such as an in-country delivery service, an international departure service, an out-of-country delivery service, an insurance contract preparation service, in-country and out-of-country customs inspection services, etc. Each of these service providers may perform their services in exchange for payment from the second user, and thus a number of additional interactions (for example, between the second user and each service provider) may be necessary to complete the initial interaction between the second user and the first user. .

[0105] In some embodiments, the implementation of the second user (for example, through the computer 130 of the second user) can determine exactly which service providers will be used to deliver goods, as well as the order in which they will perform their services. The second user may also reach an agreement with each service provider regarding the amount of payments and types of currency that will be provided in exchange for their services (for example, ¥35000 for the first service provider, ¥12000 for the second service provider, ¥57000 for the second service provider, $3400 for a fourth provider, $6,850 for a fifth provider, and so on).

[0106] The second user may then (eg, via the second user's computer 130 ) provide some or all of the payment and send information to the second node computer 145 so that the second node computer 145 can schedule the second user's payment processes. This may include providing second node computer 145 with operational identifiers for each user (eg, the first user and each service provider).

[0107] Second node computer 145 may then determine the node computer (eg, node computer address ID) associated with each work ID. For example, the first node computer 165 may be associated with the work ID of a first user, the third node computer 123 may be associated with the work ID of one service provider, the fourth node computer 124 may be associated with the work ID of yet another service provider, and so on. In embodiments, the second node computer 145 may communicate with the administrative node computer 150 to learn which nodes are associated with each work ID. In some embodiments, the second node computer 145 may use a locally stored lookup table to identify the node associated with each work ID. In other embodiments, the second node computer 145 may parse each operational identifier to determine the computer address identifier of each node.

[0108] Having received information about each transaction (for example, each payment provider, each payee, each payment amount), each sending service to be performed in exchange for each payment, and the computers of the nodes with which to communicate, the computer 145 the second node can proceed to approve the smart contract that governs the whole process.

[0109] In step S101 , the computer 145 of the second node may generate a smart contract. A smart contract may define an ordered set of events (eg, departure-related services) that are expected to take place. The smart contract may also contain information specifying an ordered set of interactions to take place in response to an ordered set of events. In this case, each interaction could be a payment transaction between the sending account and the receiving account. Each different transaction may indicate a different receiving account. A smart contract can specify that each interaction should only run if its corresponding event occurs in the correct order.

[0110] While a smart contract may be identified based on an ordered sequence of events and/or an ordered sequence of interactions, in some embodiments, the second node computer 145 may assign a smart contract identifier (e.g., an alphanumeric value) to the smart contract. In other embodiments, the administrative host computer 150 may assign a smart contract identifier to the smart contract at a later point in time.

[0111] Additionally, the computer 145 of the second node can make a reservation in relation to the account of the second user. For example, the total amount that the second user must pay may be calculated. This can be done by summing the amounts of all payments, where the second user is the payment provider. The second node computer 145 can check that the second user has enough funds available to make all of these payments and can further reserve the funds needed for each payment so that the funds are available when payments are made.

[0112] In step S102 , the computer 145 of the second node may generate a digital signature for the smart contract. The digital signature can be created using the private key associated with the computer 145 of the second node. In some embodiments, the digital signature may serve as an indication that the second node computer 145 approves the smart contract and/or that the second node computer 145 has reserved the funds required for each payment that the second user provides.

[0113] In step S103 , the second node computer 145 may transmit the smart contract and/or digital signature to the administrative node computer 150 . As a result, the administrative host computer 150 may receive a smart contract that indicates that an ordered set of interactions will take place in response to an ordered set of events.

[0114] In step S104 , the administrative node computer 150 may send a copy of the smart contract to the first node computer 165 to obtain approval of the smart contract from the first node computer. For example, the administrative host computer 150 may parse the smart contract to determine that entities are listed as responsible for sending one or more payments. The administrative host computer 150 may then require confirmation from each sender of the payment. In this case, the senders of payments include the computer 145 of the second node (on the side of the second user) and the computer 165 of the first node (on the side of the first user). Because the second node computer 145 may have already provided the digital signature, the administrative node computer 150 may only require an additional digital signature from the first node computer 165 .

[0115] Additionally, the administrative node computer 150 can verify the digital signature of the second node computer, for example, using the public key associated with the second node computer 145 . Additionally, the administrative node computer 150 may digitally store the smart contract and/or the digital signature of the first node computer (eg, in a smart contract database).

[0116] In step S105 , the first node computer 165 may determine whether to agree to the smart contract. For example, the first node computer 165 may inform the first user (eg, via the first user's computer 110 ) of charges to be charged to the first user's account, details of the shipment (eg, items to be provided and delivery timeline), and any other relevant details specified by the smart contract.

[0117] If the first user approves the details of the smart contract, the first node computer 165 may generate a digital signature for the smart contract, for example, using the private key associated with the first node computer 165 . Additionally, the first node computer 165 may reserve in the first user's account the payment amount for the second user for goods (and any other payment amounts for which the first user is responsible).

[0118] The first node computer 165 may then transmit the digital signature to the administrative node computer 150 along with a message indicating that the first node computer 165 approves the smart contract.

[0119] The computer 150 of the administrative node can verify the digital signature of the computer of the first node, for example, using the public key associated with the computer 165 of the first node. Additionally, the administration site computer 150 may digitally store the digital signature of the first site computer (eg, along with the smart contract and the digital signature of the second site computer). Having received approval from both senders of payments indicated by the smart contract and/or having confirmed that the payment amounts are available and reserved, the administrative node computer 150 may consider the smart contract as validated and in effect.

[0120] In step S106 , the administrative node computer 150 may send notifications to each node computer about the newly created smart contract. For example, the administrative host computer 150 may send a message to the third host computer 123 informing the third host computer 123 that a payment (for a specific amount) will be provided by the second user to the third user if the third user performs a specific task. The third user may be a delivery service within the country, and the task may be to pick up goods from the second user's warehouse and deliver the goods to the port of origin. The computer 123 of the third node may, in turn, provide this information to the computer 133 of the third user. Similar messages can be sent to each other host's computer and the user's computer. As a result, each user can be informed of the corresponding task related to the shipment and can be sure that he will receive payment if he completes his task.

[0121] In some embodiments, each of the host computer and the user computer are only informed about the interactions and/or events with which they are associated. For example, the third user's computer 133 may not receive any information about payments accepted by the fourth user's computer 134 or sending tasks performed by it. Additionally, in some embodiments, the node computers may be configured to communicate with the administrative node computer 150 to view (its portion of) smart contracts that are in execution.

[0122] In step S107 , the second user (eg, via the second user's computer 130 ) may initiate the process in response to the smart contract approval. For example, a second user may package goods and provide goods to a third user (eg, a delivery service within a country). This may initiate the delivery process and bring an ordered sequence of events to execution.

[0123] In step S108 , the third user may cause the first event to occur. For example, a third user may perform a first action or task, such as transporting goods from a second user's warehouse to a port of departure.

[0124] After the first event occurs, the third user may (eg, via the third user's computer 133 ) report that the task has been completed. The computer 133 of the third user may send a message about the event to the computer 123 of the third node.

[0125] In step S109 , the third node computer 123 may generate an event notification message indicating that a first event has occurred (eg, task completed). The message may contain information describing the event and when it occurred, as well as any suitable evidence that the event occurred (eg, receipt, photograph, etc.). The message may additionally contain a smart contract identifier.

[0126] In some embodiments, the implementation of the message may also contain information about the first interaction that should take place in response to the first event, as specified by the smart contract. Thus, the event notification may also or instead serve as a payment request message by providing information about the payment amount, payment provider (eg, second user), and payee (eg, third user).

[0127] Additionally, the computer 123 of the third node can generate a digital signature for the event notification message, for example, using the private key associated with the computer 123 of the third node. Additionally, the third node computer 123 may send an event notification message and/or a digital signature to the administrative node computer 150 .

[0128] In some embodiments, in order to ensure that an event occur message (and an event notification message) is sent only if the first event has occurred, the event occur message may be sent in response to a specific signal. launch. For example, an event trigger message may be sent if a third user (eg, attendant or delivery truck) arrives at the delivery location (eg, port of origin). The third user's location may be tracked and determined via a mobile device, vehicle, or other device equipped with location tracking technology (eg, GPS). The mobile device of the third user may be in communication with the third user computer 133 , the third node computer 123 , and/or the administrative node computer 150 in order to transmit current location data. As a result, information about the occurrence of an event cannot be transmitted until the third user arrives at the delivery location.

[0129] In additional embodiments, instead of the third user computer 133 and the third node computer 123 , the fourth user computer 134 and/or the fourth node computer 124 may report that the first event has occurred. Thus, an event is only reported as completed if the fourth user can verify that the third user completed their task (eg, the third user provided goods to the fourth user).

[0130] The administrative node computer 150 may receive the event notification message and then may identify the smart contract (eg, from among other smart contracts stored in the smart contract database) associated with the message. For example, a stored smart contract may be identified based on a smart contract identifier included in the notification message, or based on an event and/or interaction described in the notification message.

[0131] In step S110 , the administrative node computer 150 checks the event notification message based on the smart contract. For example, the administrative host computer 150 may check that the event reported in the event notification message corresponds to the next expected event according to the smart contract. In the case of a first event, the administrative host computer 150 may check that the reported event should occur first (eg, before all other events) within an ordered set of smart contract events.

[0132] The administrative host computer 150 can also verify that the third host computer 123 is reporting the occurrence of an event by verifying the digital signature of the third host computer (eg, using a public key associated with the third host computer).

[0133] In some embodiments, the administrative node computer 150 may not consider the event notification sent by the third node computer 123 as valid until the fourth user computer 134 and/or the fourth node computer 124 confirm that they have accepted the goods from a third user, and/or will not confirm that the event has been committed.

[0134] After the administrative host computer 150 determines that the first event has occurred, the administrative host computer 150 may mark the first event as having occurred. For example, a notification message or other indication of completion may be stored in the smart contract database along with the smart contract.

[0135] Additionally, the administrative node computer 150 may determine the first interaction to take place in response to the first event occurring. This may include parsing the smart contract to identify the interaction associated with the event and/or parsing the notification message to identify the interaction that is requested. In this example, the interaction is a second user making a payment to a third user. The administrative node computer 150 can thereby identify the user and node computer (eg, second node computer 145 ) responsible for sending the interaction payment.

[0136] In step S111 , the administrative node computer 150 may generate and transmit a message with an instruction to write to the second node computer 145 . In this case, the write instruction may be an instruction to create a data packet representing the first interaction (eg, a payment from the second node to the third node), so that the data packet can be written to the transaction ledger. In some embodiments, the administrative host computer 150 may also or instead inform the second host computer 145 that the first event has occurred, and the second host computer 145 may determine which payment to make based on the smart contract.

[0137] In step S112 , the computer 145 of the second node generates a data packet representing the first interaction from the ordered set of interactions. The data packet may be formatted such that it may be included in a transaction ledger, which may be a record of a block chain. In this case, the data packet may contain any suitable information representing the details of the payment transaction, such as the agreed transaction amount, currency type, information identifying the sending account (for example, the account of the second user), information identifying the receiving account (for example, the account of the third user ), the working computer ID of the second user, the working computer ID of the third user, the address ID and/or class ID of the second node computer, the address ID and/or class ID of the third node computer, and/or any other pertinent information.

[0138] In some embodiments, the data packet may also contain a smart contract identifier, such that the data packet may later be identified (eg, within a block chain record) using the smart contract identifier.

[0139] Additionally, the second node computer 145 may generate a first digital signature for the data packet. For example, second node computer 145 may generate a one-way hash using some or all of the information in the data packet, and then encrypt the hash using the private key. A hash value and/or a digital signature may be attached to the data packet, thereby making the data packet visible when the data is corrupted.

[0140] In step S113 , the second node computer 145 transmits the data packet for the first interaction and the first digital signature to the administrative node computer 150 for validation and entry into the block chain record.

[0141] In step S114 , the administrative node computer 150 may verify the digital signature and/or hash value of the second node computer. For example, the administrative host computer 150 may perform a checksum verification procedure for 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 administrative site computer 150 can verify the digital signature using the public key of the second site computer. The administrative host computer 150 may reject the data packet if the hash or digital signature cannot be verified.

[0142] The administrative host computer 150 may also check that both of the class ID and the address ID of the second host computer are valid, are associated with the second host computer 145 , and are used appropriately. If these and any other suitable verification steps are successfully completed, the administrative host computer 150 may consider the data packet to be valid, and the administrative host computer 150 may generate a second digital signature for the data packet (e.g., using the private key associated with the administrative host computer 150 ) .

[0143] In step S115 , the administrative node computer 150 may add information about the first interaction (and/or the entire data packet) to the entry. For example, the administrative host computer 150 may create a new block for the block chain, the block containing the data packet for the first interaction and digital signatures. A block may also contain other unrelated data packets that were received in a similar time period (eg, a block may contain all data packets received over a 10-minute period).

[0144] In step S116 , the administrative node computer 150 may send a copy of the data packet to the third node computer 123 (eg, to inform the third node computer 123 of the transaction). The administrative node computer 150 may also make the block chain entry available to the third node computer 123 .

[0145] In step S117 , the third node computer 123 may authenticate the data packet. For example, the third node computer 123 may confirm that the data packet has been entered into the block chain record (eg, by accessing the block chain record on the administrative node computer 150 ). The third node computer 123 may also verify that the data packet contains two digital signatures, one from the second node computer 145 and one from the administrative node computer 150 . The third node computer 123 may also verify digital signatures (eg, using the appropriate public keys). All of these checks in combination can create a high level of confidence in the authenticity of the data packet, as well as a high level of confidence that the provided interaction will take place.

[0146] Additionally, the third node computer 123 may update its local records based on the data packet. For example, the third node computer 123 may credit the secured transaction value (eg, as specified in the data packet) to the third user's bank account.

[0147] The process of committing an event and executing an interaction (eg, payment) in response to the event, as described above in steps S108-S117 , can be repeated in a similar manner for other events and interactions in steps S118-S127 . For example, when the third user performed the first event (at S108 ), the third user could provide the product packaging to the fourth user. The fourth user may be identified in the smart contract as a service provider that will trigger a second event involving goods, and the smart contract may also identify the second event as a trigger for the second interaction.

[0148] For example, in step S118 , which may be similar to step S108 , the fourth user may cause the second event to occur. For example, a fourth user may be a customs officer within a country, and a fourth user may perform a task related to inspecting goods and clearing goods for export. The fourth user may (eg, via the fourth user's computer 134 ) also report that the task has been completed to the fourth node's computer 124 . In some situations, the second event may occur hours or days after the first event.

[0149] In step S119 , which may be similar to step S109 , the fourth node computer 124 may generate an event notification message indicating that a second event has occurred (e.g., the second task has been completed) and also generate a digital signature for the message (e.g., , using the private key associated with the fourth node computer 124 ). The fourth node computer 124 may send an event notification message and/or a digital signature to the administrative node computer 150 .

[0150] In step S120 , which may be similar to step S110 , the administrative node computer 150 checks the event notification message based on the smart contract. For example, the administrative host computer 150 may check that the event reported in the event notification message is the next expected event according to the smart contract. In the case of a second event, the administrative host computer 150 may check that the reported event should occur second (eg, after the first event and before all other events) within the smart contract's ordered set of events. This may include checking that previous events (in this case only the first event) have been marked as committed.

[0151] The administrative host computer 150 may also verify the digital signature of the fourth node computer (eg, using the public key associated with the fourth node computer), and the administrative host computer 150 may flag the second event as having occurred.

[0152] Additionally, the administrative host computer 150 may determine a second interaction to take place in response to the occurrence of the second event. In this example, the interaction is the second user making a payment to the fourth user.

[0153] In step S121 , which may be similar to step S111 , the administrative node computer 150 may generate and transmit a message with instructions for writing to the second node computer 145 . In this case, the write instruction may be an instruction to create a data packet representing the second interaction (eg, a payment from the second node to the fourth node), so that the data packet can be written to the transaction ledger.

[0154] In step S122 , which may be similar to step S112 , the second node computer 145 generates a second data packet representing the second interaction from the ordered set of interactions. In this case, the second data packet may contain any suitable information representing the details of the payment transaction, such as the agreed transaction amount, currency type, information identifying the sending account (for example, the account of the second user), information identifying the receiving account (for example, the account of the fourth user), the working computer ID of the second user, the working computer ID of the fourth user, the address ID and/or class ID of the computer of the second node, the address ID and/or class ID of the computer of the fourth node, and/or any other pertinent information. Additionally, the computer 145 of the second node can generate a digital signature for the second data packet.

[0155] In step S123 , which may be similar to step S113 , the second node computer 145 transmits the second data packet for the second interaction and the accompanying digital signature to the administrative node computer 150 to validate and enter the block chain record.

[0156] In step S124 , which may be similar to step S114 , the administrative node computer 150 may verify the digital signature and/or hash value of the second node computer. If this and any other suitable verification steps are successfully performed, the administrative host computer 150 may generate a second digital signature for the second data packet.

[0157] In step S125 , which may be similar to step S115 , the administrative node computer 150 may add information about the second interaction (and/or the entire data packet) to the entry. For example, the administrative host computer 150 may create a new block for the block chain, the block containing the second data packet for the second interaction and the associated digital signatures. The block may also contain other unrelated data packets (eg, for other unrelated sending processes) that were received in a similar time period (eg, the block may contain all data packets received over a 10-minute period). Additional blocks may have been created during the time between steps S115 and S125 . As a result, the block chain may contain a plurality of intermediary blocks between the block created in step S115 and the block created in step S125 .

[0158] In step S126 , which may be similar to step S116 , the administrative node computer 150 may transmit a copy of the data packet to the fourth node computer 124 .

[0159] In step S127 , which may be similar to step S117 , the fourth node computer 124 may authenticate the data packet. Additionally, the fourth node computer 124 may update its local records based on the data packet. For example, the fourth node computer 124 may credit the secured transaction value (eg, as indicated in the second data packet) to the fourth user's bank account.

[0160] Thus, two separate events and two separate corresponding interactions can take place, as predetermined in the smart contract. This event-interaction process (as described for the first event and the first interaction in steps S108-S117 and again described for the second event and the second interaction in steps S118-S127 ) may be repeated for each event-interaction pair set in smart contract.

[0161] For example, the dispatch process may involve additional transportation segments, additional customs clearances, insurance policy creation steps, etc., and each of these additional tasks may be performed by an additional service provider. In FIG. 1 shows seven such service providers (represented by computers 133 to 139 users from third to ninth), but any suitable number of service providers and corresponding smart contract elements can be represented. Thus, there may be one, three, five, or more iterations of the event and interaction process (eg, as described above for steps S108-S117 ) for additional service providers.

[0162] The last dispatch event may be the delivery of goods to the first user (eg, to the warehouse of the first user). This may trigger the last payment provided by the second user that can be sent to the final delivery service. Additionally, the computer 145 of the second node may determine that the goods have been successfully delivered (or be notified about it). As a result, the second user could efficiently complete the original task of sending the package of goods to the first user. Thus, in addition to the last delivery triggering the last payment provided by the second user, it may also trigger the final payment that the first user (eg, the buyer of the goods) sends to the second user (eg, the person making the delivery of the goods).

[0163] In step S128 , which may be similar to step S109 , the second node computer 145 may generate an event notification message indicating that a final event has occurred (e.g., the sending process has been completed) and also generate a digital signature for the message. The second node computer 145 may send an event notification message and/or a digital signature to the administrative node computer 150 .

[0164] In step S129 , which may be similar to step S110 , the administrative node computer 150 checks the event notification message based on the smart contract. For example, the administrative host computer 150 may check that the event reported in the event notification message is the next expected event according to the smart contract. In the event of a final event, the administrative host computer 150 may check that all events have been committed and that the smart contract indicates that additional interaction should take place when all events have been confirmed as having occurred (e.g., in addition to the interaction that could already in place for the last service provider).

[0165] Additionally, the administrative node computer 150 may determine the final (eg, third or later) interaction to take place in response to the occurrence of the final (eg, third or later) event. In this case, the interaction is the first user making a payment to the second user.

[0166] In step S130 , which may be similar to step S111 , the administrative node computer 150 may generate and transmit a message with instructions regarding writing to the second node computer 145 . In this example, the write instruction may be an instruction to create a data packet representing the final interaction (eg, a payment from the first node to the second node) so that the data packet can be written to the transaction ledger.

[0167] In step S131 , which may be similar to step S112 , the first node computer 165 generates a final (eg, third or later) data packet representing the third interaction from the ordered set of interactions. In this case, the third data packet may contain any suitable information representing the details of the payment transaction, such as the agreed amount of the transaction (for example, $2000000), currency type, information identifying the sending account (for example, the account of the first user), information identifying the receiving account (e.g., the account of the second user), the work ID of the first user's computer, the work ID of the second user's computer, the address ID and/or class ID of the first node's computer, the address ID and/or class ID of the second node's computer, and/or any other pertinent information. Additionally, the first node computer 165 may generate a digital signature for the final data packet.

[0168] In step S132 , which may be similar to step S113 , the first node computer 165 transmits the final data packet for the final interaction and the accompanying digital signature to the administrative node computer 150 for validation and entry into the block chain record.

[0169] In step S133 , which may be similar to step S114 , the administrative node computer 150 may verify the digital signature and/or hash value of the first node computer. If this and any other suitable verification steps are successfully performed, the administrative host computer 150 may generate an additional digital signature for the final data packet.

[0170] In step S134 , which may be similar to step S115 , the administrative node computer 150 may add information about the final interaction (and/or the entire data packet) to the entry. For example, the administrative host computer 150 may create a new block for the block chain, where the block contains the final data packet for the final interaction and the associated digital signatures. A block may also contain other unrelated data packets that were received in a similar time period (eg, a block may contain all data packets received over a 10-minute period).

[0171] In step S135 , which may be similar to step S116 , the administrative node computer 150 may transmit a copy of the data packet to the second node computer 145 .

[0172] In step S136 , which may be similar to step S117 , the second node computer 145 may authenticate the data packet. Additionally, the second node computer 145 may update its local records based on the data packet. For example, the second node computer 145 credits the secured transaction value (eg, as indicated in the second data packet) to the second user's bank account.

[0173] At a later time, steps may be taken to calculate transaction amounts for each of the payment transactions (e.g., between settlement accounts for each pair of nodes) based on the data packet records stored in the ledger in the form of a block chain (e.g., in steps S115 , S125 and S134 ). In some embodiments, batch settlement may occur at the end of the day and multiparty settlement may take place throughout the network. In some embodiments, each transaction may be settled using two steps of atomic settlement (eg, a transfer from the sender's account to the central bank's account, and then a transfer from the central bank's account to the recipient's account).

[0174] Accordingly, one smart contract may conduct the entire process (eg, the sending process), which may include a plurality of successive events, and includes the creation of a plurality of entries representing a plurality of successive interactions in response to events.

[0175] Some embodiments of the present invention may contain additional or alternative details for some aspects of the above method. For example, in step S104 , the administrative node computer 150 may optionally add a smart contract to the block chain (eg, by creating a new block that contains the smart contract). However, other embodiments may not store the smart contract on the blockchain, for example, since the blockchain may only be used to store interaction data. A smart contract may already be sufficiently enforceable and trustworthy without being added to the block chain (eg based on a trusted central administrator managing the smart contract and reserved account values).

[0176] Additionally, in some embodiments, instead of the administrative node computer 150 communicating with the first node computer 165 to obtain a digital signature for a smart contract (e.g., in step S104 ), the second node computer 145 may communicate with the first node computer 165 for that purpose. For example, the second node computer 145 and the first node computer 165 may communicate with each other to agree on the details of the smart contract, the first node computer 165 may provide a digital signature to the second node computer 145 , and then the second node computer 145 may transmit the smart contract. the contract and both digital signatures to the administrative host computer 150 (eg, in step S103 ).

[0177] Additionally, in some embodiments, the administrative node computer 150 may create data packets for transactions from the second node computer 145 , provided that the second node computer 145 has already agreed to transactions through a smart contract. Thus, instead of sending the write instruction (eg, in step S111 ), the administrative node computer 150 can generate a data packet and execute the transaction directly.

[0178] As mentioned above, embodiments allow the first node computer 165 to perform some or all of the functions performed by the second node computer 145 . For example, the first node computer 165 may generate a smart contract instead of the second node computer 145 , the first node computer 165 may provide payments to each of the other node computers instead of the second node computer 145 , and so on. purposes, and they can be interchanged or modified in any suitable way.

[0179] Method 500 has been described above as a method for sending payments to service providers that participate in the sending process. However, embodiments of the present invention may also apply to other processes and other types of record keeping. For example, the embodiments may apply to other types of transactions for goods and services and in other contexts, such as medical contexts and construction contexts. Embodiments of the present invention can be used to ensure that steps in medical procedures or processing are performed in the correct order, to ensure that steps in construction projects or fabrication projects are performed in the correct order, and/or for any other suitable orderly process. or systems.

[0180] Embodiments of the present invention have a number of advantages. For example, in embodiments of the present invention, a smart contract may define a plurality of records (eg, for interactions) to be created in response to a plurality of trigger events. Additionally, the smart contract can set the order for events and records, the central administrative node can make sure that the events occur in the correct order. As a result, new records are added to the block chain in a predefined order (for example, according to a smart contract). This ensures that the block chain is built in an orderly, organized and logical manner. It also allows the viewer to track successive records through the block chain, thus providing a replay of the perfect process. This application of a smart contract is especially useful for blockchain record systems, since blockchains generally cannot be modified once information has been added, so it is useful to filter information before adding it.

[0181] Embodiments of the present invention also advantageously provide each participating host computer with a unique private key. As a result, the notification message submitted by the host computers can be digitally signed and verifiable. In some embodiments, the smart contract is triggered by event notifications from node computers, and digital signatures enhance the security and reliability of this event triggering process.

[0182] The following will describe a computer system that can be used to implement any of the entities or components described herein. Subsystems in a computer system are interconnected via a system bus. Additional subsystems include a printer, keyboard, fixed disk, and a monitor that can be connected to a display adapter. Peripherals and input/output (I/O) devices that can be connected to the I/O controller can be connected to the computer system using any number of means known in the art, such as a serial port. For example, a serial port or external interface may be used to connect the computing device to a wide area network such as the Internet, a mouse input device, or a scanner. The system bus interconnection allows the CPU to communicate with each subsystem and manage the execution of instructions from system memory or a fixed disk, as well as the exchange of information between subsystems. The system memory and/or the fixed disk may be a computer readable medium.

[0183] As described, a service according to the present invention may include 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 the execution of a set of instructions or program code by a suitably programmed computing device, microprocessor, data processing device, or the like. The instruction set or program code may be stored in memory or a data storage element of another form that is accessed by a computing device, microprocessor, etc. In other embodiments, the functions, processes, operations, or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.

[0184] Any of the software components or functions described herein may be implemented as program code to be executed by a processor using any suitable computer language such as, for example, Java, C++, or Perl, using, for example, traditional or object-oriented approaches. Program code may be stored as a sequence of instructions or instructions on a computer readable medium such as random access memory (RAM), read only memory (ROM), magnetic media such as a hard disk or floppy disk, or optical media such as a CD-ROM. . Any such computer-readable medium may be on or in a single computing device and may be present on or in different computing devices within a system or network.

[0185] Although certain exemplary embodiments have been described in detail and shown in the accompanying drawings, it should be understood that such embodiments are illustrative only and are not intended to limit the broad invention and that this invention should not be limited to the particular arrangements and structures shown and described. , as various other modifications may be apparent to those skilled in the art.

[0186] In the context of this document, the use of the singular form means "at least one", unless otherwise indicated separately.

Claims (55)

1. A method for creating a set of records based on an ordered smart contract, comprising the steps of: receiving, by means of the administrative host computer, a smart contract indicating that the ordered set of interactions will take place in response to the ordered set of events, wherein the smart contract indicates that each interaction in the ordered set of interactions corresponds to an event in the ordered set of events, wherein the smart contract specifies that each interaction in an ordered set of interactions will take place in response to a corresponding event only if the corresponding event occurs within a particular order of events; receiving, by means of the administrative node computer, a first notification that a first event of the ordered set of events has occurred; verifying by the smart contract-based administrative node computer that the first event should occur first within the ordered set of events; determining by the administrative node computer based on the smart contract that the first interaction from the ordered set of interactions should take place in response to the first event; in response to the first event from the ordered set of events, transmitting by means of the computer of the administrative node to the computer of the second node an instruction to generate the first data packet for the first interaction from the ordered set of interactions, and the smart contract indicates that the first interaction will take place in response to the first event; receiving by means of the administrative node computer from the computer of the second node the first data packet for the first interaction; generating, by means of the administrative node computer, a first block for the block chain, the first block including a first data packet for the first interaction; receiving, by means of the administrative node computer, a second notification that a second event from the ordered set of events has occurred; verifying, by means of the smart contract-based administrative node computer, that the second event should occur second within the ordered set of events; determining by the administrative host computer based on the smart contract that a second interaction from the ordered set of interactions is to take place in response to the second event; in response to the second event from the ordered set of events, sending from the computer of the administrative node to the computer of the second node an instruction to generate a second data packet for the second interaction from the ordered set of interactions, and the smart contract indicates that the second interaction will take place in response to the second event; receiving by the administrative node computer from the second node computer a second data packet for a second interaction; and generating, by means of the administrative node computer, a second block for the block chain, the second block including a second data packet for the second interaction. 2. The method of claim 1, further comprising the steps of: in response to receiving the first notification that the first event has occurred, marking the first event as committed by the administrative node computer; and before sending the instruction to generate the second data packet for the second interaction, it is checked by the administrative node computer that the first event is marked as committed. 3. The method of claim 1, wherein a first notification that a first event has occurred is received from a third node computer, wherein the first interaction takes place between the second node computer and the third node computer, wherein the second notification that a the second event is received from the computer of the fourth node, and the second interaction takes place between the computer of the second node and the computer of the fourth node. 4. Computer of the administrative node for creating a set of records based on an ordered smart contract, containing: processor and a computer-readable medium, wherein the computer-readable medium contains code executable by a processor for implementing a method comprising: receiving a smart contract indicating that an ordered set of interactions will take place in response to an ordered set of events, wherein the smart contract indicates that each interaction in the ordered set of interactions corresponds to an event in the ordered set of events, wherein the smart contract indicates that each an interaction in an ordered set of interactions will take place in response to a corresponding event only if the corresponding event occurs within a particular order of events; receiving a first notification that a first event of the ordered set of events has occurred; checking based on the smart contract that the first event should occur first within the ordered set of events; determining based on the smart contract that the first interaction of the ordered set of interactions should take place in response to the first event; in response to the first event from the ordered set of events, instructing the computer of the second node to generate the first data packet for the first interaction from the ordered set of interactions, and the smart contract indicates that the first interaction will take place in response to the first event; receiving from the computer of the second node the first data packet for the first interaction; generating a first block for the block chain, the first block including a first data packet for the first interaction; receiving a second notification that a second event from the ordered set of events has occurred; checking based on the smart contract that the second event should occur second within the ordered set of events; determining, based on the smart contract, that the second interaction of the ordered set of interactions should take place in response to the second event; in response to the second event from the ordered set of events, instructing the computer of the second node to generate a second data packet for the second interaction from the ordered set of interactions, and the smart contract indicates that the second interaction will take place in response to the second event; receiving from the computer of the second node the second data packet for the second interaction; and generating a second block for the block chain, the second block including a second data packet for the second interaction. 5. The administrative node computer of claim 4, wherein a first notification that a first event has occurred is received from a third node computer, and a second notification that a second event has occurred is received from a fourth node computer, the method further contains: receiving a first digital signature for a first notification that a first event has occurred from the computer of the third node; verifying a first digital signature using a first public key associated with the computer of the third node, wherein an instruction to generate a first data packet is transmitted in response to verifying the first digital signature; receiving a second digital signature for a second notification that a second event has occurred from the computer of the fourth node; and verifying the second digital signature using the second public key associated with the computer of the fourth node, wherein an instruction to generate a second data packet is transmitted in response to verifying the second digital signature. 6. The administrative host computer of claim 4, wherein the method further comprises: in response to receiving the smart contract, sending messages to each computer associated with the ordered set of interactions indicating that the interaction will take place if a certain event. 7. A method for creating a plurality of data packages based on an ordered smart contract, comprising the steps of: by means of the computer of the second node, a smart contract is generated indicating that the ordered set of interactions will take place in response to the ordered set of events, wherein the smart contract indicates that each interaction in the ordered set of interactions corresponds to an event in the ordered set of events, wherein the smart contract specifies that each interaction in an ordered set of interactions will take place in response to a corresponding event only if the corresponding event occurs within a particular order of events; receiving by the computer of the second node from the computer of the administrative node an instruction to generate the first data packet for the first interaction from the ordered set of interactions, and by the computer of the administrative node this instruction was sent in response to the first notification that the first event from the ordered set of events has occurred, and verified, that the first event must occur first within an ordered set of events, based on a smart contract; in response to the first event from the ordered set of events, generating by the computer of the second node the first data packet for the first interaction from the ordered set of interactions, and the smart contract indicates that the first interaction will take place in response to the first event; transmitting, by means of the second node computer, a first data packet to the administrative node computer, the administrative node computer generating a first block for the block chain, the first block including the first data packet; receiving by the second node computer from the administrative node computer an instruction to generate a second data packet for the second interaction from the ordered set of interactions, moreover, by the computer of the administrative node, this instruction was sent in response to the second notification that the second event from the ordered set of events has occurred, and verified, that the second event must occur second within an ordered set of events, based on a smart contract; in response to the second event from the ordered set of events, generating by the computer of the second node a second data packet for the second interaction from the ordered set of interactions, and the smart contract indicates that the second interaction will take place in response to the second event; and transmitting, by means of the second node computer, a second data packet to the administrative node computer, wherein the administrative node computer creates a second block for the block chain, the second block including the second data packet. 8. The method of claim 7, further comprising transmitting, by means of the second node computer, the smart contract to the administrative host computer, the administrative host computer transmitting messages to each computer associated with the ordered set of interactions indicating that the interaction will be take place if a particular event occurs. 9. The method of claim 7, further comprising the steps of: generating, by means of the computer of the second node, a digital signature for the smart contract using the secret key; and by means of the computer of the second node, the digital signature for the smart contract is transmitted to the computer of the administrative node, while the computer of the administrative node receives an additional digital signature for the smart contract from the computer of the first node, and the additional digital signature is generated by the computer of the first node using the additional secret key. 10. Computer of the second node for creating a set of data packets based on an ordered smart contract, containing: processor and a computer-readable medium, wherein the computer-readable medium contains code executable by a processor for implementing the method according to any one of claims 7-9.

Images