DETAILED ACTION
Status of Application
This action is a Non-Final Rejection. This action is in response to the request for continued examination filed on October 15, 2025.
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 claim 1 “recites more than just a payment, risk mitigation and commercial interaction.” Remarks at 11. Applicant points to claim language to support this assertion on pages 11-12 of the Remarks. However, claim 1 recites a method that includes steps such as receiving transaction data, assigning an approver score based on previous transaction history, approving a crypto transaction, and completing the payment transaction. These steps are all part of the abstract ideas that are identified in the rejection.
Applicant further argues that “the additional steps in the claims are specific computing mechanisms that solve technical problems, as listed above regarding proof-of-work verification and proof-of-stake verification. The claims improve electronic crypto transaction verification methods by providing a decentralized system that is configured to use historical data to identify a trusted approver node and use the trusted approver node along with non-fungible tokens (NFTs) and smart contracts to verify crypto transaction. These claimed limitations improve crypto payment gateways by enabling verification of crypto transactions while maintaining security and being resource efficient.” Remarks at 12-13. However, Applicant is describing an alleged improvement to a business process, i.e., abstract idea, and not the technology itself. Existing technology is being used to implement the abstract idea.
Therefore, 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.
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 further including:
tracking the final-approver node using a node vulnerability tracker, wherein the tracking includes 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;
based on the determining, transmitting a command to the knowledge graph to select a new final-approver node from the group of nodes, wherein the new final-approver node is different from the final approver node.
5. The method of claim 1 further including:
tracking the final-approver node using a node vulnerability tracker, wherein the tracking includes 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 new final-approver node from the group of nodes, wherein the new final-approver node is different from the final approver node.
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.
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 further comprises a node vulnerability tracker, the node vulnerability tracker 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 new final-approver node from the group of nodes, wherein the new final-approver node is different from the final approver node.
12. The unified payment gateway of claim 8 further comprises a node vulnerability tracker, the node vulnerability tracker 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 new final-approver node from the group of nodes, wherein the new final-approver node is different from the final approver node.
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.
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
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