Hierarchy-based blockchain

Patent metadata

Field	Value
Publication number	US-11676144-B2
Application number	US-202017096620-A
Country	US
Kind code	B2
Filing date	Nov 12, 2020
Priority date	Nov 12, 2020
Publication date	Jun 13, 2023
Grant date	Jun 13, 2023

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.

First claim

What is claimed is:

1. A system comprising:
a plurality 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 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 transaction attributes, wherein the first node is not in direct communication with the second node;
identify 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;
in response to the hierarchy file indicating that transaction requests from the first node must be approved by the third node, identify a second block instance based on the second block instance comprising an identifier of the third node, the 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 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, third node, or the set of transaction attributes to approve or deny the transaction request; and
in response to receiving an indication of approval from the executable file, append a third block instance comprising the set of transaction attributes to the blockchain.

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 blockchain.

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, the transaction request comprising 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 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;
in response to the hierarchy 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 based on the second block instance comprising an identifier of the third node, the second block instance 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, third node, or the set of transaction attributes to approve or deny the transaction request; and
in response to receiving an indication of approval from the executable file, appending, by consensus of the plurality of nodes, a third block instance comprising the set of transaction attributes to the blockchain.

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.

16. The method of claim 15 , wherein the predetermined subset of nodes are peer nodes to the first node having a same level of hierarchy.

17. The method of claim 11 , wherein the executable file is configured to prompt the second node to receive an approval or denial of the transaction request.

18. The method of claim 11 , further comprising:
prompting, by the consensus of the plurality of nodes, the third node in response receiving approval.

19. The method of claim 11 , wherein the data source is a first blockchain.

20. The method of claim 11 , wherein the retrieved data from the data source comprises one or more rules indicating whether to authorize the pending transaction.

Assignees

• Citibank Na

Inventors

• Marsh Ryan

Classifications

• H04L9/0618

  Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation · CPC title

• H04L2209/56

  Financial cryptography, e.g. electronic payment or e-cash · CPC title

• G06Q20/40 Primary

  Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists · CPC title

• G06Q2220/00

  Business processing using cryptography · CPC title

• H04L9/3239

  involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD · CPC title