Hierarchy-based blockchain

Abstract

A computer-implemented method comprising receiving a transaction request from a first node within the plurality of nodes, the transaction request corresponding to a pending transaction between the first node and a second node; identifying a blockchain associated with the pending transaction, the blockchain including a first block instance having a hierarchy file indicating a hierarchy among the first node, the second node, and the third node; identifying a second block instance having an executable file to approve the transaction request received from the first node; executing the executable file, wherein the executable file is configured to retrieve data from a data source associated with the third node and analyze data to approve or deny the transaction request; and appending a third block instance comprising the set of transaction attributes to the blockchain.

Description

(19) *EP004675968A2* (11) EP 4 675 968 A2 (12) EUROPEAN PATENT APPLICATION (43) Date of publication: 07.01.2026 Bulletin 2026 / 02 (21) Application number: 25217683.9 (22) Date of filing: 25.10.2021 (51) International Patent Classification (IPC): H04L 9 / 00 (2022.01) (52) Cooperative Patent Classification (CPC): H04L 9 / 50; G06F 21 / 64; G06Q 20 / 401; G06Q 20 / 4014; G06Q 40 / 04; H04L 9 / 3239; G06Q 2220 / 00; H04L 2209 / 56 (84) Designated Contracting States: AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR (30) Priority: 12.11.2020 US 202017096620 (62) Document number(s) of the earlier application(s) in accordance with Art. 76 EPC: 21892557.6 / 4 244 793 (71) Applicant: Citibank, N.A. New York, NY 10013 (US) (72) Inventor: MARSH, Ryan Billericay, Essex CM120JB (GB) (74) Representative: Bjerkén Hynell KB P.O. Box 1061 101 39 Stockholm (SE) Remarks: This application was filed on 21‑11‑2025 as a divisional application to the application mentioned under INID code 62. (54) HIERARCHY‑BASED BLOCKCHAIN (57) A computer-implemented method comprising receiving a transaction request from a first node within the plurality of nodes, the transaction request corre- sponding to a pending transaction between the first node and a second node; identifying a blockchain associated with the pending transaction, the blockchain including a first block instance having a hierarchy file indicating a hierarchy among the first node, the second node, and the third node; identifying a second block instance having an executable file to approve the transaction request re- ceived from the first node; executing the executable file, wherein the executable file is configured to retrieve data from a data source associated with the third node and analyze data to approve or deny the transaction request; and appending a third block instance comprising the set of transaction attributes to the blockchain. EP 4 67 5 96 8 A 2 Processed by Luminess, 75001 PARIS (FR) 2 1 EP 4 675 968 A2 2 Description CROSS-REFERENCE TO RELATED PATENT APPLI- CATIONS

[0001] This application claims priority to U.S. Provi- sional Application No. 17 / 096,620, entitled "Hierarchy- Based Blockchain," filed November 12, 2020, which is hereby incorporated by reference in its entirety. TECHNICAL FIELD

[0002] This application relates generally to implement- ing a hierarchical data structure using blockchain-based technology. BACKGROUND

[0003] As the processing power of computers allows for greater computer functionality and the Internet tech- nology era allows for interconnectivity between comput- ing systems,many institutions are shifting towards block- chain-based technology to store and maintain the integ- rity of transaction data. While blockchain-based storage methods may require more computational resources than conventional methods (e.g., a central database), the immutability of the datawithin the blockchain enables operators to have peace of mind that the data in the blockchain is accurate and will not be changed.

[0004] In some instances, large organizations that manage transactions between many legal entities may use blockchain-based technology to keep track of the transactions. While the legal entities may fall under the same corporate umbrella, each of the legal entities may maintain its own distributed ledger to keep track of any transactions it performs and its current financial status. Given the large amount of computational resources that are required tomaintain just one distributed ledger,main- taining separate blockchains for many legal entities may incur a large processing burden on the organization.

[0005] The processing burden may require the cor- poration to utilize more processors and memory and, in some cases, may cause the corporation to maintain data warehouses or server farms that are dedicated to storing the transaction data. Such processing may also incur increased electricity usage given the amount of energy nodesexpendas they verify block instanceseach time they add a new block to the respective blockchain. This problemmay be exacerbated as the number of legal entities and corresponding blockchains that fall under the organization increases given the large number of nodes that are often needed to maintain the integrity of indivi- dual blockchains to stop malicious parties from gaining control of the data. SUMMARY

[0006] For the aforementioned reasons, there is a need for a method to maintain a centralized blockchain that is accessible to multiple legal entities under a cor- porate umbrella without requiring each legal entity to maintain its own blockchain. Themethod aims to provide functionality that enableseach legal entity to contribute to the blockchainwhilemaintaining the privacy of any trans- actions towhich it commits.Disclosedhereinaresystems and methods for creating a hierarchy-based blockchain that enables related legal entities to append transaction blocks to a blockchain using a rule and / or hierarchy- based method. The systems and methods may also enable blocks to be added to the blockchain without a quorum of all of the nodes that maintain the blockchain verifying the authenticity of the transaction.

[0007] Implementations of the systems and methods described herein may integrate hierarchy files and scripted executable code (e.g., smart contracts) into a central blockchain so nodes that maintain the blockchain may more easily determine how to authenticate transac- tions between internal nodes. For example, if an investor node and an issuer node of the blockchain seek to enter into a transaction, the investor node may submit a trans- action request to the other nodes thatmaintain the block- chain and the nodes may check the hierarchy and / or the rules of a smart contract that are stored on the blockchain to determine the requirements for the transaction to be approved (e.g., for a block instance tobeappended to the blockchain). The nodes may determine that only a set of nodes at a predetermined tier of the hierarchy above the investor node need to approve of the transaction for the transaction to be authorized. The set of nodes may use smart contracts that arestoredon theblockchain tocheck to make sure the terms of any transaction conform to established rules of the legal entities.

[0008] Because of the hierarchy and rule-based mod- el, the systems andmethods described herein may elim- inate theneed for individual legal entities tomaintain their own blockchains or other ledger technologies and allow for a single blockchain to store transaction data for transactions between legal entities to be processed andapproved.The rules thatare storedon theblockchain may further enable the legal entities to ensure they can uniquely control the transactions into which they enter despite such transactions being managed by a global authority.

[0009] In one embodiment, a system comprises a plur- ality of nodes each corresponding to a computing device having a processor and memory to store data, wherein each processor is configured to: receive a transaction request from a first node within the plurality of nodes, the transaction request corresponding to a pending transac- tion between the first node and a second node within the plurality of nodes via a third node within the plurality of nodes, the transaction request comprising a set of trans- action attributes, wherein the first node is not in direct communication with the second node; identify a block- chain associatedwith the pending transaction, the block- chain including a first block instance having a hierarchy 5 10 15 20 25 30 35 40 45 50 55 3 3 EP 4 675 968 A2 4 file indicating a hierarchy among the first node, the sec- ondnode, and the third node; in response to thehierarchy file indicating that transaction requests from the first node must be approved by the third node, identify a second block instance having an executable file to approve the transaction request received from the first node; execute the executable file, wherein the executable file is config- ured to retrieve data from a data source associated with the third node and analyze the retrieved data associated with at least one of the first node, the second node, third node, or the set of transaction attributes to approve or deny the transaction request; and in response to receiv- ing an indication of approval from the executable file, append a third block instance comprising the set of transaction attributes to the blockchain.

[0010] In another embodiment, a method comprises: receiving, by a consensus of a plurality of nodes, a transaction request from a first node within the plurality of nodes, the transaction request corresponding to a pending transaction between the first node and a second node within the plurality of nodes via a third node within the plurality of nodes, the transaction request comprising a set of transactionattributes,wherein the first node is not in direct communication with the second node; identify- ing, by the consensus of the plurality of nodes, a block- chain associatedwith the pending transaction, the block- chain including a first block instance having a hierarchy file indicating a hierarchy among the first node, the sec- ondnode, and the third node; in response to thehierarchy file indicating that transaction requests from the first node must be approved by the third node, identifying, by the consensus of the plurality of nodes, a second block instance having an executable file to approve the trans- action request received from the first node; executing, by the consensus of the plurality of nodes, the executable file, wherein the executable file is configured to retrieve a data from a data source associated with the third node and analyze data associated with at least one of the first node, the second node, third node, or the set of transac- tion attributes to approveor deny the transaction request; and in response to receiving an indication of approval from the executable file, appending, by the consensus of the plurality of nodes, a third block instance comprising the set of transaction attributes to the blockchain.

[0011] It is to be understood that both the foregoing general description and the followingdetailed description are exemplary and explanatory and are intended to pro- vide further explanation of the invention as claimed. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Theaccompanyingdrawingsconstituteapart of this specification, illustrate an embodiment of the inven- tion, and together with the specification, explain the in- vention. FIG. 1 illustrates implementation of a hierarchy- based blockchain system, according to an embodi- ment. FIG. 2 illustrates appending block instances to a blockchain, according to an embodiment. FIG. 3 illustrates node hierarchy of a hierarchy- based blockchain system, according to an embodi- ment. FIG. 4 illustrates a flowchart depicting operational steps for implementing a hierarchy-based block- chain system, according to an embodiment. FIG. 5 graphically illustrates implementing a hierar- chy-based blockchain system, according to an em- bodiment. DETAILED DESCRIPTION

[0013] Reference will now be made to the exemplary embodiments illustrated in the drawings, and specific language will be used here to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Alterations and further modifications of the inventive features illu- strated here, and additional applications of the principles of the inventions as illustrated here, which would occur to a person skilled in the relevant art and having possession of this disclosure, are to beconsideredwithin thescopeof the invention.

[0014] FIG. 1 illustrates components of a hierarchy- based blockchain system 100, according to an embodi- ment. The system 100may comprise an analytics server 110a, a system database 110b, distributed peer nodes 120a-c (hereinafter referred to as peer nodes 120 or peer node 120), a client device 140, and a network 150. Aspects of the system 100may be configured to employ andmanage a systemblockchain, sometimes referred to in the art as a "distributed ledger," and may include blockchain-based distributed ledger software (e.g., Hy- perledger, Ethereum, Openchain, and TerraLedger). Network 150may be any synchronous or asynchronous network. The system blockchain may operate as a dis- tributed database that stores data records associated with users and transactions between peer nodes 120, where the data records stored on the system blockchain may be blocks of data (e.g., block instances or blocks) that are hosted (e.g., locally stored or otherwise in pos- session of each distributed, such as being remotely hosted or hosted in a cloud) on distributed peer nodes 120. The system database 110bmay also store records associated with transactions between peer nodes 120. Data stored in records within system databases 110b may vary from the data stored in blocks of the system blockchain hosted on peer nodes 120. Furthermore, each block instance may not be accessible to other peer nodes120,howeverall block instancesmaybeaccessed by the analytics server 110a and / or may be stored in the 5 10 15 20 25 30 35 40 45 50 55 4 5 EP 4 675 968 A2 6 system database 110b. In some embodiments, the ana- lytics server 110a may generate a duplicate of one or moreblock instanceswithin theblockchainandstoresaid block instances in the system database 110b.

[0015] While the analytics server 110a may dictate accessibility and transmit instructions to other parties within system 100, each peer node within the distributed peer nodes 120 (e.g., creators of the block instance) or the client (via the client device 140) may prevent others within the system 100 from accessing at least portions of thedatawithinoneormoreblock instances.Forexample, while generating a block instance, a peer node 120may encrypt a portion of the block instance so one or more peer nodes 120 may be unable to access the encrypted portion. Peer nodes 120 of a transaction may encrypt transaction data of a block instance so entities that were not privy to the transaction may not be able to view or access the transaction details. Consequently, only the peer nodes 120 that were privy to the transaction may access the data (e.g., by using their respective PKI key).

[0016] The analytics server 110amay be any comput- ing device comprising a processor and non-transitory machine-readable storage capable of executing the var- ious tasks and processes described herein. Non-limiting examples of such computing devices may include work- station computers, laptop computers, server computers, laptop computers, and the like. In some embodiments, the analytics server 110amay be or include one or more peer nodes of peer nodes 120 that maintain the system blockchain. The analytics server 110amay generate and display a user interface on the client device 140. An example of a user interface generated and hosted by theanalytics server110amaybeawebsite. Theanalytics server 110amay host a website accessible to end-users, where the content presented via the various webpages may be controlled based upon end-users’ accounts an- d / or account permissions.

[0017] While the system 100 includes a single analy- tics server 110a, in some configurations, the analytics server 110a may include any number of computing de- vices operating in a distributed computing environment.

[0018] The analytics server 110a may execute soft- ware applications configured to display the user interface (e.g., host a website), which may generate and serve various webpages to the client device 140 or each peer node of the distributed peer nodes 120.Thewebsitemay be used to generate and access data stored on the system database 110b or a blockchain hosted by nodes 120. In some implementations, the analytics server 110a may be configured to require user authentication based upon a set of user authorization credentials (e.g., user- name, password, biometrics, cryptographic certificate, and the like). Such authorization credentials may corre- spond to a peer node account or a user account that is otherwise associated with a peer node 120. In such implementations, the analytics server 110a may access the system database 110b, which may be configured to store user credentials. The analytics server 110amay be configured to reference the stored user credentials to determine whether a set of entered credentials (purport- edlyauthenticating theuser)matchanappropriate stored set of credentials that identify and authenticate the user.

[0019] The system database 110b can be a dynamic database that includes transaction records that the sys- tem database 110b receives from the peer nodes 120 and from various other sources (e.g., data source provi- ders). The system database 110b can be a graph data- base, MySQL, Oracle, Microsoft SQL, PostgreSql, DB2, document store, search engine, key-value store, etc. The system database 110b may be configured to hold any amount of data and can be made up of any number of components. Transaction records stored in the system database 110b may comprise one or more data fields (e.g., attributes and / or attribute values) containing trans- action-identifying hash values generated by the analytic server 110a according to a hashing algorithm implemen- ted by the peer nodes 120. When a new transaction record containing a machine-readable computer file (e.g., PDF, DOC, XSL), is received, the analytic server 110amay store the new transaction record in the system database 110b. The analytic server 110a may also gen- erate a hash value for the new transaction record and store the hash value in the system database 110b. The hash value may be a unique identifier for the particular transaction record and may be used by various comput- ing devices of the system 100, such as the system database 110b, to reference the computer file or meta- data describing the computer file. The computer file may be stored in the system database 110b and / or on a block instance of the system blockchain that is hosted on peer nodes 120.

[0020] In some embodiments, the system database 110b may include a hierarchy file indicating a hierarchy of thedifferent nodesof thesystem100.Thehierarchyfile may include information indicating which nodes are at which tier of the hierarchy and the rules associated with each tier (e.g., the number of nodes of each tier that must approve the transaction for the respective tier to author- ize a transaction). The hierarchy file may also include indications of the transaction attributes that are relevant to each tier (e.g., the transaction attributes that the peer nodes 120may provide to nodes of the tier to authorize a transaction). As described herein, a similar hierarchy file may be stored on the system blockchain.

[0021] The system database 110b may be hosted on any number of computing devices comprising a non- transitory machine-readable storage medium and may be capable of performing the various tasks described herein. The system database 110bmay be accessed by the peer nodes 120 via the network 150.

[0022] Peer nodes 120 may represent one or more institutions under the same corporate umbrella (e.g., each peer node 120may be a computing device or group of computing devices of an affiliate of the same com- pany), entities that are associated with the corporate umbrella, and / or entities that are outside of the corporate 5 10 15 20 25 30 35 40 45 50 55 5 7 EP 4 675 968 A2 8 umbrella. Peer nodes 120 may represent any group of computing devices (e.g., anygroupof computing devices that perform transactions with each other and maintain a blockchain for such transactions). Each peer node 120 may have its own status within the corporate umbrella or maybeoutsideof thecorporateumbrellaaltogether (e.g., investor nodes may not be under the corporate umbrella of different custodian nodes or issuer nodes). For exam- ple, as is described in more detail with respect to FIG. 3, peer nodes 120 may be investor nodes, broker dealer nodes, prime dealer nodes, global custodians, sub-cus- todians, central security depository nodes, etc. A peer node 120 may be any computing device comprising a processor and a non-transitory machine-readable sto- rage medium capable of performing the various tasks and processes described herein. Non-limiting examples of a peer node may be a workstation computer, laptop computer, tablet computer, and server computer. Although three peer nodes are shown, any number of peer nodesmay be utilized. Although the peer nodes 120 are described as storing blocks of the blockchain in FIG. 1, other computing devices, such as the analytics server 110a,may host blocks of the blockchain or host a corre- sponding blockchain. Each peer node 120 may locally store an instance of the system blockchain in the storage medium of the system blockchain, and may further exe- cute a software application that instructs the peer node 120 to generate andquery blockswithin the locally stored blockchain instance as described herein.

[0023] In some embodiments, the analytics server 110amaygenerateandhostwebpages for a client device 140. The client device 140may be one or more comput- ing devices that can access such webpages by signing into accounts that are associated with individual peer nodes 120. The client device 140 may be any type of computing device. The analytics server 110a may gen- erate webpages based upon a peer node’s 120 role within the system 100 (e.g., investor, global custodian, broker dealer, prime broker, global custodian, sub-cus- todian,CSD, or issuer). For example, theanalytics server 110amay identify theaccount of apeernode120 (e.g., an account being accessed by the client device) that has logged into the system to initiate a transaction or view the attributes of the transaction. The analytics server 110a may select a user interface to present to the node based on the account characteristics that indicate the type or role of the peer node 120. For instance, the analytics server 110a may generate a user interface that allows investor nodes to initiate transactions, a user interface that allows custodian nodes tomaintain or approve trans- actions, a user interface that enables issuers to provide securities for sale or to view potential transactions in- itiated by investor nodes, etc. In such implementations, the characteristics identifying each node’s role may be defined by data fields and input fields in account records stored in the systemdatabase110b.Theanalytics server 110a may authenticate an account and identify the ac- count’s role by executing an access directory protocol (e.g. LDAP). The analytics server 110a may generate webpage content, access or generate data stored in the system database 110b, and access or generate data stored in the blockchain instances, according to the account’s role defined by the account record in the sys- tem database 110b.

[0024] In operation, in some embodiments, a user at the client device 140 may provide an input into a user interface generated by the analytics server 110a to in- itiate a transaction between a first and second peer node 120. The transaction may be a security purchase or a bond purchase and have various attributes (e.g., trans- action type (e.g., securities purchase, bond purchase, etc.), initiation date, amount, transacting peer, currency, etc.). Upon receiving the transaction by the client device 140 for the first peer node 120, the analytics server 110a may forward the transaction request to the other peer nodes 120. For example, the client device 140 may initiate, via a user interface, a transaction between an investor node and an issuer node by logging into an account associated with the investor node and providing an input that causes the investor node to purchase an asset such as a bond or a number of shares that were issued by the issuer node. The client device 140 may input the transaction attributes of the transaction into the user interface and the analytics server 110amay forward the transaction request to one or more prime broker nodes and / or one or more global custodian nodes of the peer nodes 120 (e.g., a third peer node 120) for processing. The analytics server 110a may forward the transaction request to any number of peer nodes 120 except for, in some cases, the second peer node 120 (e.g., the issuer node). In some cases, the analytics server 110a may forward the transaction request to a consensusof thepeernodes120.Thenetworkmayallow this transaction to be broadcast to all relevant nodes (e.g., nodes of the transaction and / or nodes that are verifying the transaction) simultaneously or sequentially, depending on network configuration.

[0025] The consensus of the peer nodes 120 may receive the transaction request and identify a blockchain that theymaintainand that isassociatedwith thefirst peer node 120, the second peer node 120, and the third peer node 120. The consensus may identify a block instance from the blockchain that stores a hierarchy file. The hierarchy file may indicate different tiers and / or groups of peer nodes 120 including a hierarchy among the first peer node, the second peer node, and / or the third peer node. For example, the hierarchy file may indicate that the first peer node is an investor peer node 120 at the bottom of the hierarchy and the second peer node is an issuer peer nodeat the topof thehierarchy. Thehierarchy file may indicate that the third peer node 120 is a global custodian peer node among multiple global custodian peer nodes 120 that are on an upper tier of the hierarchy.

[0026] The hierarchy file may indicate that the global custodian peer nodes 120 that are on the upper tier of the hierarchy must approve any transaction that is initiated 5 10 15 20 25 30 35 40 45 50 55 6 9 EP 4 675 968 A2 10 by the first peer node 120. Accordingly, the consensus of the plurality of nodes may identify a block instance that stores files or that is otherwise associated with the global custodian peer nodes 120on the systemblockchain. The block instance may be or include a smart contract that, upon execution, causes the consensus to retrieve data from a data source (e.g., a blockchain or a central data- base) associated with the global custodian peer nodes 120 that includes one or more rules indicating which transactions to allow and / or decline. The consensus of the peer nodes 120 may provide the global custodian nodes with transaction attributes that correspond to the custodian nodes. Each of the global custodian peer nodes 120 may compare the transaction attributes of the transaction to the rules and, responsive to one of the rules being satisfied, transmit indications to the plur- ality of nodes to indicate their approval. However, re- sponsive to a custodian peer node 120 determining none of the rules are satisfied, the custodian peer node 120 may send back an indication that it does not approve of the transaction. The consensus of the peer nodes 120 may maintain a count for each custodian peer node 120 that transmits an indication authorizing the transaction.

[0027] The consensus of the peer nodes 120 may determinewhether aquorumof the custodianpeer nodes 120 has approved of the transaction by comparing the count to a user set threshold.Upondetermining the count exceeds the threshold, the consensus of the peer nodes 120 may determine the custodian peer nodes 120 have approved of the transaction and transmit a signal to the second peer node 120 indicating the transaction was approved by the custodian peer nodes 120.

[0028] The second peer node 120 may receive the indication anddeterminewhether to approveof the trans- action. Thesecondpeer node120maydo sobasedon its own set rules or based on a user input. Upon the second peer node 120 approving the transaction, the second peer node 120 may transmit a signal to the consensus of the peer nodes 120 indicating the approval, and the consensus of the peer nodes 120 may append a block instance to the system blockchain indicating the transac- tion attributes and other data associated with the trans- action (e.g., timestamp data, the peer nodes involved in the transaction, the votes of the global custodian peer nodes 120, etc.). In someembodiments, the secondpeer node 120 and / or the consensus may transmit a signal to the analytic server 110a indicating the approval and the transaction attributes of the transaction. The analytic server 110a may store transaction data in the system database 110b as a record to maintain a record of the transaction off-blockchain for added security such as to have data to compare against the system blockchain to check if the system blockchain was compromised.

[0029] When appending block instances to the system blockchain, the peer nodes 120 may generate block addresses for data to be retrieved from the respective blockchain. To do so, the peer nodes 120maygenerate a hash value for the transaction record of the block in- stance, where the hash value or other identifier values may be a block address to reference the block instance within the blockchain. The peer nodes 120a-c may gen- erate the hash value for the transaction record by gen- erating a hash based on the transaction record (e.g., based on all or a portion of the data of the transaction record) and the data of the immediately preceding block data or block address. This block address may then be stored into the system database 110b in a document record along with the transaction record and any number of additional data field entries related to the transaction record.

[0030] In operation, the analytics server 110a or peer nodes 120 may reference the block of the blockchain containing the file according to the block address. The analytics server 110a or peer nodes 120 may generate additional blocks and corresponding block addresses on the system blockchain in a similar manner (e.g., gener- ating a hash value for a block containing user data and then generating a new block address using the block addressof theprecedingblock). Blockaddressesmaybe generated in any number of combinations of hashed block data and / or hashed block addresses from the new block and one or more preceding blocks, such that the address of the new block is dependent upon, or otherwise linked to, at least the immediately preceding block.

[0031] In some embodiments, a peer node 120 may generate new blocks on a locally stored instance of the system blockchain according to data received from the analytics server 110a or other peer nodes 120. The analytic server 110a may query the block instances of the system blockchain according to a block address stored in the system database 110b.When the analytics server 110a executes the query of the blocks on the system blockchain, the analytics server 110a may poll the peer nodes 120 to determine themost recent data on the system blockchain (e.g., latest valid blockchain).

[0032] In some embodiments, the analytics server 110a (or peer nodes 120) may ensure that the data of the system blockchain is accurate according to a voting mechanism encodedwithin the blockchain software exe- cuted by the peer nodes 120. Each peer node 120 may receive a query for the block instance and block address, and return a response to the analytics server 110a in- dicating whether the block address contains the same data. Theanalytics server110amayselect thismethod to combat possible fraud and to be certain that data in the blockchain is resistant to corruption, as each block in- stance on a quorum or consensus of the peer nodes 120 wouldneed tobecorrupted in thesameway for apossible security breach. In this way, the analytics server 110a may also be prevented from acting on obsolete data. For instance, a peer node 120 may attempt to modify infor- mation about a particular transaction. By modifying the information within the block instance, the hash value of saidblock instancemaychange,whichwould result in the block instance being disconnected from other block in- 5 10 15 20 25 30 35 40 45 50 55 7 11 EP 4 675 968 A2 12 stances within the blockchain. Furthermore, when quer- ied, other peer nodes 120may indicate that the modified block instance does not match a version of the data storedon their respectivenodes.Asa result, theanalytics server 110a may determine that the modified block in- stance has been indeed tampered with. The peer nodes 120may then refuse to use the modified block instance.

[0033] As described above, the process performed by the peer nodes 120may be performed by a consensus of the peer nodes 120. A consensus may be a majority, all, or a number above a predetermined threshold (which may be set and be adjusted by an administrator). The peer nodes 120 may each perform the process to verify the validity of a transaction between peer nodes 120. In some embodiments, different nodes of the consensus may perform different steps of the process. Responsive to a consensus of the peer nodes 120 receiving an indication of approval of a transaction request, the con- sensus may append a block instance for the respective transaction to the blockchain maintained by the peer nodes 120. In some cases, peer nodes 120 may in turn append block instances to blockchains maintained in- ternally by the respective peer nodes 120. Because the peer nodes 120 may append a block instance to the blockchain using the hierarchy-based method, the peer nodes may append the block instance to the blockchain without requiring a quorum, substantially lowering the required resources to maintain the blockchain.

[0034] Referring now to FIG. 2, a non-limiting example of appending block instances to a blockchain comprising different block instances is illustrated. As depicted inFIG. 2, a blockchain 208 comprising block instances 202a‑202n (collectively 202) may include data 204a‑204n (collectively 204) that enables information, such as transaction data, hierarchical data (e.g., a hier- archy file indicating a node hierarchy of the blockchain), smart contract data, machine-readable code / docu- ments, and other metadata associated with one or more transactions of the peer nodes described above. The block instances 202 may also contain hash values 206a‑206n (collectively 206) that are used to link each of the block instances to the preceding block instance, as understood in the art.

[0035] Peer nodes may generate (or instruct a block- chain service to generate) the block instance 202a (e.g., the genesis block). The peer nodes may receive data 204a from a first peer node or a first computing device via a GUI provided by an analytic server on the first comput- ing device or peer node. For example, an administrator using the first computing device may log in to a website hosted or otherwise associated / managed by the analytic server and transmit data204b (e.g., a transaction record) to other peer nodes. The peer nodes may verify the data 204b against data of a corresponding transaction record. Responsive to determining the data matches, the peer nodes may generate a block instance for the blockchain that theymaintain. Upon generation of the block instance 202b, the peer nodesmay generate the hash value 206b based on the data 204b (and / or data of the immediately previous block instance), an identifier of the first comput- ing device, and / or other identifier information (e.g., time stamp and / or geolocation information). The identification information may be used as a veracity scale factor that the information is true and accurate.

[0036] The peer nodes may generate (or instruct a blockchain service to generate) the block instance 202c. The peer nodes may receive data 204c from a second computing device (e.g., a second peer node) via a GUI provided by the analytic server on the second computing device. For example, an administrator using the second computing device may log in to a website hosted or otherwise managed by the analytic server and the second computing device may transmit data 204c to the peer nodes. The peer nodes may generate a hash value 206c based on the data204c andother information as described above.

[0037] Thehash value 206cmaybebased on the hash value 206b and / or the data 204c. The peer nodes may incorporate thehash value206b into thehash value206c to append the block instance 202c to the block instance 202b.The peer nodesmay subsequently poll all the peer nodes to ensure the highest integrity of the blockchain by appending the latest block instance to the latest valid blockchain instances (e.g., the last blockchain for which there was a quorum). Using this method, block instances within the blockchain 208 may be appended to the pre- ceding block instance. The peer nodes may generate block instances 202c-n using the same methods ex- plained above to continuously update the blockchain 208. As depicted, block instances 202a, 202b, 202c, and 202n are connected because of synchronization of hash values 206a, 206b, 206c, and 206n.

[0038] Modification of datawithin a block instancemay disconnect that block instance from the blockchain. The peer nodes may use this method to combat possible fraud or unauthorized modification of the data within blockchain instances. For example, if the second admin- istrator using the second computing devicemodifies data 204bwithin block instance202b, thehashvalue206bwill also be modified. As explained above the hash value 206bmaybebasedon (orat leastpartially basedon)data 204b; therefore if data204b ismodified, hash value206b will also bemodified. Modification of the data 204b or the hash value 206c may break the link between block in- stance 202b and block instance 202c because hash value 206c is at least in part generated based on hash value 206b.

[0039] FIG. 3 illustrates a non-limiting example of a node hierarchy (e.g., node hierarchy 300). The node hierarchy 300 may be an example hierarchy showing communicative relationships between a plurality of nodes of a hierarchy-based blockchain system. Node hierarchy 300may include investors 302a-c (hereinafter referred to as investors 302 or investor 302), broker dealer 304, prime dealer 306, global custodian 308, sub-custodian 310, central securities depository (CSD) 5 10 15 20 25 30 35 40 45 50 55 8 13 EP 4 675 968 A2 14 312, and issuer 314, in some embodiments. Node hier- archies may include any number of nodes or different types of entities. An investor 302 may be or include a node that initiates a transaction by purchasing an asset such as a bond or stock. A broker dealer 304 may be or include a node that executes transactions for assets. In some instances, a broker dealer 304 may hold or store assets themselves. A primedealer 306maybeor include a node that executes transactions but provides custody for investors 302.

[0040] Aglobal custodian308maybeor includeanode that provides portfolio custody services for clients in multiple markets or across different blockchain environ- ments. A sub-custodian 310 may be or include a node that is the legal owner of an asset. A sub-custodian may hold or store assets on behalf of clients such as investors 302.CSD312maybeor includeanode that storesand / or maintains a register of the owners of assets on behalf of one or more issuers 314. Issuer 314may be or include a node from which investors 302 purchase assets. Each entity of node hierarchy300maybeor include a separate node that may communicate with other nodes within node hierarchy 300, as illustrated. Node hierarchies may be organized in any fashion.

[0041] Variousparties shown in thenodehierarchy300 may belong to different entities and may utilize different computing devices to interact with the same blockchain. As discussed herein, these parties may have competing and / or conflicting interests. Therefore, data generatedby different parties may not be treated equally. A single blockchain may be configured using the methods de- scribed herein, such that the investor 302a and the sub-custodian 310 can add data to the blockchain using different blockchain consensus. That is, the blockchain is configured to use different protocols for adding data based on a node’s position within the node hierarchy 300.The node hierarchy 300maybe revised by a system administrator.

[0042] FIG. 4 illustrates execution of a method 400 for implementing a hierarchy-based blockchain, according to an embodiment. Other embodiments may comprise additional or alternative steps, or may omit some steps altogether. Each of the steps of the method 400 may be performed (in some cases separately) by one or a com- bination of a server and / or any of a plurality of nodes that maintain a blockchain.

[0043] At step 402, a consensus of a plurality of nodes may receive, from a first node, a transaction request to initiateapending transactionbetween thefirst nodeanda second node of the plurality of nodes. The transaction request may include transaction attributes (e.g., amount, time, parties to the transaction, etc.) for a potential trans- action between the first node and the second node such as a bond purchase or a purchase of shares. As ex- plained above, a server associated with the plurality of nodesmay generate a graphical user interface to provide transaction record services to the first node. In an embo- diment, the graphical user interface may be a website hosted by a server or one of the peer nodes, which may beavailable toeachof theplurality of nodes. Thepurpose of saidwebsitemaybe to collect transaction data such as data in transaction records, and to provide a platform to securely upload transaction data, and / or to possibly re- trieve transaction data from the peer nodes.

[0044] The graphical user interface may act as an intermediary between different nodes involved in a trans- action and may be a central and "one-stop" website for facilitating transactions between peer nodes, storing data of the transactions, and / or retrieving such data. While the described graphical user interface is described herein as a central management tool, neither the peer nodes nor the graphical user interface deviate from the spirit of the distributed nature of the blockchain technol- ogy.Thepeernodesmayprovide themanagement tool to reduce the computational burden of keeping record with- in different and unrelated databases. Blockchain and block instances may be stored in individual peer node databases.

[0045] Thedifferent nodesof theplurality of nodesmay have different types of accounts for the website. Types of accounts may be, for example, investor, broker dealer, prime broker, global custodian, sub-custodian, central security depositories (e.g., securities databases), and / or asset issuer. As described above, each type of account may have different responsibilities formanaging transac- tions that are executed andmaintained on the blockchain and / or be responsible for verifying different transaction attributes. In some instances, the different types of ac- counts may be dedicated to different types of assets or perform different functions when facilitating transactions between nodes that maintain the blockchain.

[0046] A third node of the plurality of nodes (e.g., a global custodian or a prime broker) may be dedicated to verifying or enabling transactions between nodes of the plurality of nodes. The third node may receive the trans- action request from the first node, in some cases via a private communications channel the third node shares with the first node. The third node may receive and forward the request to other nodes of the plurality of nodes to determine whether to authorize the transaction. In someembodiments, the third nodemay send a prompt to the second node to indicate the first node is initiating a transaction and the terms of the transaction. Conse- quently, the first node may initiate a transaction with the second node without any direct communication with the first node, enabling the third node to facilitatewhether to allow the transaction to be authorized.

[0047] For example, an investor node may submit a transaction request to initiate a bond purchase from a custodian node. The custodian node may forward the request to other nodes that manage the blockchain and send a prompt indicating the transaction request and its transaction attributes to the issuer node that issued the bond.

[0048] Upon receiving the transaction request, at step 404, theconsensusof theplurality of nodesmay identify a 5 10 15 20 25 30 35 40 45 50 55 9 15 EP 4 675 968 A2 16 blockchain that is associated with the pending request. Theblockchainmaybeablockchain that ismaintainedby the plurality of nodes including, for example, the first node, the second node, and / or the third node. The block- chain may include transaction data of transactions that are processed between the nodes that maintain the blockchain and other data associated with the nodes (e.g., smart contracts, geographical location information, rules to allow for transactions to be authorized, financial data, etc.).

[0049] The blockchain may include a block instance that contains a hierarchy file. The hierarchy file may include a hierarchy of the nodes of the plurality of nodes with tiers that indicate permissions that are required for different nodes to append block instances to the block- chain. The data structure of the hierarchy file may be an organized list of the different nodes and their tiers, tags associated with the nodes indicating their tiers, various rules identifying the different devices within the tiers, etc. The nodes may be represented in the hierarchy by var- ious identifiers (e.g., device identifiers, account identi- fiers, group entity identifiers, or any other type of identi- fier). For example, in one embodiment, the hierarchy file may include two tiers. A node in the bottom tier may require permission from a quorum or a predetermined number of nodes of the top tier for a transaction to be authorized. For instance, an investor node may be in the bottom tier of the hierarchy and prime broker nodes may be in the top tier. When the investor node initiates a transaction with an issuer node (which may also be in the top tier), the investor node may need permissions from a quorum of the prime broker and / or custodian nodes for the transaction to be allowed and for the con- sensus to append a block instance for the transaction to the blockchain.

[0050] The hierarchy may include more than two tiers of peer nodes. For example, a bottom tier may include investor nodes, thenext tiermay includeglobal custodian nodes, the next tier may include sub-custodian nodes, the next tiermay includeCSDnodes, and the top tiermay include issuer nodes. The hierarchy file may include different rules for the tiers such as amajority of the global custodian nodesmust approve the transactionwhile only one of the sub-custodian nodes must approve the trans- action for the transaction to be allowed. The nodes of each tier may execute smart contracts on the system blockchain or otherwise analyze data retrieved from ex- ecution of the smart contract to determine whether the terms of the transaction comply with their associated rules and therefore determine whether to approve of the transaction. The hierarchy file may include any num- ber of rules or tiers.

[0051] The hierarchy file may include rules that indi- cate which tiers of the hierarchy for the consensus of the plurality of nodes to identify. The rulesmay be associated with different transaction attributes that are associated with the individual tiers. For example, the hierarchy file may include rules where transactions that are initiated at specific times may be verified by a specific tier of the hierarchy or transactions that have specific transaction attributes (e.g., transaction type, amount, etc.) may be verified by a specific tier of the hierarchy. In some embo- diments, nodes of individual tiers of the hierarchy may only add specific types of data to the blockchain. The hierarchy file may include any number or type of such rules.

[0052] The consensus of the plurality of nodes may identify the tiers of the nodes that are involved in the potential transaction (e.g., the first node, the second node, and / or the third node). The consensusmay identify the identifiers for the first node, second node, and / or the third node and determine the tier of each node. Based on the third node having a higher tier than the first and / or secondnode, theconsensusmaydetermine that the third node or a quorum of nodes on the same tier as the third node needs to approve the transaction request for the transaction to be authorized.

[0053] In response to the hierarchy file indicating that transaction requests from the first node must be ap- proved by the third node, at step 406, the consensus may identify a second block instance that has an execu- table file that is configured to approve transaction re- quests received from the first node. The consensus may identify the second block instance based on an identifier containedwithin the second block instance that indicates the block instance comprises data associated with the third node. The executable file may be a smart contract that is associated with the third node. The smart contract may be configured to retrieve data from a data source (e.g., a database or a blockchain) of the third node. The consensus may execute the executable file by inputting the set of transaction attributes into the executable along with identifiers of the first and / or second nodes.

[0054] At step 408, upon execution, the executable file may cause the third node or the consensus of nodes to retrieve data (e.g., a document, a machine-readable file, etc.) from the data source associated with the third node. The retrieved data may include financial data about the first, second, or third nodes, sets of rules that correspond to the nodes, workflow management data, etc. The ex- ecutable file may retrieve such data and evaluate the transaction attributes included in the transaction request against the data. The executable file may determine whether the transaction attributes satisfy the rules to determine whether to approve the transaction request.

[0055] For example, the data may include a series of rules. The series of rules may correspond to the first node. Examples of such rules may include automatically accepting any transaction requests from the first node, a requirement that a user at the third node review and manually approve transactions from the first node, only accepting transactions from the first node that have attributes that fall within specific ranges (e.g., transac- tions that have values between 1000 and 4000), only accepting transactions for which the first node has en- ough money on-hand to make the purchase, etc. Simi- 5 10 15 20 25 30 35 40 45 50 55 10 17 EP 4 675 968 A2 18 larly, the data may include a series of rules that corre- spond to the second and / or third node. For example, the third node and / or the second node may be associated with rules that only allow transactions with a value less than a threshold to be authorized. The second nodemay be associated with rules that only allow a predefined number of shares to be purchased at once. The third nodeand / or the secondnodemaybeassociatedwithany number of rules. The executable file may retrieve such rules and / or data about the first node and compare the two to determine whether to approve the transaction.

[0056] Each tier of nodes may be associated with different attributes of a transaction and rules associated with the particular attributes. For example, the sub-cus- todians may be associated with different transaction attributes than prime brokers and have rules that are associated with the specific attributes. Such attributes may be designated in a file stored on the system block- chain or in a system database such as in a hierarchy file. Upon initiating a transaction, the consensus of the plur- ality of nodes may identify transaction attributes of the transaction that correspond to each of the tiers of the hierarchy. The consensus may only provide the corre- sponding transaction attributes to the nodes of the re- spective tiers. In turn, the nodes may compare the cor- responding transaction attributes to a set of rules (e.g., input the transactionattributes into asmart contract of the blockchain) to determine if the transaction attributes satisfy their respective rules. Responsive to each tier of nodes determining the transaction attributes satisfies its respective set of rules, the consensusmay generate a signal indicating the transaction has been authorized. However, in some embodiments, responsive to a portion of the attributes not satisfying rules of any one of the tiers, the consensus may determine the transaction was not authorized and generate a rejection signal to send back to the peer node that initiated the transaction. Advanta- geously, by using the hierarchical account structure de- scribed herein to authorize transactions, each tier may only view the portions of the transaction that are relevant to the respective tier without gleaning a full view of the transaction, enabling the transaction to remain private between the transacting parties while ensuring the trans- action complieswith the rulesof eachparty that facilitates the transaction.

[0057] The executable file may be configured to allow the transaction to be authorized responsive to determin- ing a consensus of a set of peer nodes (e.g., a set of nodes within the plurality of nodes) has approved the transaction.Theset of peernodesmaybe identified in the rules or may be specified in the executable file. The consensus of the plurality of nodes may execute the executable file and poll the set of peer nodes asking whether the peer nodes approve of the transaction. The peer nodes may analyze the data associated with the transaction (e.g., any transaction attributes that cor- respond to the respective tier of the peer nodes) and, in some cases, any rules or data that the executable file has retrieved from the data source. In some embodiments, the peer nodes may retrieve such rules and / or data from the data source. Responsive to determining the transac- tion data satisfies the retrieved data and / or rules from the data source, the peer nodesmay send indications of their approval to the nodes executing the executable file. However, responsive to determining the transaction data does not satisfy the retrieved data and / or rules, the peer nodes may send indications of their disapproval.

[0058] Thepeernodesmaybe identifiedbasedon their place in the hierarchy. For example, the hierarchy of the hierarchy file may have multiple tiers indicating different nodes’ placement within the hierarchy. The executable may identify the set of nodes based on an indication to query the set of nodes that is within the top tier of the hierarchy. The executablemay identify the indication and identify the nodes that are associated with the top tier of the hierarchy. In turn, the executable may cause the consensus of the plurality of nodes executing the execu- table to poll the nodes that are associatedwith the top tier of the hierarchy asking if they approve of the transaction.

[0059] The executable file may determine whether a quorum of the polled set of nodes has provided their approval. The quorum may be a predetermined number or percentage of the polled nodes. The executable file may maintain a counter indicating the number of nodes that have responded with their approval of the transac- tions, incrementing the counter for each positive re- sponse. The executable file may compare the counter to thepredeterminednumber or percentage.Responsive to determining the count of the counter exceeds the predetermined number or percentage, the executable file may determine the transaction has been approved by the set of nodes. The executable file may cause the consensus to prompt the third node to indicate the ap- proval.

[0060] Responsive to determining the rules have been satisfied and / or a quorum of the set of nodes has trans- mitted an approval message to the consensus of the plurality of nodes, the executable file may cause the consensus to prompt the second node asking whether the second node approves or denies the transaction request. The executable may cause the consensus to send a prompt indicating the transaction attributes of the transaction, that the executable file has approved of the transaction, and / or the rules that were satisfied for the approval. The executable may generate the approval request and transmit thegenerated request to thesecond node.

[0061] The second node may receive the prompt from the executable or the consensus and determine whether to approve of the transaction request. The second node may do so according to its own set of rules (e.g., rules indicating whether the second node can sell to the first node, whether the number of shares falls within an al- lowed range,whether the purchase price is too high, etc.) or automatically upon receiving the prompt. The second node may determine whether to approve of the transac- 5 10 15 20 25 30 35 40 45 50 55 11 19 EP 4 675 968 A2 20 tion request and transmit a signal to the third node indicating its approval or disapproval.

[0062] Responsive to receiving the approval from the second node, the executable file may generate an in- dication of approval for the transaction. The indication of approval may include an indication of identifiers of the first node, second node, and / or third node, indications of the set of transaction attributes, and / or any other char- acteristics about the transaction. The executable filemay transmit or cause a signal to be transmitted to the con- sensus of the plurality of nodes indicating the generated indication of approval.

[0063] At step 410, in response to receiving an indica- tion of approval from the executable file, the consensus may append a third block instance comprising the set of transaction attributes to the blockchain. The approval may be an indication that the requirements of the execu- table file were satisfied, that a quorum of the peer nodes above the first and / or second nodes approved the trans- action, the second node approved the transaction, or any other indication that the transaction was approved. The consensus may receive the approval and append a blockchain to the blockchain that is maintained by the plurality of nodes. Advantageously, the consensus may do so without obtaining approval from a quorum of all of the plurality of nodes. Based on the data of the hierarchy file and / or the executable file, the consensus may ap- pend the block instance for the transaction to the block- chain-based only on the approval of one or a few of the nodes of the plurality of nodes. Thus, the systems and methods described herein allow for fewer computational resources to be used when approving transactions and appending blocks to a blockchain.

[0064] FIG. 5 visually depicts a non-limiting example of how the methods and systems described herein can be implemented. The sequence 500may include a plurality of nodes 502 that facilitate a transaction or a purchase of a financial instrument between a first node 504 and a secondnode506of the plurality of nodes502without any direct communication between the first node 504 and the second node 506. The first node 504 may transmit a message to a set of nodes 508 (e.g., a consensus of the plurality of nodes 502) of the plurality of nodes 502 indicating a potential transaction with the second node 506. The transaction request may include a set of trans- action attributes for the potential transaction such as the purchase price and / or the number of shares that are being purchased.

[0065] The set of nodes 508may identify a blockchain 509 that the set of nodes 508maintainswith the first node 504 and the second node 506. The blockchain 510 may initially comprise a plurality of block instances 512a-c. The block instance 512amay include a hierarchy file 514 and a hash 516 of the hierarchy file 514 and any other data being stored in the block instance 512a. The block instance 512b may include a smart contract 518 and a hash520of thesmart contract518,otherdataof theblock instance 512b, and / or the hash 516. The block instance 512c may include transaction data 522 for a transaction between nodes of the plurality of nodes 502 and a hash 524 of the transaction data 522, the hash 520, and any other data stored within the block instance 512c.

[0066] The set of nodes 508 may receive the transac- tion request from the first node 504 and identify the hierarchy file 514 from the blockchain 510.The hierarchy file 514 may include a hierarchy 526 of the nodes of the plurality of nodes 502 indicating the permissions each node has and / or the rules for appending block instances to the blockchain 510. The hierarchy 526 may include a first tier 528 and a second tier 530. The first tier 528may include nodes 532a-c for which a quorum must approve of transactions that are initiated by nodes 534a-b of the second tier530.Nodes532a-cand / or nodes534a-bmay be nodes of the plurality of nodes 502. For example, according to the hierarchy 526, if the node 534a attempts to purchase a financial instrument from another node, a quorum of the nodes 532a-c must approve of the trans- action for the transaction to be approved. The first node 504 and / or the second node 506may be associated with or be in the first tier 528 or the second tier 530.

[0067] In some embodiments, for the quorum of the nodes 532a-c to approve of the transaction, the set of nodes 508 or the nodes 532a-c may execute the smart contract 518. By executing the smart contract, the set of nodes 508 or the nodes 532a-cmay retrieve data from a datasource536.Thedatasource536maybemaintained or stored by the set of nodes 508 or one or more of the nodes 532a-c. The data may include a set of rules indicating which transactions to allow (e.g., which trans- action attributes are allowable orwhich nodes can initiate transactions), account information about the first node 504, account information about the second node 506, etc. The nodes 532a-c may compare the transaction attributes of the potential transaction between the first node 504 and the second node 506 and the retrieved data.

[0068] Upon a quorum of the nodes 532a-c determin- ing the transaction should be allowed (e.g., based on the set of rules), the set of nodes 508 may prompt the first node 504 and / or the second node 506 to indicate the transaction has been allowed and append a block in- stance536 to the blockchain510.Theblock instance538 may contain transaction data 540 and / or a hash 542 of the transaction data 540, other data of the block instance 538, and the hash 542 of the previous block instance 512c. Thus, the hierarchical structure of the nodes that maintain the blockchain 510 may enable nodes to ap- pend block instances to the blockchain 510 based on the hierarchy instead of requiring a quorum of all nodes that maintain the blockchain 510, enabling block instances to be appended using different sets of rules and permis- sions instead of just based on an agreement between the plurality of nodes 502.

[0069] While the systems and methods described herein have been integrated into a blockchain system, the hierarchy model may also be implemented without a 5 10 15 20 25 30 35 40 45 50 55 12 21 EP 4 675 968 A2 22 blockchain. For example, a processor may store a hier- archy file within memory that indicates the different tiers of different nodes of the hierarchy. Upon receiving a transaction request, the processor can distribute the transaction attributes of the transaction request to the nodes according to the hierarchy and the nodes may determine whether the respective attributes are accep- table or otherwise comply with a set of rules established by the set of nodes. Responsive to each of the nodes determining the transaction attributes satisfy its respec- tive rules, the processor may authorize the transaction. However, responsive to one of the nodes or one of the tiersof nodesdetermining the respectiveattributesdonot satisfy its respective rules, the processormay not author- ize the transaction. Thus the systems and methods pro- vide for a new method of authorizing transactions be- tween entities using a hierarchical data structure.

[0070] In an example, a plurality of nodes may each maintain a database that stores files including various rules that correspond to different transaction attributes. Thedifferent nodesmayeachbe associatedwith specific transactionattributes.Acentral servermaymaintainafile that includes a hierarchy indicating the transaction attri- buteswithwhich thedifferentnodesareassociated.Each tier of the hierarchymaybeassociatedwith a different set of transaction attributes. When a node initiates a trans- action, the server may send the transaction attributes for the transaction to the corresponding nodes. The nodes may compare the received transaction attributes to their stored rules. Responsive to each of the nodes approving or determining the received transaction attributes comply with the node’s respective rules, the server may allow for the transaction to go through. However, responsive to one of the nodes determining the transaction attributes do not satisfy the respective node’s rules, the node may transmit a signal to the central server and the central server may decline the transaction. In yet another exam- ple, for a transaction request, the central server may receive rules from the different nodes and apply the rules to the transaction attributes of the transaction request that correspond to each respective node. Responsive to determining the applied rules are satisfied, the server may enable the transaction. However, responsive to determining at least one of the rules is not satisfied, the central server may stop the transaction.

[0071] The foregoingmethod descriptions and the pro- cess flow diagrams are provided merely as illustrative examplesandarenot intended to require or imply that the steps of the various embodiments must be performed in the order presented. The steps in the foregoing embodi- ments may be performed in any order. Words such as "then," "next," etc. are not intended to limit the order of the steps; these words are simply used to guide the reader through thedescriptionof themethods.Althoughprocess flow diagramsmay describe the operations as a sequen- tial process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process may corre- spond to amethod, a function, a procedure, a subroutine, a subprogram,and the like.Whenaprocess corresponds to a function, the process termination may correspond to a return of the function to a calling function or a main function.

[0072] The various illustrative logical blocks, modules, circuits, and algorithmsteps described in connectionwith the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combina- tions of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks,modules, circuits, andstepshavebeendescribed above generally in terms of their functionality. Whether such functionality is implemented as hardware or soft- ware depends upon the particular application and design constraints imposed on the overall system. Skilled arti- sans may implement the described functionality in vary- ing ways for each particular application, but such imple- mentationdecisions should not be interpretedas causing a departure from the scope of the present invention.

[0073] Embodiments implemented in computer soft- ware may be implemented in software, firmware, mid- dleware, microcode, hardware description languages, or any combination thereof. A code segment or machine- executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subrou- tine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means includingmemory sharing, message passing, token passing, network transmission, etc.

[0074] The actual software code or specialized control hardwareused to implement thesesystemsandmethods is not limiting of the invention. Thus, the operation and behavior of the systems and methods were described without reference to the specific software code being understood that software and control hardware can be designed to implement the systems and methods based on the description herein.

[0075] When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-read- able storagemedium. The steps of amethod or algorithm disclosed herein may be embodied in a processor-ex- ecutable software module, which may reside on a com- puter-readable or processor-readable storage medium. A non-transitory computer-readable or processor-read- able media includes both computer storage media and tangible storage media that facilitate transfer of a com- puter program from one place to another. A non-transi- tory processor-readable storagemediamaybeanyavail- able media that may be accessed by a computer. By way of example, and not limitation, such non-transitory pro- cessor-readable media may comprise RAM, ROM, EE- 5 10 15 20 25 30 35 40 45 50 55 13 23 EP 4 675 968 A2 24 PROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storagemedium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer or processor. Disk and disc, as used herein, include com- pact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs repro- duce data optically with lasers. Combinations of the above should also be included within the scope of com- puter-readable media. Additionally, the operations of a method or algorithm may reside as one or any combina- tion or set of codesand / or instructionsonanon-transitory processor-readable medium and / or computer-readable medium, which may be incorporated into a computer program product. Examples according to the following clauses are also disclosed: 1. A system comprising: a plurality of nodes each corresponding to a comput- ing device having a processor and memory to store data, wherein each processor is configured to: receive a transaction request from a first node within the plurality of nodes, the transaction request corresponding to a pending transaction between the first node and a second nodewithin the plurality of nodes via a third node within the plurality of nodes, the transaction request com- prising a set of transaction attributes, wherein the first node is not in direct communication with the second node; identify a blockchain associated with the pend- ing transaction, the blockchain including a first block instance having a hierarchy file indicating a hierarchy among the first node, the second node, and the third node; in response to the hierarchy file indicating that transaction requests from the first nodemust be approved by the third node, identify a second block instance having an executable file to ap- prove the transaction request received from the first node; execute the executable file, wherein the execu- table file is configured to retrieve data from a data source associated with the third node and analyze data associated with at least one of the first node, the secondnode, thirdnode, or theset of transaction attributes to approve or deny the transaction request; and in response to receiving an indication of ap- proval from the executable file, append a third block instance comprising the set of transaction attributes to the blockchain. 2. The systemof clause1,wherein eachprocessor is further configured to: prompt the second node in response to receiving the transaction request. 3. The systemof clause1,wherein eachprocessor is further configured to: transmit the transaction request to a server in re- sponse to receiving the indication of approval from the executable file or the second node. 4. The system of clause 1, wherein the executable file causes a consensus of the plurality of nodes to poll a predetermined subset of nodes within the plurality of nodes. 5. The system of clause 4, wherein the predeter- mined subset of nodes are at a higher level of hier- archy than the first node. 6. The system of clause 5, wherein the predeter- mined subset of nodes are peer nodes to the first node having a same level of hierarchy. 7. The system of clause 1, wherein the executable file is configured to prompt the second node to re- ceive an approval or denial of the transaction re- quest. 8. The systemof clause1,wherein eachprocessor is further configured to: prompt the third node in response to receiving ap- proval. 9. The systemof clause 1,wherein the data source is a first blockchain. 10. The system of clause 1, wherein the retrieved data from the data source comprises one or more rules indicating whether to authorize the pending transaction. 11. A method comprising: receiving, by a consensusof a plurality of nodes, a transaction request from a first node within the plurality of nodes, the transaction request cor- responding to a pending transaction between the first node and a second node within the plurality of nodes via a third node within the plurality of nodes, the transaction request com- prising a set of transaction attributes, wherein the first node is not in direct communication with the second node; identifying, by the consensus of the plurality of nodes, a blockchain associated with the pend- ing transaction, the blockchain including a first block instance having a hierarchy file indicating a hierarchy among the first node, the second node, and the third node; in response to the hierarchy file indicating that transaction requests from the first nodemust be approved by the third node, identifying, by the consensus of the plurality of nodes, a second block instance having an executable file to ap- prove the transaction request received from the first node; executing, by the consensus of the plurality of 5 10 15 20 25 30 35 40 45 50 55 14 25 EP 4 675 968 A2 26 nodes, the executable file, wherein the execu- table file is configured to retrieve data from a data source associated with the third node and analyze data associated with at least one of the first node, the secondnode, thirdnode, or theset of transaction attributes to approve or deny the transaction request; and in response to receiving an indication of ap- proval from the executable file, appending, by consensus of the plurality of nodes, a third block instance comprising the set of transaction attri- butes to the blockchain. 12. The method of clause 11, further comprising: prompting, by the consensus of the plurality of nodes, the second node in response to receiving the transaction request. 13. The method of clause 11, further comprising: transmitting, by the consensus of the plurality of nodes, the transaction request to a server in re- sponse to receiving the indication of approval from the executable file or the second node. 14. Themethodof clause 11,wherein theexecutable file causes the consensus to poll a predetermined subset of nodes within the plurality of nodes. 15. The method of clause 14, wherein the predeter- mined subset of nodes are at a higher level of hier- archy than the first node. 16. The method of clause 15, wherein the predeter- mined subset of nodes are peer nodes to the first node having a same level of hierarchy. 17. Themethodof clause 11,wherein theexecutable file is configured to prompt the second node to re- ceive an approval or denial of the transaction re- quest. 18. The method of clause 11, further comprising: prompting, by the consensus of the plurality of nodes, the third node in response receiving ap- proval. 19. The method of clause 11, wherein the data source is a first blockchain. 20. The method of clause 11, wherein the retrieved data from the data source comprises one or more rules indicating whether to authorize the pending transaction.

[0076] The preceding description of the disclosed em- bodiments is provided to enable any person skilled in the art to make or use the present invention. Various mod- ifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, thepresent invention is not intended tobe limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

[0077] While various aspects and embodiments have been disclosed, other aspects and embodiments are contemplated. The various aspects and embodiments disclosed are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims. Claims 1. A system (100) comprising: a plurality of nodes each corresponding to a comput- ing device having a processor and memory to store data, wherein one ormore processors of the plurality of nodes are configured to: receive a transaction request from a first node within the plurality of nodes, the transaction request corresponding to a pending transaction between the first node and a second nodewithin the plurality of nodes via a third node within the plurality of nodes; identify a hierarchy file indicating a hierarchy among the first node, the second node, and the third node; in response to the hierarchy file indicating that the transaction request from the first node must be approved by the third node, identify a first recordof adistributed ledger associatedwith the pending transaction based on an identifier of the third node in the first record, the first record having an executable file to approve the trans- action request received from the first node; execute the executable file, wherein the execu- table file is configured to retrieve data from a data source associated with the third node and analyze data associated with at least one of the first node, the second node, or the third node to approve or deny the transaction request; and in response to receiving an indication of ap- proval from theexecutable file, appendasecond record for the transaction to the distributed led- ger. 2. The system of claim 1, wherein each processor is further configured to: prompt the second node in response to receiving the transaction request. 3. The system of claim 1, wherein each processor is further configured to: transmit the transaction request to a server in re- sponse to receiving the indication of approval from the executable file or the second node. 4. The system of claim 1, wherein the executable file causes a consensus of the plurality of nodes to poll a predetermined subset of nodes within the plurality of nodes. 5 10 15 20 25 30 35 40 45 50 55 15 27 EP 4 675 968 A2 28 5. The system of claim 4, wherein the predetermined subset of nodesareat ahigher level of hierarchy than the first node. 6. The system of claim 5, wherein the predetermined subset of nodes are peer nodes to the first node having a same level of hierarchy. 7. The system of claim 1, wherein the executable file is configured to prompt the second node to receive an approval or denial of the transaction request. 8. The system of claim 1, wherein each processor is further configured to: prompt the third node in response to receiving ap- proval. 9. The system of claim 1, wherein the data source is a first distributed ledger. 10. The system of claim 1, wherein the retrieved data from the data source comprises one or more rules indicating whether to authorize the pending transac- tion. 11. A method comprising: receiving, by a consensusof a plurality of nodes, a transaction request from a first node within the plurality of nodes, the transaction request cor- responding to a pending transaction between the first node and a second node within the plurality of nodes via a third node within the plurality of nodes; identifying, by the consensus of the plurality of nodes, a hierarchy file indicating a hierarchy among the first node, the second node, and the third node; in response to the hierarchy file indicating that the transaction request from the first node must beapprovedby the third node, identifying, by the consensus of the plurality of nodes, a first record of a distributed ledger associated with the pend- ing transaction based on an identifier of the third node in the first record, the first record having an executable file to approve the transaction re- quest received from the first node; executing, by the consensus of the plurality of nodes, the executable file, wherein the execu- table file is configured to retrieve data from a data source associated with the third node and analyze data associated with at least one of the first node, the second node, or the third node to approve or deny the transaction request; and in response to receiving an indication of ap- proval from the executable file, appending, by theconsensusof theplurality of nodes, asecond record for the transaction to the distributed led- ger. 12. The method of claim 11, further comprising: prompting, by the consensus of the plurality of nodes, the second node in response to receiving the transaction request. 13. The method of claim 11, further comprising: transmitting, by the consensus of the plurality of nodes, the transaction request to a server in re- sponse to receiving the indication of approval from the executable file or the second node. 14. The method of claim 11, wherein the executable file causes the consensus to poll a predetermined sub- set of nodes within the plurality of nodes. 15. The method of claim 14, wherein the predetermined subset of nodesareat ahigher level of hierarchy than the first node. 5 10 15 20 25 30 35 40 45 50 55 16 EP 4 675 968 A2 17 EP 4 675 968 A2 18 EP 4 675 968 A2 19 EP 4 675 968 A2 20 EP 4 675 968 A2 21 EP 4 675 968 A2 REFERENCES CITED IN THE DESCRIPTION This list of references cited by the applicant is for the reader’s convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard. Patent documents cited in the description • US 09662020

[0001] 摘要 一种计算机实现的方法， 包括： 从多个节点中的第一节点接收交易请求， 该 交易请求对应于第一节点与第二节点之间的待处理交易；识别与该待处理交易 相关的区块链， 该区块链包括一个第一区块实例， 该实例具有一个层次结构 文件， 该文件指示第一节点、 第二节点和第三节点之间的层次关系； 识别一 个第二区块实例， 该实例具有一个可执行文件， 用于批准从第一节点接收的 交易请求； 执行该可执行文件， 其中该可执行文件被配置为从与第三节点关 联的数据源中检索数据， 并分析数据以批准或拒绝该交易请求； 以及将包含 该交易属性集的第三区块实例追加到区块链中。

Claims

1. A system (100) comprising: a plurality of nodes each corresponding to a computing device having a processor and memory to store data, wherein one or more processors of the plurality of nodes are configured to: receive a transaction request from a first node within the plurality of nodes, the transaction request corresponding to a pending transaction between the first node and a second node within the plurality of nodes via a third node within the plurality of nodes; identify a hierarchy file indicating a hierarchy among the first node, the second node, and the third node; in response to the hierarchy file indicating that the transaction request from the first node must be approved by the third node, identify a first record of a distributed ledger associated with the pending transaction based on an identifier of the third node in the first record, the first record having an executable file to approve the transaction request received from the first node; execute the executable file, wherein the executable file is configured to retrieve data from a data source associated with the third node and analyze data associated with at least one of the first node, the second node, or the third node to approve or deny the transaction request; and in response to receiving an indication of approval from the executable file, append a second record for the transaction to the distributed ledger.

2. The system of claim 1, wherein each processor is further configured to: prompt the second node in response to receiving the transaction request.

3. The system of claim 1, wherein each processor is further configured to: transmit the transaction request to a server in response to receiving the indication of approval from the executable file or the second node.

4. The system of claim 1, wherein the executable file causes a consensus of the plurality of nodes to poll a predetermined subset of nodes within the plurality of nodes.

5. The system of claim 4, wherein the predetermined subset of nodes are at a higher level of hierarchy than the first node.

6. The system of claim 5, wherein the predetermined subset of nodes are peer nodes to the first node having a same level of hierarchy.

7. The system of claim 1, wherein the executable file is configured to prompt the second node to receive an approval or denial of the transaction request.

8. The system of claim 1, wherein each processor is further configured to: prompt the third node in response to receiving approval.

9. The system of claim 1, wherein the data source is a first distributed ledger.

10. The system of claim 1, wherein the retrieved data from the data source comprises one or more rules indicating whether to authorize the pending transaction.

11. A method comprising: receiving, by a consensus of a plurality of nodes, a transaction request from a first node within the plurality of nodes, the transaction request corresponding to a pending transaction between the first node and a second node within the plurality of nodes via a third node within the plurality of nodes; identifying, by the consensus of the plurality of nodes, a hierarchy file indicating a hierarchy among the first node, the second node, and the third node; in response to the hierarchy file indicating that the transaction request from the first node must be approved by the third node, identifying, by the consensus of the plurality of nodes, a first record of a distributed ledger associated with the pending transaction based on an identifier of the third node in the first record, the first record having an executable file to approve the transaction request received from the first node; executing, by the consensus of the plurality of nodes, the executable file, wherein the executable file is configured to retrieve data from a data source associated with the third node and analyze data associated with at least one of the first node, the second node, or the third node to approve or deny the transaction request; and in response to receiving an indication of approval from the executable file, appending, by the consensus of the plurality of nodes, a second record for the transaction to the distributed ledger.

12. The method of claim 11, further comprising: prompting, by the consensus of the plurality of nodes, the second node in response to receiving the transaction request.

13. The method of claim 11, further comprising: transmitting, by the consensus of the plurality of nodes, the transaction request to a server in response to receiving the indication of approval from the executable file or the second node.

14. The method of claim 11, wherein the executable file causes the consensus to poll a predetermined subset of nodes within the plurality of nodes.

15. The method of claim 14, wherein the predetermined subset of nodes are at a higher level of hierarchy than the first node.

Images