DETAILED ACTION
Status of Application
This action is a Final Rejection. This action is in response to the amendment and response filed on April 13, 2026.
Claims 1, 4, 5, 8, 11, 12, and 15 have been amended.
Claims 1-20 are pending and rejected.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Arguments
Regarding the rejection under 35 U.S.C. 101, Applicant argues that amended claim 1 “recites, technology-specific improvements that extend beyond an abstract concept of payment authorization. In particular, the claim now requires a node vulnerability tracker configured to (i) continuously monitor changes in computing bandwidth levels of a selected final-approver node, and (ii) upon detecting diminishing computing bandwidth levels, using the approver segregator to identify a new final-approver node having been assigned computer resource consumption metric reflecting that previous transactions processed by the new final approver node consumed less than a threshold number of computing resources. Accordingly, the amended claims recite significantly more than an abstract concept. They present a specific, technological solution to a technological problem namely the dynamic detection and management of resource consumption within decentralized processing networks, resulting in improved reliability and operational resilience.” Remarks at 12.
Applicant’s Specification, including the following paragraphs, were reviewed in light of the claim amendments:
[0028] In some embodiments, methods may include tracking the final-approver node. The final-approver node may be tracked using a node vulnerability tracker. The node vulnerability tracker may be a node included in the MCP network configured to track other nodes. Tracking nodes may include monitoring performance metrics, computing bandwidth levels, trustworthiness levels, IP addresses and/or any other suitable metric of a selected node. Tracking the final-node approver may include monitoring any changes to an IP address assigned to/associated with the final-approver node. Tracking the final-approver node may include monitoring any changes of an assigned level of trust between the final-approver node and other nodes included in the MCP network. Tracking the final-approver node may include monitoring any changes in computing bandwidth levels associated with the final-approver node. Tracking the final-approver node may include monitoring any change in computing metrics of the final-approver node.
[0029] Based on the monitoring, the methods may include determining whether the IP address of the final-approver node has changed, whether the level of trust between the final-approver node and other nodes has diminished, whether the computing bandwidth levels have diminished and/or any other suitable computing metric has changed. In response to determining that a change in the IP address of the final-approver node, a diminishing of the level of trust between the final-approver node and other nodes, a diminishing in the computing bandwidth levels, and/or any changes in other suitable computing metric, the methods may include transmitting a command to the knowledge graph to select a new final-approver node from the group of nodes. The new final-approver node may be a node that is different from the previously selected final approver node.
[0093] At step 414, an approver list may be generated using the group of nodes identified by transaction-relation knowledge graph at step 412. At step 416, an approver segregator may assign an approver score to each of the nodes included in the approver list. The approver score may be assigned based on node transaction history, node trustworthiness, computing bandwidth, computing speed and any other suitable approval parameters. At step 426, the approver list may be updated with the assigned approval scores. At step 428, a final-approver node may be selected. The final approver-node may be selected based on the assigned approver score.
Although the claims recite that the node vulnerability tracker monitors computing bandwidth levels of the final-approver node to detect diminishing bandwidth levels, this is being done in order to select a new final-approver node that presumably is the node that generates the NFT for approving the pending crypto transaction. The Specification does not provide a detailed description of these features other than what is recited in the claims. Selecting a new final-approver node that is going to be used to generate an NFT for approving a transaction is part of the abstract idea and not a technological improvement.
Additionally, claim 1, for example, was amended to state that the unified payment gateway comprises a node vulnerability tracker that is configured to “monitor,” “identify,” and “select.” However, these are not positively recited steps of the claimed method. Moreover, the claim states that the final-approver node is used to generate an NFT for approving the transaction. Therefore, it appears that the final-approver node and not the new final-approver node is used in the claimed method.
As such, the rejection is maintained.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03)
Yes, with respect to claims 1-7 and 15-20, which recite a method and, therefore, are directed to the statutory class of process.
Yes, with respect to claims 8-14, which recite a “unified payment gateway” which comprises “a node.” Paragraph 0010 of the Specification states “the one or more nodes may be computing devices, peripheral devices and/or any other suitable network devices.” Paragraph 0041 states “[a] node may include a computing device, a peripheral device, and/or any other suitable network related devices.” These statements are being used to interpret the claimed node as a hardware device. Therefore, these claims fall within a statutory category.
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a))
The following claims identify the limitations that recite the abstract idea in regular text and that recite additional elements in bold:
1. A method for resource efficient and decentralized verification, approval and storage of pending crypto transactions, the method leveraging smart contracts, non-fungible tokens and knowledge graphs, the method including:
receiving at a unified payment gateway a transaction data packet from a crypto payment platform, the unified payment gateway being part of a multidimensional crypto payment (“MCP”) network, the MCP network being a decentralized network having one or more nodes, wherein the transaction data packet includes:
a pending crypto transaction between a sender node and a receiver node;
sender node identification; and
receiver node identification;
transmitting, from the unified payment gateway, the transaction data packet to a knowledge graph including:
identification data of the one or more nodes; and
transaction data relating to previous transactions between the one or more nodes;
identifying, in the knowledge graph, a group of nodes from the one or more nodes, each of the group of nodes having previously completed at least one transaction with the sender node and at least one transaction with the receiver node;
assigning an approver score to each node included in the group of nodes by determining, for each node:
previous transaction history with the receiver node;
previous transaction history with the sender node; and
trustworthiness based on previous transaction history;
selecting a final-approver node from the group of nodes, the final-approver node being a node having a highest assigned approval score;
using the final-approver node to generate a non-fungible token (“NFT”) for approving the pending crypto transaction;
in parallel with the generating of the NFT, transmitting final-approver node identification to a node consensus validator, the node consensus validator configured to validate the final-approver node;
creating, using the node consensus validator, a smart contract, the smart contract including the sender node identification, the receiver node identification, the final-approver node identification, the NFT, and a set of rules to validate the smart contract;
validating the smart contract using one of the one or more nodes in the MCP network, the validating including solving the set of rules;
in response to validating the smart contract;
approving the pending crypto transaction; and
storing the crypto transaction in the MCP network; and
exchanging crypto payment-related resources between the receiver node and the sender node as specified by the crypto transaction;
wherein the unified payment gateway further comprises a node vulnerability tracker configured to:
monitor computing bandwidth levels of the final-approver node; and
in response to detecting the computing bandwidth levels of the final-approver node diminishing, identify and select, using an approver segregator, a new final-approver node, the new final-approver node being assigned a computer resource consumption metric reflecting that previous transactions processed by the new final-approver node consumed less than a threshold number of computing resources.
2. The method of claim 1 further including homomorphically encrypting the transaction data packet prior to receiving the transaction data packet.
3. The method of claim 2 further including homomorphically encrypting data relating to the pending crypto transaction and not homomorphically encrypting data relating to sender node identification and receiver node identification.
4. The method of claim 1 wherein the node using a node vulnerability tracker is further configured to track the final-approver node, the tracking comprising:
monitoring if an internet protocol (“IP”) address of the final-approver node has changed;
based on the monitoring determining that the IP address of the final-approver node has changed; and
based on the determining, transmitting a command to the knowledge graph to select a second new final-approver node from the group of nodes.
5. The method of claim 1 wherein the node vulnerability tracker is further configured to track the final-approver node, the tracking comprising:
monitoring if a level of trust between the final-approver node and other nodes included in the MCP network is diminished;
based on the monitoring determining that the level of trust between the final-approver node and other nodes is diminished; and
based on the determining, transmitting a command to the knowledge graph to select a second new final-approver node from the group of nodes.
6. The method of claim 1 further comprising dynamically updating the knowledge graph in response to a node being added to the MCP network, the updating comprising updating the knowledge graph with:
identification data of the node being added; and
transaction data relating to previous and ongoing transactions between the node being added and the one or more nodes included in the MCP network.
7. The method of claim 6 wherein the updating is executed in real-time.
8. A unified payment gateway for resource efficient and decentralized verification, approval and storage of pending crypto transactions, the unified payment gateway leveraging smart contracts, non-fungible tokens and knowledge graphs, the unified payment gateway being included in a multidimensional crypto payment (“MCP”) network, the MCP network being a decentralized network having one or more nodes, the unified payment gateway comprising:
a node, the node comprising:
a receiver configured to receive a transaction data packet from a crypto payment platform, the transaction data packet including:
a pending crypto transaction between a sender node and a receiver node, the sender and receiver node included in the MCP network;
sender node identification; and
receiver node identification;
a transmitter configured to transmit the transaction data packet from the unified payment gateway to a knowledge graph, the knowledge graph comprising:
identification data of the one or more nodes; and
transaction data relating to previous transactions between the one or more nodes;
an approver segregator configured to:
identify, in the knowledge graph, a group of nodes from the one or more nodes, each of the group of nodes having previously completed at least one transaction with the sender node and at least one transaction with the receiver node;
assign an approver score to each node included in the group of nodes by determining, for each node:
previous transaction history with the receiver node:
previous transaction history with the sender node; and
trustworthiness based on previous transaction history;
select a final-approver node from the group of nodes, the final-approver node being a node having a highest assigned approval score;
a non-fungible token (“NFT”) generator configured to use the final-approver node to generate an NFT to use for approval of the pending crypto transaction; and
a node consensus validator configured to validate the final-approver node, the node consensus validator configured to:
create a smart contract, the smart contract including the sender node identification, the receiver node identification, final-approver node identification, the NFT, and a set of rules to validate the smart contract; and
validate the smart contract, the validation including solving the set of rules; and
in response to validating the smart contract, the unified payment gateway is configured to:
approve the pending crypto transaction; and
store the crypto transaction in the MCP network;
wherein in response to storing the crypto transaction, the unified payment gateway is configured to enable an exchange of crypto payment-related resources between the receiver node and the sender node as specified by the crypto transaction;
wherein the unified payment gateway further comprises a node vulnerability tracker configured to:
monitor computing bandwidth levels of the final-approver node; and
in response to detecting the computing bandwidth levels of the final-approver node diminishing, identify and select, using the approver segregator, a new final-approver node, the new final-approver node being assigned a computer resource consumption metric reflecting that previous transactions processed by the new final approver node consumed less than a threshold number of computing resources.
9. The unified payment gateway of claim 8 wherein the transaction data packet is configured to be homomorphically encrypted prior to transmission of the transaction data packet.
10. The unified payment gateway of claim 9 wherein data relating to the pending crypto transaction is configured to be homomorphically encrypted and data relating to sender node identification and receiver node identification is not configured to be homomorphically encrypted.
11. The unified payment gateway of claim 8 wherein the node vulnerability tracker is further configured to:
monitor if an internet protocol (“IP”) address of the final-approver node has changed;
based on the monitoring, determine that the IP address of the final-approver node has changed; and
based on the determining, transmit a command to the approver segregator to select a second new final-approver node from the group of nodes.
12. The unified payment gateway of claim 8 wherein, the node vulnerability tracker is further configured to:
monitor if a level of trust between the final-approver node and other nodes included in the MCP network is diminished; and
based on the monitoring, determine that the level of trust between the final-approver node and other nodes included in the MCP network has diminished; and
based on the determining, transmit a command to the approver segregator to select a second new final-approver node from the group of nodes.
13. The unified payment gateway of claim 8 further configured to dynamically update the knowledge graph in response to a node being added to the MCP network, the unified payment gateway is configured to update the knowledge graph with:
identification data of the node being added; and
transaction data relating to previous and ongoing transactions between the node being added and the one or more nodes included in the MCP network.
14. The unified payment gateway of claim 13 wherein the update is configured to be executed in real-time.
15. A method for resource efficient and decentralized verification, approval and storage of pending crypto transactions, the method leveraging smart contracts, non-fungible tokens and knowledge graphs, the method including:
receiving at a unified payment gateway a transaction data packet from a crypto payment platform, the unified payment gateway being part of a first network, the first network being a decentralized network having first network nodes, wherein the transaction data packet includes:
a pending crypto transaction between a sender node and a receiver node;
sender node identification; and
receiver node identification;
transmitting, from the unified payment gateway, the transaction data packet to a knowledge graph including:
identification data of the first network nodes;
identification data of second network nodes, the second network nodes included in a second network, the second network different from the first network; and
transaction data relating to previous transactions between the first and second network nodes;
identifying, in the knowledge graph, a group of nodes from first network nodes and second network nodes, each node included in the group of nodes having previously completed at least one transaction with the sender node and at least one transaction with the receiver node;
assigning an approver score to each node included in the group of nodes by determining, for each node:
previous relationship history with the receiver node;
previous relationship history with the sender node; and
trustworthiness based on previous transaction history;
selecting a final-approver node from the group of nodes, the final-approver node being a node having a highest assigned approval score;
using the final-approver node to generate a non-fungible token (“NFT”) for approving the pending crypto transaction;
in parallel with the generating of the NFT, transmitting final-approver node identification to a node consensus validator, the node consensus validator configured to validate the final-approver node;
creating, using the node consensus validator, a smart contract, the smart contract including the sender node identification, the receiver node identification, the final-approver node identification, the NFT, and a set of rules to validate the smart contract;
validating the smart contract using a node selected from the first network nodes and the second network nodes, the validating including solving the set of rules;
in response to validating the smart contract;
approving the crypto transaction; and
storing the crypto transaction in the first network; and
exchanging crypto payment-related resources between the receiver node and the sender node as specified by the crypto transaction;
wherein the unified payment gateway further comprises a node vulnerability tracker configured to:
monitor computing bandwidth levels of the final-approver node; and
in response to detecting the computing bandwidth levels of the final-approver node diminishing, identify and select, using an approver segregator, a new final-approver node, the new final-approver node being assigned a computer resource consumption metric reflecting that previous transactions processed by the new final approver node consumed less than a threshold number of computing resources.
16. The method of claim 15 wherein the final-approver node is selected from the first network nodes.
17. The method of claim 15 wherein the final-approver node is selected from the second network nodes.
18. The method of claim 15 wherein the node selected for validating the smart contract is selected from the first network nodes.
19. The method of claim 15 wherein the node selected for validating the smart contract is selected from the second network nodes.
20. The method of claim 15 further comprising dynamically updating the knowledge graph in response to a node being added to either the first network or the second network, the updating comprising updating the knowledge graph with:
identification data of the node being added; and
transaction data relating to previous and ongoing transactions between the node being added and first and second network nodes .
Yes. But for the recited additional elements as shown above in bold, the remaining limitations of the claims recite certain methods of organizing human activity. The claims are directed to verifying/approving and implementing a crypto transaction. This type of method of organizing human activity is a fundamental economic practice because it includes a payment and mitigating risk and it is a commercial interaction such as agreements in the form of contracts, legal obligations, sales activities or behaviors, and business relations. Thus, the claims recite an abstract idea.
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d))
No. The claims as a whole merely use a computer as a tool to perform the abstract idea. The computing related components (i.e., additional elements that are in bold above) are recited at a high level of generality and are merely invoked as a tool to implement the steps. For example, only programmed general purpose computing devices are needed to implement the claimed invention. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Moreover, the abstract idea is merely being linked to a particular technological environment, i.e., blockchain. Employing well known technology with a blockchain environment to execute the abstract idea, even when limiting the use of the abstract idea to this environment, does not integrate the exception into a practical application or add significantly more. Additionally, there is no improvement to the functioning of a computer or technology. Therefore, the abstract idea is not integrated into a practical application.
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05)
No. As discussed with respect to Step 2A, Prong 2, the additional elements in the claims, both individually and in combination, amount to no more than tools to perform the abstract idea. Merely performing the abstract idea using a computer cannot provide an inventive concept. Therefore, the claims do not provide an inventive concept.
As such, the claims are not patent eligible.
Relevant Prior Art
The following references are relevant to Applicant’s invention:
Ramakrishnan et al., U.S. Patent Application Publication Number 2023/0237496 A1. This reference teaches a risk determination enabled crypto currency transaction system.
Gaur et al., U.S. Patent Application Publication Number 2021/0350343 A1. This reference teaches a blockchain compliance verification network. Information regarding a transfer of value is captured from a message and evaluated to determine whether the value transfer complies with regulations.
O’Brien, U.S. Patent Application Publication Number 2019/0122300 A1. This reference teaches providing proof of trust related to smart contracts.
Ramaswamy et al., U.S. Patent Application Publication Number 2023/0237482 A1. This reference teaches an invention for determining trust values in a blockchain. A transaction rating value and a transaction confirmation value are used to adjust a trust rating value.
Giralte et al., U.S. Patent Application Publication Number 2020/0410479 A1. This reference teaches optimized online presence blockchain trust management to avoid online fraud.
Grendon et al., U.S. Patent Application Publication Number 2019/0188704 A1. This reference teaches a method for processing a trust-based transaction via a blockchain.
Rosli, Athirah, Suhaidi Hassan, Mohd Hasbullah Omar. “Data Authentication Mechanism Using Blockchain’s Proof-of-Trust Mechanism in Named Data Networking.” https://pubs.aip.org/aip/acp/article/2608/1/020020/2895737/Data-authentication-mechanism-using-blockchain-s (Jun 12, 2023). This reference teaches the use of proof-of-trust in Named Data Networking for providing an alternative for data authentication.
Bahri, Leila and Sarunas Girdzijauskas. “When Trust Saves Energy: A Reference Framework for Proof of Trust (PoT) Blockchains,” https://dl.acm.org/doi/pdf/10.1145/3184558.3191553 (April 23-27, 2018). This reference teaches a proof-of-trust blockchain where peer trust is valuated in the network based on a trust graph that emerges in a decentralized fashion that is encoded in and managed by the blockchain itself.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELIZABETH H ROSEN whose telephone number is (571) 270-1850 and email address is elizabeth.rosen@uspto.gov. The examiner can normally be reached Monday - Friday, 10 AM ET - 7 PM ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Michael Anderson, can be reached at 571-270-0508. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ELIZABETH H ROSEN/Primary Examiner, 3693
Prosecution Insights