Prosecution Insights
Last updated: October 01, 2026
Application No. 19/281,933

System, Method, and Computer Program Product for Dynamic Passcode Communication

Non-Final OA §101§103§DOUBLEPATENT
Filed
Jul 28, 2025
Priority
Sep 01, 2021 — nonprovisional of PCTUS2021048642 +3 more
Examiner
TRAN, HAI
Art Unit
Tech Center
Assignee
Visa International Service Association
OA Round
1 (Non-Final)
62%
Grant Probability
Moderate
1-2
OA Rounds
2y 3m
Est. Remaining
94%
With Interview

Examiner Intelligence

Grants 62% of resolved cases
62%
Career Allowance Rate
458 granted / 738 resolved
+2.1% vs TC avg
Strong +32% interview lift
Without
With
+31.8%
Interview Lift
resolved cases with interview
Typical timeline
3y 5m
Avg Prosecution
30 currently pending
Career history
765
Total Applications
across all art units

Statute-Specific Performance

§101
38.4%
-1.6% vs TC avg
§103
27.4%
-12.6% vs TC avg
§102
8.8%
-31.2% vs TC avg
§112
16.1%
-23.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 738 resolved cases

Office Action

§101 §103 §DOUBLEPATENT
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 is the Non-Final Office Action in response to Application No. 19/281,933 filed on July 28, 2025, title: “System, Method, And Computer Program Product For Dynamic Passcode Communication”. Status of the Claims Claims 1-18 are pending in the application and have been examined. Priority This application was filed on 07/28/2025 and is a CON of US Application No. 18/367,230 filed on 09/12/2023 (Patented No. 12,393,937) which is a CON of US Application No. 17/632,556 filed on 02/03/2022 (Patented No. 11,790,356) and which is a 371 of PCT/US21/48621 filed on 09/01/2021. For the purpose of examination, the 09/01/2021 is considered to be the effective filing date. Information Disclosure Statement The information disclosure statement (IDS) filed on 10/14/2025 has been considered. A copy of the PTO-1449 form with the examiner’s initials is enclosed to this Office Action. Drawings The drawings submitted on 07/28/2025 are acceptable. 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 § 2146 et seq. 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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer. Claims 1-18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-18 of US Patent No. 12,393,937 and claims 1-14 of US Patent No. 11,790,356. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the present Application recite substantially the same limitations as the claims of the Patents with minor variations that would have been obvious to one of ordinary skills in the art. The present claims are broader in scope and are either anticipated by, or would have been obvious over, the reference claims. Also, the Application and Patents are directed to the same field of invention, have the same inventor, and are commonly owned. Therefore, this rejection is deemed necessary. Application No. 19/281,933 Patent No. 12,393,937 Claim 1, A computer-implemented method comprising: Claim 1, A computer-implemented method comprising: receiving, with at least one processor, with a merchant application installed on a user device, transaction data associated with a transaction, wherein the transaction data includes an account identifier associated with an account at an issuer system; requesting, with at least one processor, with an issuer application installed on a user device, an issuer software development kit (SDK) integrated into the issuer application on the user device, to initialize registration with an issuer system; binding, with the at least one processor, with the issuer SDK integrated into the issuer application on the user device, a token to each of an account identifier associated with an account at the issuer system and a device identifier associated with the user device; transmitting, with the at least one processor, with the merchant application installed on the user device, directly to an issuer application installed on the user device, a request for a one-time passcode; transmitting, with the at least one processor, with the issuer SDK integrated into the issuer application installed on the user device, to the issuer system, a request to register the issuer application installed on the user device with the issuer system, wherein the request to register the issuer application includes the token bound to each of the account identifier associated with the account at the issuer system and the device identifier associated with the user device; registering, with the at least one processor, with the issuer system, the token in association with the account identifier; receiving, with the at least one processor, with the issuer SDK integrated into the issuer application installed on the user device, from the issuer system, a confirmation that the issuer application is registered with the issuer system; receiving, with the at least one processor, with the merchant application installed on the user device, directly from the issuer application installed on the user device, the one-time passcode, wherein the one-time passcode is generated by the issuer application installed on the user device based on the account identifier associated with the account at the issuer system and a device identifier associated with the user device, and wherein the one-time passcode is configured for validation with a token registered at the issuer system in association with the account identifier and the device identifier; receiving, with the at least one processor, with the issuer SDK integrated into the issuer application installed on the user device, directly from a merchant SDK integrated into a merchant application installed on the user device, a request for a one-time password associated with a transaction at a merchant system, wherein the request for the one-time password includes the account identifier and the device identifier, and wherein the merchant application is registered with a payment gateway system; generating, with the at least one processor, with the issuer SDK integrated with the issuer application installed on the user device, based on the account identifier and the device identifier, the one-time password, wherein the one-time password is configured for validation with the token registered at the issuer system in association with the account identifier and the device identifier; bundling and encrypting, with the at least one processor, with the merchant application installed on the user device, the one-time passcode and the account identifier in an authorization request requesting authorization of the transaction; transmitting, with the at least one processor, with the issuer SDK integrated into the issuer application installed on the user device, directly to the merchant SDK integrated into the merchant application installed on the user device, the one-time password for bundling and encrypting of the one-time password with the account identifier in an authorization request requesting authorization of the transaction; transmitting, with the at least one processor, with the merchant application installed on the user device, to the issuer system, the authorization request requesting authorization of the transaction, wherein the authorization request includes a bundled and encrypted account identifier and the one-time passcode, and wherein the transaction is authorized or denied by the issuer system based on the bundled and encrypted account identifier and one-time passcode; and receiving, with the at least one processor, with the issuer system, from the merchant SDK integrated into the merchant application installed on the user device via the payment gateway at which the merchant application is registered, the authorization request requesting authorization of the transaction, wherein the authorization request includes the account identifier bundled with the one-time password that has been decrypted at the payment gateway at which the merchant application is registered; determining, with the at least one processor, with the issuer system, whether to authorize or deny the transaction based on the one-time password; and receiving, with the at least one processor, with the merchant application installed on the user device, from the issuer system, an authorization response authorizing or denying the transaction. transmitting, with the at least one processor, with the issuer system, to the merchant application installed on the user device via the payment gateway at which the merchant application is registered, an authorization response authorizing or denying the transaction. Application No. 19/281,933 Patent No. 11,790,356 Claim 1, A computer-implemented method comprising: Claim 1. A computer-implemented method comprising: receiving, with at least one processor, with a merchant application installed on a user device, transaction data associated with a transaction, wherein the transaction data includes an account identifier associated with an account at an issuer system; transmitting, with the at least one processor, with the merchant application installed on the user device, directly to an issuer application installed on the user device, a request for a one-time passcode; transmitting, with at least one processor, with an issuer application installed on a user device, to an issuer system, a request to register the issuer application installed on the user device with the issuer system, wherein the request to register the issuer application includes a token bound, by the issuer application, to each of an account identifier associated with an account at the issuer system and to a device identifier associated with the user device; in response to transmitting the request to register the issuer application installed on the user device with the issuer system, receiving, with the at least one processor, with the issuer application installed on the user device, from the issuer system, a confirmation that the issuer application is registered with the issuer system; receiving, with the at least one processor, with a merchant application installed on the user device, transaction data associated with a transaction at a merchant system, wherein the merchant application is associated with the merchant system, wherein the transaction data includes the account identifier associated with the account at the issuer system; scanning, with the at least one processor, with the merchant application installed on the user device, the user device to determine whether the issuer application associated with the issuer system is installed on the user device; in response to determining that the issuer application associated with the issuer system is installed on the user device, transmitting, with the at least one processor, with the merchant application installed on the user device, directly to the issuer application installed on the user device, a request for a one-time password; receiving, with the at least one processor, with the issuer application installed on the user device, directly from the merchant application installed on the user device, the request for the one-time password; generating, with the at least one processor, with the issuer application installed on the user device, based on the account identifier and the device identifier, the one-time password, wherein the one-time password is configured for validation with the token registered at the issuer system in association with the account identifier and the device identifier; transmitting, with the at least one processor, with the issuer application installed on the user device, directly to the merchant application installed on the user device, the one-time password; receiving, with the at least one processor, with the merchant application installed on the user device, directly from the issuer application installed on the user device, the one-time passcode, wherein the one-time passcode is generated by the issuer application installed on the user device based on the account identifier associated with the account at the issuer system and a device identifier associated with the user device, and wherein the one-time passcode is configured for validation with a token registered at the issuer system in association with the account identifier and the device identifier; receiving, with the at least one processor, with the merchant application installed on the user device, directly from the issuer application installed on the user device, the one-time password; bundling and encrypting, with the at least one processor, with the merchant application installed on the user device, the one-time passcode and the account identifier in an authorization request requesting authorization of the transaction; bundling and encrypting, with the at least one processor, with the merchant application installed on the user device, the one-time password and the account identifier into an authorization request requesting authorization of the transaction; transmitting, with the at least one processor, with the merchant application installed on the user device, to the issuer system, the authorization request requesting authorization of the transaction, wherein the authorization request includes a bundled and encrypted account identifier and the one-time passcode, and wherein the transaction is authorized or denied by the issuer system based on the bundled and encrypted account identifier and one-time passcode; and transmitting, with the at least one processor, with the merchant application installed on the user device, to the issuer system, the authorization request requesting authorization of the transaction, wherein the authorization request includes the bundled and encrypted account identifier and one-time password; and receiving, with the at least one processor, with the merchant application installed on the user device, from the issuer system, an authorization response authorizing or denying the transaction. receiving, with the at least one processor, with the merchant application installed on the user device, from the issuer system, an authorization response authorizing or denying the transaction. 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-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Step 1: Under the 2019 Revised PEG, Step 1 analysis, the claims are reviewed to determine whether they fall within the four statutory categories of patentable subject matter (i.e., process, machine, manufacture, or combination of matter). Claims 1-18 recite a method, system, and computer program product for dynamic passcode communication as indicated by the Application’s title. The claims recite a process, machine, and manufacture which fall within the four statutory categories of invention (Step 1-Yes, the claims are statutory). Step 2A, Prong 1: Under the 2019 Revised PEG, Step 2A, Prong 1 analysis, the claims are reviewed to determine whether they recite a judicial exception by identifying if the claim limitations fall in one of the enumerated abstract idea groupings (i.e., organizing human activity, mathematical concepts, and mental processes) that amount to a judicial exception to patentability. Claim 1, computer-implemented method comprising: receiving, with at least one processor, with a merchant application installed on a user device, transaction data associated with a transaction, wherein the transaction data includes an account identifier associated with an account at an issuer system; transmitting, with the at least one processor, with the merchant application installed on the user device, directly to an issuer application installed on the user device, a request for a one-time passcode; receiving, with the at least one processor, with the merchant application installed on the user device, directly from the issuer application installed on the user device, the one-time passcode, wherein the one-time passcode is generated by the issuer application installed on the user device based on the account identifier associated with the account at the issuer system and a device identifier associated with the user device, and wherein the one-time passcode is configured for validation with a token registered at the issuer system in association with the account identifier and the device identifier; bundling and encrypting, with the at least one processor, with the merchant application installed on the user device, the one-time passcode and the account identifier in an authorization request requesting authorization of the transaction; transmitting, with the at least one processor, with the merchant application installed on the user device, to the issuer system, the authorization request requesting authorization of the transaction, wherein the authorization request includes a bundled and encrypted account identifier and the one-time passcode, and wherein the transaction is authorized or denied by the issuer system based on the bundled and encrypted account identifier and one-time passcode; and receiving, with the at least one processor, with the merchant application installed on the user device, from the issuer system, an authorization response authorizing or denying the transaction.. The claim limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers a method of organizing human activity but for the recitation of generic computer components (e.g., a processor with the stored program instructions, a user device, a merchant application associated with the merchant system, an account identifier associated with an account at an issuer system, and a device identifier associated with the user device). More specifically, the claim recites fundamental economic principles or practices and/or commercial or legal interactions including a method for authorizing or denying a transaction based on the bundled and encrypted account identifier and one-time passcode using a user device with a merchant application is installed. The claim recites an electronic authentication method where the user is authorized the transaction after successfully presenting the bundled and encrypted account identifier and the one-time passcode to the issuer system (multi-factor authentication "MFA" or two-factor authentication "TFA"). Authorization of a transaction using bundled and encrypted account identifier and the one-time passcode (TFA) to minimizing risk is a fundamental economic practice (i.e., hedging, insurance, mitigating risk) and a commercial interaction between a user and merchant (i.e., agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). See MPEP 2106.04(a)(2)III.C.2. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a fundamental economic practice or commercial interaction, then it falls within the "Certain Methods of Organizing Human Activity" grouping of abstract ideas. The mere nominal recitation of computer components (i.e., a processor with the stored program instructions, a user device, a merchant application associated with the merchant system, an account identifier associated with an account at an issuer system, and a device identifier associated with the user device) do not take the claim out of the Certain Methods Of Organizing Human Activity grouping. Accordingly, the claim recites an abstract idea. While claim 1 is addressed above, the analysis above can be applied to claim 7 where the processors and memories also serve as mere instructions to apply an exception using generic computer components. Similarly, the non-transitory computer-readable medium of claim 13 is an additional element that serves as mere instructions to apply an exception using a generic computer component and does not provide a practical application or significantly more than the judicial exception. Therefore, these claims also recite an abstract idea (Step 2A Prong 1-Yes, the claims recite an abstract idea). Step 2A, Prong 2: Under the 2019 Revised PEG, Step 2A, Prong 2 analysis, the claims are reviewed to determine whether the judicial exception (i.e., abstract idea) is integrated into a practical application. In order to make this determination, the additional element(s), or combination of elements, are analyzed to determine if the claim as a whole integrates the recited judicial exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. The judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of: a processor along with the programmed instructions, a user device, a merchant application associated with the merchant system, an account identifier associated with an account at an issuer system, and a device identifier associated with the user device. The computer components all are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component, and this is substantiated by the Applicant’s Specification (see Publication No. 2025/0356348, paragraphs 72-94 and Figures 1-2). The recitation of generic computer components in a claim does not necessarily preclude that claim from reciting an abstract idea. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, the claims recite an abstract idea (Step 2A, Prong 2-No, the claims are not integrated into a practical application). Step 2B: Under the 2019 Revised PEG, Step 2B analysis, the claims are reviewed to determine whether the claims provide an inventive concept (i.e., whether the claim(s) include additional elements, or combinations of elements, that are sufficient to amount to significantly more than the judicial exception (i.e., abstract idea)). Independent claims 1, 7, and 13 do not include additional elements, considered both individually and as an ordered combination, 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 element of using a computer to perform the step receiving, transmitting, receiving, bundling and encrypting, transmitting, and receiving functions as claimed amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. All these generic computer functions are well-understood, routine, and conventional activities previously known to the industry similar to those referenced by MPEP 2106.05(d) II. Therefore, the independent claims are not patent eligible. Dependent claims 2-6, 8-12, and 14-18 depend on claims 1, 7, and 13 respectively, and therefore include all the limitations of claims 1, 7, and 13. Thus, the dependent claims recite the same abstract idea as discussed in the independent claims. Claims 2, 8, and 14 recite the additional elements “further comprising: before receiving, with the merchant application installed on the user device, the transaction data associated with the transaction at the merchant system, transmitting, with the at least one processor, from the merchant application installed on the user device, to a payment gateway system, a request to register the merchant application installed on the user device with the payment gateway system; and in response to transmitting the request to register the merchant application installed on the user device, receiving, with the at least one processor, with the merchant application installed on the user device, from the payment gateway system, a confirmation that the merchant application is registered with the payment gateway system.” (Additional detailed instructions for transmitting a request to register the merchant application with the user gateway system and receiving a confirmation for the registration. The claims individually or in combination with others do not integrate the abstract idea into a practical application or add an inventive concept to the abstract idea.) Claims 3, 9, and 15 recite the additional elements “further comprising: scanning, with the at least one processor, with the merchant application installed on the user device, the user device to determine whether the issuer application associated with the issuer system is installed on the user device, and wherein the merchant application installed on the user device transmits the request for the one-time passcode directly to the issuer application installed on the user device in response to determining that the issuer application associated with the issuer system is installed on the user device.” (Additional detailed instructions for the scanning, transmitting, and determining steps. The claims individually or in combination with others do not integrate the abstract idea into a practical application or add an inventive concept to the abstract idea.) Claims 4, 10, and 16 recite the additional elements “wherein scanning, with the at least one processor, with the merchant application installed on the user device, the user device to determine whether the issuer application associated with the issuer system is installed on the user device includes: transmitting, with the merchant application installed on the user device, to the payment gateway system, at least a portion of the account identifier; receiving, with the merchant application installed on the user device, from the payment gateway system, an identification of the issuer application associated with the issuer system associated with the account identifier; and scanning, with the merchant application installed on the user device, the user device for the identified issuer application.” (Additional detailed instructions for the scanning step recited in the previous claims to include transmitting, receiving, and scanning steps. The claims individually or in combination with others do not integrate the abstract idea into a practical application or add an inventive concept to the abstract idea.) Claims 5, 11, and 17 recite the additional elements “wherein the at least one processor transmits the authorization request from the merchant application to the issuer system via a merchant system and a payment gateway system.” (Additional detailed instructions for the processor to transmit the authorization request from the merchant application to the issuer system. The claims individually or in combination with others do not integrate the abstract idea into a practical application or add an inventive concept to the abstract idea.) Claims 6, 12, and 18 recite the additional elements “wherein the at least one processor receives the authorization response with the merchant application from the issuer system via a merchant system and a payment gateway system.” (Additional detailed instructions for the processor to receive the authorization request from the merchant application to the issuer system. The claims individually or in combination with others do not integrate the abstract idea into a practical application or add an inventive concept to the abstract idea.) The dependent claims do not include any additional elements that are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. The dependent claims recite limitations that further define the same abstract idea noted in their independent claims. Each and every recited combination between the recited computing hardware and the recited computing functions has been considered. No non-generic or non-conventional arrangement is found in the claims. There is no inventive concept found in the claims. The claims do no more than generally linking the use of the judicial exception to a particular technical environment or field of use. Therefore, the dependent claims also are not patent eligible. The focus of the claims is on a method for authorizing or denying an electronic transaction based on the bundled and encrypted account identifier and one-time passcode using a user device with a merchant application is installed. The claims are not directed to a new type of processor, computer network, or system memory, nor do they provide a method for processing data that improves existing technological processes. The focus of the claims is not on improving computer-related technology, but on a certain independent abstract idea that uses computers as tools. Accordingly, when viewed as a whole, the claims do no more than generally linking the use of the judicial exception to a particular technological environment or field of use. No inventive concept is found in the claims. Therefore, the claims do not add significantly more (i.e., an inventive concept) to the abstract idea (Step 2B-No, the claims are not significantly more than the judicial exception). Claim Rejections - 35 USC § 103 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 (i.e., changing from AIA to pre-AIA ) 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. 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, 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: Determining the scope and contents of the prior art. Ascertaining the differences between the prior art and the claims at issue. Resolving the level of ordinary skill in the pertinent art. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1-18 are rejected under 35 U.S.C. 103 as being unpatentable over Ravi (US Publication No. 2020/0280557, hereinafter “Ravi”) and further in view of Fisher (US Publication No. 2013/0317989, hereinafter “Fisher”). As per Claim 1, Ravi teaches a computer-implemented method comprising: receiving, with at least one processor, with a merchant application installed on a user device, transaction data associated with a transaction, wherein the transaction data includes an account identifier associated with an account at an issuer system (see Ravi, at least Abstract, paras. 60-66; Figures 2-4); transmitting, with the at least one processor, with the merchant application installed on the user device, directly to an issuer application installed on the user device, a request for a one-time passcode (see Ravi, at least Abstract, paras. 60-66; Figures 2-4); receiving, with the at least one processor, with the merchant application installed on the user device, directly from the issuer application installed on the user device, the one-time passcode, wherein the one-time passcode is generated by the issuer application installed on the user device based on the account identifier associated with the account at the issuer system and a device identifier associated with the user device, and wherein the one-time passcode is configured for validation with a token registered at the issuer system in association with the account identifier and the device identifier (see Ravi, at least Abstract, paras. 60-66; Figures 2-4); bundling and encrypting, with the at least one processor, with the merchant application installed on the user device, the one-time passcode and the account identifier in an authorization request requesting authorization of the transaction (see Ravi, at least Abstract, paras. 60-66; Figures 2-4); transmitting, with the at least one processor, with the merchant application installed on the user device, to the issuer system, the authorization request requesting authorization of the transaction, wherein the authorization request includes a bundled and encrypted account identifier and the one-time passcode, and wherein the transaction is authorized or denied by the issuer system based on the bundled and encrypted account identifier and one-time passcode (see Fisher, para 38 “the merchant… may send an authorization message to a payment network… The payment network may forward the authorization message… to an issuer” ; Figure 2/element 220 “Merchant transmits authorization message to issuer payment network”. see Ravi, Abstract, para. 60-66, Figures 2-4); and receiving, with the at least one processor, with the merchant application installed on the user device, from the issuer system, an authorization response authorizing or denying the transaction (see Fisher, para 39 “The issuer may return the authorization response via the payment network to the merchant”; Figure 2/element 225 “Issuer returns authorization response to merchant”. see Ravi, Abstract, para. 60-66, Figures 2-4). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the authorization request and response process, as taught by Fisher, in the system/method of Ravi since the claimed is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. As per Claim 2, The computer-implemented method of claim 1, further comprising: before receiving, with the merchant application installed on the user device, the transaction data associated with the transaction at the merchant system, transmitting, with the at least one processor, from the merchant application installed on the user device, to a payment gateway system, a request to register the merchant application installed on the user device with the payment gateway system (see Ravi, Abstract, para. 57-66, Figures 1-4); and in response to transmitting the request to register the merchant application installed on the user device, receiving, with the at least one processor, with the merchant application installed on the user device, from the payment gateway system, a confirmation that the merchant application is registered with the payment gateway system (see Ravi, Abstract, para. 57-66, Figures 1-4). As per Claim 3, The computer-implemented method of claim 2, further comprising: scanning, with the at least one processor, with the merchant application installed on the user device, the user device to determine whether the issuer application associated with the issuer system is installed on the user device (see Ravi, at least Abstract, paras. 60-66; Figures 2-4), and wherein the merchant application installed on the user device transmits the request for the one-time passcode directly to the issuer application installed on the user device in response to determining that the issuer application associated with the issuer system is installed on the user device (see Ravi, at least Abstract, paras. 60-66; Figures 2-4). As per Claim 4, The computer-implemented method of claim 3, wherein scanning, with the at least one processor, with the merchant application installed on the user device, the user device to determine whether the issuer application associated with the issuer system is installed on the user device includes: transmitting, with the merchant application installed on the user device, to the payment gateway system, at least a portion of the account identifier (see Ravi, Abstract, para. 57-66, Figures 1-4); receiving, with the merchant application installed on the user device, from the payment gateway system, an identification of the issuer application associated with the issuer system associated with the account identifier (see Ravi, Abstract, para. 57-66, Figures 1-4); and scanning, with the merchant application installed on the user device, the user device for the identified issuer application (see Ravi, Abstract, para. 57-66, Figures 1-4). As per Claim 5, The computer-implemented method of claim 1, wherein the at least one processor transmits the authorization request from the merchant application to the issuer system via a merchant system and a payment gateway system (see Ravi, Abstract, para. 57-66, Figures 1-4). As per Claim 6, The computer-implemented method of claim 1, wherein the at least one processor receives the authorization response with the merchant application from the issuer system via a merchant system and a payment gateway system (see Ravi, Abstract, para. 57-66, Figures 1-4). As per Claim 7, this claim written in computer system form corresponds to claim 1 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 1. As per Claim 8, this claim written in computer system form corresponds to claim 2 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 2. As per Claim 9, this claim written in computer system form corresponds to claim 3 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 3. As per Claim 10, this claim written in computer system form corresponds to claim 4 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 4. As per Claim 11, this claim written in computer system form corresponds to claim 5 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 5. As per Claim 12, this claim written in computer system form corresponds to claim 6 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 6. As per Claim 13, this claim written in computer program form corresponds to claim 1 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 1. As per Claim 8, this claim written in computer program form corresponds to claim 2 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 2. As per Claim 9, this claim written in computer program form corresponds to claim 3 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 3. As per Claim 10, this claim written in computer program form corresponds to claim 4 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 4. As per Claim 11, this claim written in computer program form corresponds to claim 5 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 5. As per Claim 12, this claim written in computer program form corresponds to claim 6 and has the same elements and limitations. Hence, it is rejected under the same rationale provided in claim 6. Conclusion Claims 1-18 are rejected. Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAI TRAN whose telephone number is (571)272-7364. The examiner can normally be reached Monday-Friday, 9-5. 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, Christine M. Behncke can be reached at 571-272-8103. 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. HAI TRAN Primary Examiner Art Unit 3695 /HAI TRAN/Primary Examiner, Art Unit 3695
Read full office action

Prosecution Timeline

Jul 28, 2025
Application Filed
Sep 10, 2026
Non-Final Rejection mailed — §101, §103, §DOUBLEPATENT (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12743701
SYSTEMS AND METHODS FOR PAYMENT AUTHORIZATION UTILIZING A UNIVERSAL TOKEN
2y 6m to grant Granted Sep 22, 2026
Patent 12737764
MERCHANT SPECIFIC MACHINE LEARNING MODEL FOR FRAUD DETECTION
2y 10m to grant Granted Sep 15, 2026
Patent 12737758
TAP-TO-VERIFY PROOF OF PAYMENT CHALLENGE
2y 10m to grant Granted Sep 15, 2026
Patent 12718250
BATCH-PROCESSING TRANSACTIONS IN RESPONSE TO AN EVENT
2y 10m to grant Granted Aug 25, 2026
Patent 12711555
SYSTEM AND NETWORK FOR TIERED OPTIMIZATION
2y 5m to grant Granted Aug 18, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
62%
Grant Probability
94%
With Interview (+31.8%)
3y 5m (~2y 3m remaining)
Median Time to Grant
Low
PTA Risk
Based on 738 resolved cases by this examiner. Grant probability derived from career allowance 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