Prosecution Insights
Last updated: April 19, 2026
Application No. 19/047,139

SYSTEMS, METHODS, AND DEVICES FOR INTEGRATING A FIRST PARTY SERVICE INTO A SECOND PARTY COMPUTER APPLICATION

Non-Final OA §101§112§DP
Filed
Feb 06, 2025
Examiner
OUSSIR, EL MEHDI
Art Unit
3699
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Jpmorgan Chase Bank N A
OA Round
1 (Non-Final)
48%
Grant Probability
Moderate
1-2
OA Rounds
4y 2m
To Grant
98%
With Interview

Examiner Intelligence

Grants 48% of resolved cases
48%
Career Allow Rate
116 granted / 242 resolved
-4.1% vs TC avg
Strong +51% interview lift
Without
With
+50.6%
Interview Lift
resolved cases with interview
Typical timeline
4y 2m
Avg Prosecution
29 currently pending
Career history
271
Total Applications
across all art units

Statute-Specific Performance

§101
33.0%
-7.0% vs TC avg
§103
21.9%
-18.1% vs TC avg
§102
7.5%
-32.5% vs TC avg
§112
30.2%
-9.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 242 resolved cases

Office Action

§101 §112 §DP
DETAILED ACTION 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 . This communication is a Non-Final Office Action. Claims 17-22, and 28-39 have been examined in this application. Claims 1-16 and 23-27 are cancelled. No information disclosure statements (IDS) has been filed. Claim Objections Claims 17-22, and 28-39 are objected to because of the following informalities: Per claim 1, the claim is directed to a method carried out by a first party computer program executed by a first party electronic device for a first party. The second, third and fourth limitations are recited as being carried out by the first party computer program without including the language as in the first limitation, which recites that the program is executed by the customer electronic device on the second party computer. A program or computer program is nothing more than software; therefore, software cannot perform functions. As a result, claim 1 should be amended to capture a structure that carries out the claim limitations. Furthermore, claim 1 is confusing because it uses “second party” and “first party” and devices of said parties. The Specification and the dependent claims later try to define these parties as, for instance, a merchant, and a user device. It is requested, in order to overcome confusion, that the claims utilize the terms merchant device and user device instead of first and second to overcome indefiniteness issues. The instant claims raise clarity issues because they claim some functions as being carried out by one entity while later claiming a different entity as an entity that could be carrying out those functions. Per claim 28, the claim is directed to a system including three entities, yet the claim only focuses on what a first party computer program does. Again, a program is code, which cannot execute functions as claimed. Claim 28 must capture appropriate Beauregard language for all entities and recite what each entity carries out positively. Similar to the comments made above regarding claim 17, claim 28 should also utilize terminology such as merchant device, user device, and the like instead of first- and second-party language to overcome confusion and maintain consistency with the Specification. Per claims 34-39, the claims should also utilize terminology as proposed above with regard to claims 17 and 28. Review of the dependent claims in light of the above proposed amendments to the issues is requested. Appropriate correction is required. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 17-22, and 28-33 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Per claims 17, and 28, the claims recite limitations carried out “by the first party computer program.” It is not known how a program, software, can carry out the claim limitations. The Specification doesn’t support software carrying out the claimed limitations. Instead, the Specification does have support for a device of a financial institution comprising instructions when executed by the device causes the device to perform functions. All dependent claims are rejected under the same rational and for mere dependency on the rejected claims. Per claims 18, 29, and 35, the claims recite “wherein the first party is a financial institution, and the second party is a merchant.” It is not known how the second party can be a merchant when claims 17, 28, and 34 recite the second party as “a customer electronic device executing a second party computer program application for a second party” that sends to “a first party computer program executed by a first party electronic device for a first party” a transaction request. Claims 18, 29, and 35 are interpreted as being directed to a first party, the financial institution, which receives at least a transaction request from a customer device. The customer device, second party device, is a user device not a merchant device. Therefore, the claims at issue are rejected for lack of support of a merchant being the second party. Applicant may amend the claims as noted under the objections section to reduce wording in the independent claims and utilize the terms merchant device, customer device, financial institution device, and so on instead of first, second, and third devices. Such amendments, including adequate support from the Specification, would potentially overcome the rejection. The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims 28-33 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim limitations “the first party computer program receives…,” “the first party computer program validates…,” “the first party computer program receives…,” “the first party computer program approves… and transmitting authorization…” render claim 28 indefinite along with all dependent claims because it is not clear whether the limitations are carried out by a computer program or by the computer executing the program to cause the computer to perform the claimed limitations. Applicant my amend the claims to capture appropriate Beauregard language and remove the software language and focus on the structure that causes the limitations to be carried out in order to overcome the rejection. 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 17-22, and 28-39 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claims 17-22, and 28-39 fall within at least one of the four categories of patent eligible subject matter (process, machine, manufacture, or composition of matter). Claims 17-22, and 28-39 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of approving a transaction authorization request and forwarding said approval without significantly more. The abstract idea is categorized under certain methods of organizing human activity and mental processes. The claims capture a concept, which as a whole, can be carried out by a human mind performing concepts such as observation, evaluation, judgement, opinion, and carrying out these concepts using pen and paper. likewise, the claims capture commercial interactions such as sales activities and business relations. Claim 17 amounts to mere receiving of a transaction request between entities (i.e. a first user and another user using verbal or written communication) and the request including an authentication value. The received authentication value is authenticated with a stored value, again can be done in a human head or using a table on paper to match the received value to the written value. Assuming that in response to the validation of the value, an authorization request is received and approved before being sent to another entity or perhaps the second user. Either way, approval of and sending of information is capable of being done by a human. The above detailed flow of the entire scope of the claims is also defined by the certamin method of organizing human activity grouping and its subgroupings, which clearly link the claims to commercial interactions and business relations. The claims are based on a transaction being requested, and at best, approved; thus, a clear business relation between at least the requestor and validator of the transaction. Claim 1, in pertinent part, recites: A method, comprising: receiving, by a first party… and from… a second party, a transaction request to pay for a transaction using a wallet for the first party, the transaction request comprising an authentication value; validating… the authentication value by comparing the authentication value to a stored authentication value; receiving… an authorization request; and approving… the authorization request and transmitting authorization to a payment host for the second party. The judicial exception is not integrated into a practical application. The claims recite the following additional elements: [computer program executed by a first party electronic device for a first party, a customer electronic device executing a second party computer program, a first party electronic device, a customer electronic device, a payment host, non-transitory computer readable storage medium including instructions stored thereon, and one or more computer processors. The additional elements are recited at a high level of generality, wherein the claims merely amount to an abstract idea that is implemented using generic computers, performing generic computer functions such as receiving data, validating the data, receiving further information/data, and outputting a result based on the approval of the data. Each of the additional elements / limitations are no more than mere instructions to apply the exception using generic computer components or a generic device. Accordingly, even in combination, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to merely instructions to apply the exception using generic computer components. The claim limitations do not improve another technology or technical field, improve the functioning of a computer itself, apply the abstract idea with, or by use of, a particular machine (not a generic computer, not adding the words "apply it" or words equivalent to "apply the abstract idea", not mere instructions to implement an abstract idea on a computer, adding insignificant extra solution activity to the judicial exception, generally linking the user of the judicial exception to a particular technological environment or field of use), effects a transformation or reduction of a particular article to a different state or thing, or adds meaningful limitations that amount to more than generally linking the use of the abstract idea to a particular technological environment. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. For instance, claims 20-21 and related claims include provisioning of a session ID and a cryptogram. Again these elements are not considered additional elements as they are nothing more than mere provisioning of data from one entity to another. They are recited at a high level of generality and fail to amount to a practical application, a solution to a technical field or device. The dependent claims fail to recite additional elements that would amount to a practical application or amount to significantly more than the judicial exception as discussed above. The dependent claims further describe the abstract idea. The claims are not patent eligible. Double Patenting The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp. Claims 1 of the instant Applicant is rejected on the ground of non-statutory double patenting as being unpatentable over claim 1 of Patents 11429971 and 12254473. Although claim 1 of the instant Application is not identical to claim 1 of Patents ‘971 and ‘473, they are not patentably distinct from each other because they are directed to the same scope of invention. The instant Application recites a broader scope compared to Patents ‘971 and ‘473. Patents ‘971 and ‘473 includes limitations that are left out of the instant claims. The instant claims are broader than the patented application ‘971 and ‘473, which recite the claimed limitations of the instant Application. Therefore, it would have been obvious to one of ordinary skill in the art to remove the additional limitations in Patents ‘971 and ‘473 to result in claim 1 of the instant Application. Prior Art The claims are not rejected under prior art because the claims recite limitations directed to a architecture between entities that cannot be deemed obvious in view of the art do to the specific entity carrying out the limitations in response to information provided to the entity from another entity and further in view of the forwarding of a response to an entity that is different than other claimed entities. The claims are novel because of the architecture. References are cited which teach the provisioning of data, such as a token, a code, a password, to a merchant to initiate a transaction. The merchant being able to validate the received data and in response send a request to settle the transaction with a bank/financial institution. The claims however, are different than the teachings because the claims clearly capture an entity, the 1st party, receiving a value and request to conduct a transaction from a second party. The first party then validates the value received before receiving an authorization request from the second party and the first party approving the request and forwarding the authorization to a different entity; “a payment host for the second party.” Again, references cited include teachings of providing by a merchant to a bank a value and the bank validating the value, and other transaction data and approving the transaction based on the information provided, the validation, and sending the response of the transaction to the merchant, a third-party, a consumer, or another entity different than the merchant. The issue is that the claims do not recite sending all the data of the transaction to the bank in one instance and then receiving a response. There are two distinct communications between the first and second entity before approval is carried out and a response is sent to a host. U.S. Patent 10,380,583 to Ellis et al. (Ellis), teaches receiving via a messaging hub a code and an identifier for a merchant from a first financial institution, determining, by the messaging hub, a second financial institution based at least partially on the code, sending the code and the merchant identifier to the second financial institution, and receiving from the second financial institution account information to be sent to the first financial institution. The system and method includes sending the account information to the first financial institution to allow the first financial institution to process the payment from an account held by a payor to an account held by the merchant. As noted by the summary of Ellis, Ellis does not teach a method comprising: receiving, by a first party computer program executed by a first party electronic device for a first party and from a customer electronic device executing a second party computer program for a second party, a transaction request to pay for a transaction using a wallet for the first party, the transaction request comprising an authentication value; validating, by the first party computer program, the authentication value by comparing the authentication value to a stored authentication value; receiving, by the first party computer program and from the second party computer program an authorization request; and approving, by the first party computer program, the authorization request and transmitting authorization to a payment host for the second party. U.S. Patent Application Publication 2017/0046679 to Gotlieb et al. (Gotlieb) teaches a user device comprising an application and a stored value card carrying out a purchase mode. The issuer receives a request from the App for a value card based on the provided information sent from the mobile device to the issuer. Upon receipt of the request 1013 from the App 1011, the issuer 1012 will determine, based on the information received in the request 1013 (e.g., App-related purchase information) and the stored App-related information, whether to issue an unfunded stored-value card 1017 in response to the request 1013. The issuer 1012 will apply logical rules to the App-related purchase information and the App-related information to determine whether to issue the requested stored-value card 1017. The issuer may generate a stored-value card 1017 or request a stored value card 1017 from a third party, e.g., a third-party funding source 1016. A user indicates the items it wishes to purchase to the POS and allows the App to communicate an issued, but unfunded, stored-value card to the POS to satisfy all of, or a portion of, the purchase amount for the desired purchase transaction. Once the POS receives the card, it transmits an authorization request to a payment processing system. The issuer receives the request, query database, and authorize the transaction based on matching an App ID with a token card (unfunded value card) and send its own issuer authorization request to the third-party funding source to settle the transaction. If the issuer receives an approval of its issuer authorization request from the third party funding source, the issuer will send an approval of the authorization request to the POS 1014 to facilitate the completion of the purchase transaction. From the above, the reference includes the architectural entities as claimed, however, these entities do not perform the functions as claimed. Thus, it would not be obvious to combine such a reference with another to teach the claimed architecture to manipulate data to cause a transaction settlement. U.S. Patent Application Publication 2014/0090045 to Sanchez et al. (Sanchez) teaches a mobile device sending data including personal and transaction data to a remote server. The remote server tokenizes the data and sends it back to the mobile device and forward this generated token to a merchant. The merchant can authenticate the user using the token without having to enter secure user data. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed on for PTO-892. Any inquiry concerning this communication or earlier communications from the examiner should be directed to EL MEHDI OUSSIR whose telephone number is (571)270-0191. The examiner can normally be reached M-F 9AM - 5PM. 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, Neha W. Patel can be reached on 571-270-1492. 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. Sincerely, /EL MEHDI OUSSIR/Primary Examiner, Art Unit 3699
Read full office action

Prosecution Timeline

Feb 06, 2025
Application Filed
Jan 07, 2026
Non-Final Rejection — §101, §112, §DP (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12586065
CRYPTOCURRENCY TRANSACTION FUND FLOW ANALYSIS METHOD AND SYSTEM
2y 5m to grant Granted Mar 24, 2026
Patent 12561663
DEVICE ACCOUNT ACTIVATION
2y 5m to grant Granted Feb 24, 2026
Patent 12548031
METHOD AND SYSTEM FOR TRANSACTION VALIDATION IN A DISTRIBUTED COMPUTING SYSTEM
2y 5m to grant Granted Feb 10, 2026
Patent 12518256
METHODS AND SYSTEMS FOR RECORDING MULTIPLE TRANSACTIONS ON A BLOCKCHAIN
2y 5m to grant Granted Jan 06, 2026
Patent 12493864
SYSTEMS AND METHODS FOR COMPLETING PAYMENT TRANSACTIONS INITIATED THROUGH A FIRST DEVICE USING A SECOND DEVICE
2y 5m to grant Granted Dec 09, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
48%
Grant Probability
98%
With Interview (+50.6%)
4y 2m
Median Time to Grant
Low
PTA Risk
Based on 242 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month