Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This action is in response to the application filed January 22, 2025. Claims 1-20 are pending and examined.
Specification
Applicant is required to update the status (pending, allowed, etc.) of all parent priority applications in the first line of the specification. The status of all citations of US filed applications in the specification should also be updated where appropriate. (The only priority noted is to a provisional application which not change status. If some other priority claim was missed the sooner it is pointed out the better for everyone.)
Information Disclosure Statement
An initialed and dated copy of Applicant’s IDS form 1449 filed July 2, 2025 is attached to the instant Office action.
Claim Rejections - 35 USC § 101 Utility
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 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
In sum, claims 1–20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception to patentability (i.e., a law of nature, a natural phenomenon, or an abstract idea) and do not include an inventive concept that is something “significantly more” than the judicial exception under the January 2019 patentable subject matter eligibility guidance (2019 PEG) analysis which follows.
Under the 2019 PEG step 1 analysis, it must first be determined whether the claims are directed to one of the four statutory categories of invention (i.e., process, machine, manufacture, or composition of matter). Applying step 1 of the analysis for patentable subject matter to the claims, it is determined that the claims are directed to the statutory category of a process (claims 1–7), a machine (claims 14–20) and a manufacture (claims 8–14), where the machine and manufacture are substantially directed to the subject matter of the process. (See, e.g., MPEP §2106.03). Therefore, we proceed to step 2A, Prong 1.
Under the 2019 PEG step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more designated categories of patent ineligible subject matter (i.e., organizing human activity, mathematical concepts, and mental processes) that amount to a judicial exception to patentability. Here, the claims recite the abstract idea of managing transaction tokens to facilitate reconciliation procedures:
receiving, from a transaction framework implemented on a computing device, a request to generate a transaction token for a transaction to be performed at least in part by a software application executing on the computing device;
verifying the software application and a developer entity associated with the software application;
generating the transaction token;
providing the transaction token to the transaction framework;
receiving (1) the transaction token, and (2) a transaction result associated with the transaction; and
performing a reconciliation procedure based on the transaction token and the transaction result.
Here, the recited abstract idea falls within one or more of the three enumerated 2019 PEG categories of patent ineligible subject matter, to wit: the category of certain methods of organizing human activity, which includes fundamental economic practices or principles and commercial or legal interactions (e.g., performing a reconciliation procedure is a transaction which is a commercial or legal interaction).
Under the 2019 PEG step 2A, Prong 2 analysis, the identified abstract idea to which the claim is directed does not include limitations that integrate the abstract idea into a practical application, since the recited features of the abstract idea are being applied on a computer or computing device or via software programming that is simply being used as a tool (“apply it”) to implement the abstract idea. (See, e.g., MPEP §2106.05(f)). Therefore, the claim is directed to an abstract idea.
Under the 2019 PEG step 2B analysis, the additional elements are evaluated to determine whether they amount to something “significantly more” than the recited abstract idea. (i.e., an innovative concept). Here, the additional elements, such as: a “processor” or “transaction token” do not amount to an innovative concept since, as stated above in the step 2A, Prong 2 analysis, the claims are simply using the additional elements as a tool to carry out the abstract idea (i.e., “apply it”) on a computer or computing device and/or via software programming. (See, e.g., MPEP §2106.05(f)). The additional elements are specified at a high level of generality to simply implement the abstract idea and are not themselves being technologically improved. (See, e.g., MPEP §2106.05 I.A.). Independent claim 1 is nearly identical to independent claims 8 and 15 and so the analysis for claim 1 also applies to claims 8 and 15.
Dependent claims 2–7, 9–14, and 16–20 have all been considered and do not integrate the abstract idea into a practical application. Dependent claims 2, 9, and 16 are substantially similarly and recite limitations that further define the abstract idea noted in claim 1 as they describe the request includes a session identifier associated with the request, a unique identifier associated with the software application, transaction type information that defines whether the transaction will take place through the software application or through at least one webpage that is loaded in a web browser application executing on the computing device, and storefront information that includes locale, currency, tax, and commission information associated with the software application, the computing device, the transaction, or some combination thereof.. Dependent claims 3, 10, and 17 are substantially similarly and recite limitations that further define the abstract idea noted in claim 1 as they describe the verification of the software application and developer entity. Dependent claims 4, 11, and 18 are substantially similarly and both recite limitations that further define the abstract idea noted in claim 1 as they describe the transaction being carried out between the software application and the developer entity. Dependent claims 5, 12, and 19 are substantially similarly and both recite limitations that further define the abstract idea noted in claim 1 as they describe the completion of the first transaction causing a second transaction which is just a more complicated abstract idea of a transaction. Dependent claims 6, 13, and 20 are substantially similarly and both recite limitations that further define the abstract idea noted in claim 1 as they describe when the transaction is canceled invalidating the transaction token. This is the type of generic component being used to carry out the abstract idea noted in claim 1. Dependent claims 7 and 14 are substantially similarly and both recite limitations that further define the abstract idea noted in claim 1 as they describe the user of the software application seeking to engage in a transaction using the software application.
The additional elements of the dependent claims merely refine and further limit the abstract idea of the independent claims and do not add any feature that is an “inventive concept” which cures the deficiencies of their respective parent claim under the 2019 PEG analysis. None of the dependent claims considered individually, including their respective limitations, include an “inventive concept” of some additional element or combination of elements sufficient to ensure that the claims in practice amount to something “significantly more” than patent-ineligible subject matter to which the claims are directed.
The elements of the instant process steps when taken in combination do not offer substantially more than the sum of the functions of the elements when each is taken alone. The claims as a whole, do not amount to significantly more than the abstract idea itself because the claims do not effect an improvement to another technology or technical field (e.g., the field of computer coding technology is not being improved); the claims do not amount to an improvement to the functioning of an electronic device itself which implements the abstract idea (e.g., the general purpose computer and/or the computer system which implements the process are not made more efficient or technologically improved); the claims do not perform a transformation or reduction of a particular article to a different state or thing (i.e., the claims do not use the abstract idea in the claimed process to bring about a physical change. See, e.g., Diamond v. Diehr, 450 U.S. 175 (1981), where a physical change, and thus patentability, was imparted by the claimed process; contrast, Parker v. Flook, 437 U.S. 584 (1978), where a physical change, and thus patentability, was not imparted by the claimed process); and the claims do not move beyond a general link of the use of the abstract idea to a particular technological environment (e.g., simply claiming the use of a computer and/or computer system to implement the abstract idea).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4 and 6-11, 13-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Nayak (USPG 2026/0004,285 A1) in view of Agarwal (USPG 2025/0104,027 A1).
As per claim 1 Nayak teaches”
A method for managing transaction tokens to facilitate reconciliation procedures, the method comprising, by a management entity:
receiving, from a transaction framework implemented on a computing device, a request to generate a transaction token for a transaction to be performed at least in part by a software application executing on the computing device; (see at least Nayak paragraph 7 “Customer devices and payment cards are issued unique, secure, and customizable blockchain (BC)-based tokens. Custom conditions associated with use of the tokens are managed on the BC via smart contracts. When an electronic transaction is being verified by a FI, the payment card and/or device are linked to a prior registered token, a smart contract on the BC is accessed to determine whether the conditions associated with the token are satisfied or not based on real-time transaction information, known information about the customer, and/or real-time device information for the device. The transaction is autho-rized by a corresponding FI to complete the transaction with proper payment to the retailer only after the token is authenticated and the conditions processed by the smart contract are satisfied. Only a registered and known FI can request that tokens be validated for transactions and once the token is validated by the FI, the smart contract is initiated from the BC to evaluate the conditions linked to the token to authenticate the transaction for payment by the FI.”)
verifying the software application and a developer entity associated with the software application; (see at least Nayak paragraph 7 “When an electronic transaction is being verified by a FI, the payment card and/or device are linked to a prior registered token, a smart contract on the BC is accessed to determine whether the conditions associated with the token are satisfied or not based on real-time transaction information, known information about the customer, and/or real-time device information for the device.” While the customer is being verified the software creators setup the protocol for the verification requiring their verification as part of the transaction.)
generating the transaction token; (see at least Nayak paragraph 7 “Customer devices and payment cards are issued unique, secure, and customizable blockchain (BC)-based tokens.”)
providing the transaction token to the transaction framework; (see at least Nayak paragraph 7 “When an electronic transaction is being verified by a FI, the payment card and/or device are linked to a prior registered token, a smart contract on the BC is accessed to determine whether the conditions associated with the token are satisfied or not based on real-time transaction information, known information about the customer, and/or real-time device information for the device.”)
receiving (1) the transaction token, and (2) a transaction result associated with the transaction; (see at least Nayak paragraph 7 “once the token is validated by the FI, the smart contract is initiated from the BC to evaluate the conditions linked to the token to authenticate the transaction for payment by the FI.”) and
performing a reconciliation procedure based on the transaction token and the transaction result. (see at least Nayak paragraph 11 “The smart contract evaluates the real-time information against its configured condition and provides as output a transaction authorization or a transaction denial for the transaction. When the key vault service is unable to authentication the transaction to a secure token linked to the customer, the key vault service sends a transaction denial back to the FI. Assuming the FI receives a transaction authorization, the FI processes a payment from a customer account to a retailer account of a retailer that is performing the transaction.”)
As for verifying the software application and a developer entity associated with the software application while Nayak is not explicit about that step it was a common feature in an electronic transaction as taught by Agarwal (see at least Agarwal paragraphs 25 “"Authentication" is a process by which the credential of an endpoint (including but not limited to applications, people, devices, process, and systems) can be verified to ensure that the endpoint is who they are declared to be.” Application verification would cover both a software application and anything such as a developer entity associated with the software.) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success.
As per claims 2 , 9, and 16 Nayak teaches:
storefront information that includes locale, currency, tax, and commission information associated with the software application, the computing device, the transaction, or some combination thereof. (see at least Nayak paragraph 7 “When an electronic transaction is being verified by a FI, the payment card and/or device are linked to a prior registered token, a smart contract on the BC is accessed to determine whether the conditions associated with the token are satisfied or not based on real-time transaction information, known information about the customer, and/or real-time device information for the device.” The device information and transaction information are at least a combination of the computing device and the transaction.)
While Nayak is not explicit about identifying a session, authenticating software, or that a transaction will take place through the software application which is an “Interface” they are common features in an electronic transactions as taught by Agarwal (see at least Agarwal paragraphs 26, 27, and 39 “A communication channel may in some instances comprise a "secure communication channel" or a "tunnel," either of which may be established in any known manner, including the use of mutual authentication and a session key and establishment of a secure communications session. However, any method of creating a secure communication channel may be used, and communication channels may be wired or wireless, as well as long-range, short-range, or medium range. By establishing a secure channel, sensitive information related to a payment device (such as account number, CVV values, expiration dates, etc.) may be securely transmitted between the two entities to facilitate a transaction.” “(0039] "Interface" may include any software module configured to process communications. For example, an interface may be configured to receive, process, and respond to a particular entity in a particular communication format. Further, a computer, device, and/or system may include any number of interfaces depending on the functionality and capabilities of the computer, device, and/or system. In some embodiments or aspects, an interface may include an application programming interface (API) or other communication format or protocol that may be provided to third parties or to a particular entity to allow for communication with a device. Additionally, an interface may be designed based on functionality, a designated entity configured to communicate with, or any other variable. For example, an interface may be configured to allow for a system to field a particular request or may be configured to allow a particular entity to communicate with the system.”) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success.
As per claims 3, 4, 10, 11, 17, and 18 while for verifying the software application and a developer entity associated with the software application while Nayak is not explicit about that step it was a common feature in an electronic transaction as taught by Agarwal (see at least Agarwal paragraphs 25 “"Authentication" is a process by which the credential of an endpoint (including but not limited to applications, people, devices, process, and systems) can be verified to ensure that the endpoint is who they are declared to be.” Application verification would cover both a software application and anything such as a developer entity associated with the software.)
As per claim 6 Nayak teaches:
The method of claim 1, wherein, when the transaction result indicates that the transaction was cancelled, performing the reconciliation procedure comprises:
invalidating the transaction token. (see at least Nayak paragraph 11 “. When the key vault service is unable to authentication the transaction to a secure token linked to the customer, the key vault service sends a transaction denial back to the FI.” Denying the transaction means the token was invalid for the transaction already.)
As per claims 7 and 14 while Nayak was not explicit about the software application being used it was a common feature in the art of electronic transactions as taught by Agarwal. (see at least Agarwal paragraph 39 “(0039] "Interface" may include any software module configured to process communications. For example, an interface may be configured to receive, process, and respond to a particular entity in a particular communication format. Further, a computer, device, and/or system may include any number of interfaces depending on the functionality and capabilities of the computer, device, and/or system. In some embodiments or aspects, an interface may include an application programming interface (API) or other communication format or protocol that may be provided to third parties or to a particular entity to allow for communication with a device. Additionally, an interface may be designed based on functionality, a designated entity configured to communicate with, or any other variable. For example, an interface may be configured to allow for a system to field a particular request or may be configured to allow a particular entity to communicate with the system.”) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success.
As per claim 8 Nayak teaches:
A non-transitory computer readable storage medium configured to store instructions that, when executed by at least one processor included in a management entity, cause the management entity to manage transaction tokens to facilitate reconciliation procedures, by carrying out steps that include:
receiving, from a transaction framework implemented on a computing device, a request to generate a transaction token for a transaction to be performed at least in part by a software application executing on the computing device; (see at least Nayak paragraph 7 )
verifying the software application and a developer entity associated with the software application; (see at least Nayak paragraph 7 While the customer is being verified the software creators setup the protocol for the verification requiring their verification as part of the transaction.)
generating the transaction token; (see at least Nayak paragraph 7 “Customer devices and payment cards are issued unique, secure, and customizable blockchain (BC)-based tokens.”)
providing the transaction token to the transaction framework; (see at least Nayak paragraph 7)
receiving (1) the transaction token, and (2) a transaction result associated with the transaction; (see at least Nayak paragraph 7) and
performing a reconciliation procedure based on the transaction token and the transaction result. (see at least Nayak paragraph 11)
As for verifying the software application and a developer entity associated with the software application while Nayak is not explicit about that step it was a common feature in an electronic transaction as taught by Agarwal (see at least Agarwal paragraphs 25 “"Authentication" is a process by which the credential of an endpoint (including but not limited to applications, people, devices, process, and systems) can be verified to ensure that the endpoint is who they are declared to be.” Application verification would cover both a software application and anything such as a developer entity associated with the software.) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success.
As per claim 13 Nayak teaches:
The non-transitory computer readable storage medium of claim 8, wherein, when the transaction result indicates that the transaction was cancelled, performing the reconciliation procedure comprises:
invalidating the transaction token. (see at least Nayak paragraph 11 “. When the key vault service is unable to authentication the transaction to a secure token linked to the customer, the key vault service sends a transaction denial back to the FI.” Denying the transaction means the token was invalid for the transaction already.)
As per claim 15 Nayak teaches:
A management entity configured to manage transaction tokens to facilitate reconciliation procedures, the management entity comprising:
at least one processor; (see at least Nayak paragraph 16 “(0016] Each FI server 120 includes at least one processor 121 and a medium 122, which includes instructions”) and
at least one memory storing instructions (see at least Nayak paragraph 16 “(0016] Each FI server 120 includes at least one processor 121 and a medium 122, which includes instructions”) that, when executed by the at least one processor, cause the computing device to carry out steps that include:
receiving, from a transaction framework implemented on a computing device, a request to generate a transaction token for a transaction to be performed at least in part by a software application executing on the computing device; (see at least Nayak paragraph 7 )
verifying the software application and a developer entity associated with the software application; (see at least Nayak paragraph 7 While the customer is being verified the software creators setup the protocol for the verification requiring their verification as part of the transaction.)
generating the transaction token; (see at least Nayak paragraph 7 “Customer devices and payment cards are issued unique, secure, and customizable blockchain (BC)-based tokens.”)
providing the transaction token to the transaction framework; (see at least Nayak paragraph 7)
receiving (1) the transaction token, and (2) a transaction result associated with the transaction; (see at least Nayak paragraph 7) and
performing a reconciliation procedure based on the transaction token and the transaction result. (see at least Nayak paragraph 11)
As for verifying the software application and a developer entity associated with the software application while Nayak is not explicit about that step it was a common feature in an electronic transaction as taught by Agarwal (see at least Agarwal paragraphs 25 “"Authentication" is a process by which the credential of an endpoint (including but not limited to applications, people, devices, process, and systems) can be verified to ensure that the endpoint is who they are declared to be.” Application verification would cover both a software application and anything such as a developer entity associated with the software.) Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success.
As per claim 20 Nayak teaches:
The management entity of claim 15, wherein, when the transaction result indicates that the transaction was cancelled, performing the reconciliation procedure comprises:
invalidating the transaction token. (see at least Nayak paragraph 11 “. When the key vault service is unable to authentication the transaction to a secure token linked to the customer, the key vault service sends a transaction denial back to the FI.” Denying the transaction means the token was invalid for the transaction already.)
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Nayak (USPG 2026/0004,285 A1) in view of Agarwal (USPG 2025/0104,027 A1) and Official Notice.
As per claims 5, 12, and 19 while Nayak is not explicit about providing a second transaction it is old and well known in the art of smart contracts to conduct multiple transactions in response to a transaction providing payment to the various stakeholders in a smart contract which includes a report on the transaction so that everyone can see they received their cut. Therefore it would have been obvious to a person of ordinary skill in the art at the time the invention was made since it was solving a known problem in a known way with an expectation of success.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure:
Wang et al. USPG 2024/0095,364 A1
Any inquiry concerning this communication from the examiner should be directed to Scott S. Trotter, whose telephone number is 571-272-7366. The examiner can normally be reached on 8:30 AM – 5:00 PM, M-F.
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, Matthew Gart, can be reached on 571-272-3955.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
The fax phone number for the organization where this application or proceeding is assigned are as follows:
(571) 273-8300 (Official Communications; including After Final Communications labeled “BOX AF”)
(571) 273-7366 (Draft Communications)
/SCOTT S TROTTER/Primary Examiner, Art Unit 3696