CTFR 18/857,640 CTFR 94840 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. 12-151 AIA 26-51 12-51 Status of Claims • This action is in reply to the amendments filed on April 8, 2026 • Claims 1, 6, 13, 15, have been amended and are hereby entered. • Claims 16-17 have been added. • Claims 3, and 14 have been canceled. • Claims 1-2, 4-13, and 15-17 are currently pending and have been examined. • This action is made FINAL. Response to Arguments 07-37 AIA Applicant’s arguments filed April 8, 2026 have been fully considered but they are not persuasive. The Examiner is withdrawing the drawing objections due to Applicant’s amendments. New 35 USC § 112 rejections have been entered due to applicant’s amendments. The Examiner is withdrawing the 35 USC § 101 rejection for claim 15 being directed to signals per se due to Applicant’s amendments. Applicant’s arguments with respect to 35 USC § 101 have been fully considered and are not persuasive. Regarding Applicant’s argument on pages 9-10, that the claims improve security of merchant-initiated transactions by generating the next cryptogram for subsequent use without the need for the merchant to store private customer payment information, the Examiner respectfully notes that this type of improvement described is an improvement to the abstract idea of protecting customer payment information. Regarding Applicant’s arguments on pages 10-11, that the claims integrate a practical application, the Examiner respectfully disagrees. Under the Patent Subject Matter Eligibility analysis, Step 2A, prong two, integration into a practical application requires an additional element(s) or a combination of additional elements in the claim to 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 exception. Limitations that are not indicative of integration into a practical application are those that are mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea.-see MPEP 2106.05(f). Here, the claims recite a data processing system comprising a processor configured to perform a method comprising claim functions; and a computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to perform claim functions; a payment network such that they amount to no more than mere instructions to apply the exception using generic computer components (see MPEP 2106.05(f)). Furthermore, and in response to Applicant’s remarks on pages 10-11 regarding a purported technological solution, in determining whether a claim integrates a judicial exception into a practical application, a determination is made of whether the claimed invention pertains to an improvement in the functioning of the computer itself or any other technology or technical field (i.e., a technological solution to a technological problem). Here, the claims recite generic computer components, i.e., a generic processor, a memory storing a computer program executable by the processor to perform the claimed method steps and system functions. The processor, memory and system are recited at a high level of generality and are recited as performing generic computer functions customarily used in computer applications. Furthermore, the Specification describes a problem and improvement to a business or commercial process at least at page 1, line 13 to page 2, line 17, describing: “To protect sensitive payment card data, the data may be replaced with a secure payment token. A payment card may be inserted into a digital wallet wherein the primary account number, card verification code/value and expiration data is replaced with the payment taken that serves as a secure reference to the payment card… When a digital wallet is used to create the cryptogram, it often brings additional benefits to the merchant such as fraud liability protection due to the cardholder authentication performed and indicated within the cryptogram data…Therefore, it is desirable to provide a transaction authentication method to alleviate at least these problems. Objects and aspects of the present disclosure seek to provide a transaction authentication method to alleviate or solve these problems.” The claims are not patent eligible. Applicant’s arguments with respect to 35 USC § 103 have been fully considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. For the reasons above, Applicant’s arguments are not persuasive . Claim Rejections - 35 USC § 112 07-30-01 AIA 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. 07-31-01 AIA Claim s 1-2, 4-13, and 15-17 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 pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 1 recites the limitations of “the next transaction notification indicates credentials are authorized to be used in a future second transaction.” Although the Specification at page 7, lines 1-9, describes a next transaction notification as identifying a future second transaction, the Specification is devoid of support for the feature that the next transaction notification indicates that credentials are authorized to be used in a future second transaction. Therefore this feature is new matter. Claims 13 and 17 have similar limitations found in claim 1 above, and therefore is rejected by the same rationale. Claim 6 recites the limitation of “the second transaction request does not include consumer card information.” The Specification is devoid of this feature. Furthermore, it is noted, any negative limitation or exclusionary proviso must have basis in the original disclosure. If alternative elements are positively recited in the specification, they may be explicitly excluded in the claims. See In re Johnson , 558 F.2d 1008, 1019, 194 USPQ 187, 196 (CCPA 1977) (“[the] specification, having described the whole, necessarily described the part remaining.”). See also Ex parte Grasselli , 231 USPQ 393 (Bd. App. 1983), aff' d mem., 738 F.2d 453 (Fed. Cir. 1984). The mere absence of a positive recitation is not basis for an exclusion. Therefore it is new matter. The rest of the dependent claims are rejected due to their dependency to a rejected claim . Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 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-2, 4-13, and 15-17 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. Independent claims 1, 13, and 15 are directed to a method (claim 1), a system (claim 13), and an apparatus (claim 15). Therefore, on its face, each independent claim 1, 13, and 15 are directed to a statutory category of invention under Step 1 of the Patent Subject Matter Eligibility analysis (see MPEP 2106.03). Under Step 2A, Prong One of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), claims 1, 13, and 15 recite, in part, a method, a system, and an apparatus of organizing human activity. Using the limitations in claim 1 to illustrate, the claim recites a multiple payment tokenized digital transaction authentication method comprising: receiving a first transaction request including a payment token, first payment information, a first cryptogram and a next transaction notification, wherein the next transaction notification indicates credentials are authorized to be used in a future second transaction; authenticating the first transaction request based at least in part on the first cryptogram; generating a next transaction cryptogram based on the first cryptogram; communicating with an issuer for authorization of the first transaction request; receiving an authorization response approval message to authorize the first transaction request; providing, to a merchant, authorization response approval message to authorize the first transaction request; and providing, to the merchant as part of the authorization response approval message, the next transaction cryptogram suitable for use in authenticating a second transaction request associated with the future second transaction . The limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers fundamental economic principles or practices and commercial and legal interactions (certain methods of organizing human activity), but for the recitation of generic computer components. The claims as a whole recite a method of organizing human activity. The claimed inventions allows for receiving a transaction request, authenticating a transaction request based on a cryptogram, and providing a cryptogram for another transaction request, which is a fundamental economic principle or practice of mitigating risk and a commercial and legal interaction including sales activities or behaviors. Thus, the claims recite an abstract idea. Under Step 2A, Prong Two of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), the judicial exception is not integrated into a practical application. In particular, the additional elements of a data processing system comprising a processor configured to perform a method comprising claim functions; and a computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to perform claim functions; a payment network are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of receiving a transaction request, authenticating a transaction based on the cryptogram, and provide a cryptogram for a next transaction) such that they amount to no more than mere instructions to apply the exception using a generic computer components (see MPEP 2106.05(f)). Accordingly, the combination of 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 are directed to an abstract idea. Under Step 2B of the Patent Subject Matter Eligibility analysis (see MPEP 2106.05), the claim(s) does/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 in the claims amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. The claims are not patent eligible. The dependent claims have been given the full two part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. Dependent claims 2-12 and 16-17 simply help to define the abstract idea. The additional limitations of the dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea. Viewing the claim limitations as an ordered combination does not add anything further than looking at the claim limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea. Accordingly, claims 1-2, 4-13, and 15-17 are ineligible. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-23-aia AIA The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 07-21-aia AIA Claim s 1, 4-7, 13, and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over US 20210084029 A1 (“Kallugudde”) in view of US 20220044212 A1 (“Kaitha”), and in further view of US 20170186008 A1 (“Pachouri”) . Regarding claim 1, Kallugudde discloses a multiple payment tokenized digital transaction authentication method comprising (see at least FIG. 7.): receiving, at a payment network, a first transaction request including a payment token, first payment information, a first cryptogram and a next transaction notification (Merchant server transmits a transaction authorisation request message to payment network, the transaction authorisation request message including the token generated, an expiry date of the token and the cryptogram. See at least [0087]. Token may be tokenized payment card details, see at least [0084]. The transaction authorisation request message may include a flag indicating that the transaction is part of a recurring or incremental payment. See at least [0097].) , authenticating, at the payment network, the first transaction request based at least in part on the first cryptogram (Receiving transaction authorisation request message and validating including validating the cryptogram, see at least [0087]-[0091].) ; generating a next transaction cryptogram based on the first cryptogram (generates a second cryptogram and links the second cryptogram to the first cryptogram, e.g. by creating an electronic record, or appending to an existing electronic record. See at least [0095].) ; communicating, by the payment network, with an issuer for authorization of the first transaction request (Authentication server receives an authentication request message… In the event the authentication is successful, authentication server authenticates the user… authentication server contacting an issuer server and indicating that it has authorised a particular payment transaction… see at least [0057]-[0061]. See also [0089]-[0090] describing communicating with an issuer to determine whether an issuer has approved or declined the transaction.) ; receiving, by the payment network, an authorization response approval message to authorize the first transaction request (Payment network receives authorization message indicating transaction approval, see at least [0090]-[0091].) ; providing, to a merchant via the payment network, authorization response approval message to authorize the first transaction request (Receiving an authorization response message indicating whether transaction is approved or declined, and forwarding the message to the merchant server, see at least [0090]-[0091].) ; and providing, to the merchant, the next transaction cryptogram suitable for use in authenticating a second transaction request associated with the future second transaction (payment network generates a second cryptogram. See at least [0095]. A cryptogram can be used for authenticating a transaction, see at least [0096]-[0102].). While Kallugudde discloses a next transaction notification, Kallugudde does not expressly disclose the next transaction notification indicates credentials are authorized to be used in a future second transaction . Furthermore, while Kallugudde discloses providing the next transaction cryptogram, Kallugudde does not expressly disclose providing the next transaction cryptogram as part of the authorization response approval message . However, Kaitha discloses the next transaction notification indicates credentials are authorized to be used in a future second transaction (Payment request including an identifier that the issuer server uses to identify that the incoming transaction request is a recurring transaction request. The issuer server approves the first recurring payment, and stores the unique identifier by linking it with the pair of the payment account of the user and the merchant account of the merchant. Accordingly, for any subsequent recurring transaction, if the unique identifier is included in the payment request received from the aggregator server, the issuer server identifies that the incoming transaction request is a recurring transaction as per the already setup SI between the user and the merchant. Such recurring transactions do not need any further authentication checks required from the user, and these transactions are considered as already authorized based on the presence of the unique identifier. Hence, the aggregator server is configured to validate the SI request for each subsequent recurring payment received from the acquirer server and append the unique identifier to the SI request for processing of each subsequent recurring payment. See at least [0052].). From the teaching of Kaitha, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the notification of Kallugudde to indicate credentials are authorized to be used in a future second transaction, as taught by Kaitha, in order to improve efficiency of processing transaction and in order to improve security (see Kaitha at least at [0002]-[0005]). While Kallugudde discloses providing the next transaction cryptogram, Kallugudde does not expressly disclose providing the next transaction cryptogram as part of the authorization response approval message . However, Pachouri discloses providing the next transaction cryptogram as part of the authorization response approval message (A response message contains a secondary password which can be used in a subsequent transaction. See at least [0029]. Response message may be an authorization/approval of a transaction, see at least [0056].). From the teaching of Pachouri, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the next transaction cryptogram of Kaitha to be included in an authorization response approval message, as taught by Pachouri, in order to improve security and convenience of transactions (see Pachouri at least at [0002]-[0003]). Regarding claim 4, the combination of Kallugudde, Kaitha, and Pachouri discloses the limitations of claim 1, as discussed above, and Kallugudde further discloses the first transaction request relates to a consumer-initiated transaction (Step 1: Customer associates their payment card with an account administered by a merchant. Card details are provided to merchant server by customer electronic device as part of this process. See at least [0083].) , and the second transaction relates to a merchant-initiated transaction (Step 14: Merchant server transmits a transaction authorisation request message to payment network, the transaction authorisation request message including the token generated, an expiry date of the token, the second cryptogram received and a flag indicating that the transaction is part of a recurring or incremental payment. See at least [0097].). Regarding claim 5, the combination of Kallugudde, Kaitha, and Pachouri discloses the limitations of claim 1, as discussed above, and Kallugudde further discloses the first transaction request includes a third transaction notification (The transaction authorisation request message may include a flag indicating that the transaction is part of a recurring or incremental payment. See at least [0097]. The Examiner interprets the transaction notification which notifies of recurring payment as a third transaction notification.) , and the method further comprises providing a third cryptogram suitable for use in authenticating a third transaction request (the method can be repeated for subsequent authentication attempts, see at least [0050]. payment network generates a second cryptogram. See at least [0095]. A cryptogram can be used for authenticating a transaction, see at least [0096]-[0102].). While Kallugudde discloses a transaction notification, Kallugudde does not expressly disclose a transaction notification identifying a future third transaction . However, Kaitha discloses a transaction notification identifying a future third transaction (Payment request including an identifier that the issuer server uses to identify that the incoming transaction request is a recurring transaction request. See at least [0052].). From the teaching of Kaitha, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the notification of Kallugudde to identify a future third transaction, as taught by Kaitha, in order to improve efficiency of processing transaction and in order to improve security (see Kaitha at least at [0002]-[0005]). Regarding claim 6, the combination of Kallugudde, Kaitha, and Pachouri discloses the limitations of claim 1, as discussed above, and Kallugudde further discloses receiving, at the payment network, a second transaction request including the next transaction cryptogram, wherein the second transaction request does not include consumer card information (the method can be repeated for subsequent authentication attempts, see at least [0050]. Merchant server transmits a transaction authorisation request message to payment network, the transaction authorisation request message including the token generated, an expiry date of the token and the cryptogram. See at least [0087]. Token may be tokenized payment card details, see at least [0084]. The transaction authorisation request message may include a flag indicating that the transaction is part of a recurring or incremental payment. See at least [0097]. The Examiner interprets the token being tokenized payment card details as not consumer card information.) ; authenticating the second transaction request based at least in part on the next transaction cryptogram (Receiving transaction authorisation request message and validating including validating the cryptogram, see at least [0087]-[0091].) ; communicating, by the payment network, with the issuer for authorization of the second transaction request (Authentication server receives an authentication request message… In the event the authentication is successful, authentication server authenticates the user… authentication server contacting an issuer server and indicating that it has authorised a particular payment transaction… see at least [0057]-[0061]. See also [0089]-[0090] describing communicating with an issuer to determine whether an issuer has approved or declined the transaction.) ; receiving, by the payment network, a second authorization response approval message to authorize the second transaction request (Payment network receives authorization message indicating transaction approval, see at least [0090]-[0091].) ; and providing, to the merchant via the payment network, the second authorization response approval message to authorize the second transaction request (Receiving an authorization response message indicating whether transaction is approved or declined, and forwarding the message to the merchant server, see at least [0090]-[0091].). Regarding claim 7, the combination of Kallugudde, Kaitha, and Pachouri discloses the limitations of claim 6, as discussed above, and Kallugudde further discloses the second transaction request includes a third transaction notification (the method can be repeated for subsequent authentication attempts, see at least [0050]. The transaction authorisation request message may include a flag indicating that the transaction is part of a recurring or incremental payment. See at least [0097].) , and the method further comprises providing a third cryptogram suitable for use in authenticating a third transaction request (payment network generates a second cryptogram. See at least [0095]. A cryptogram can be used for authenticating a transaction, see at least [0096]-[0102].). While Kallugudde discloses a third transaction notification, Kallugudde does not expressly disclose a third transaction notification identifying a future second transaction . However, Kaitha discloses a third transaction notification identifying a future third transaction (Payment request including an identifier that the issuer server uses to identify that the incoming transaction request is a recurring transaction request. See at least [0052].). From the teaching of Kaitha, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the notification of Kallugudde to identify a future third transaction, as taught by Kaitha, in order to improve efficiency of processing transaction and in order to improve security (see Kaitha at least at [0002]-[0005]). Claim 13 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale. And Kallugudde discloses A data processing system comprising:a processor and a non-transitory computer-readable storage medium comprising instructions, wherein the instructions, when executed by the processor, direct the data processing system to perform claim functions (See at least [0107]-[0113]). Claim 15 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale. And Kallugudde discloses a non-transitory computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to perform claim functions (See at least [0107]-[0113]). Claim 16 has similar limitations found in claim 6 above, and therefore is rejected by the same art and rationale. Claim 17 has similar limitations found in claim 6 above, and therefore is rejected by the same art and rationale . 07-21-aia AIA Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Kallugudde in view of Kaitha, in further view of Pachouri, and in further view of US 20150032626 A1 (“Dill”) . Regarding claim 2, the combination of Kallugudde, Kaitha, and Pachouri discloses the limitations of claim 1, as discussed above. And while Kallugudde discloses a first cryptogram (see Kallugudde at least at [0087]), Kallugudde does not expressly disclose that the first cryptogram is a function of a token number of the payment token and the first payment information However, Dill discloses the first cryptogram is a function of a token number of the payment token and the first payment information (a mobile payment application of a mobile device may use a shared algorithm that uses a time, a transaction counter, and/or other dynamic data as well as a portion of the token to generate a dynamic card verification value (dCVV) for each transaction. See at least [0210]. Token is a string of numbers, see at least [0069].). From the teaching of Dill, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the first cryptogram to be a function of a token number and the first payment information, as taught by Dill, in order to improve security of transactions (see Dill at least at [0029], [0003]-[0009], and [0053]), in order to increase service transparency and reduce merchant and issuer costs (see Dill at least at [0029]), and in order to provide improved protections against misuse of payment accounts (see Dill at least at [0047]), and to improve issuers and consumers transaction approval levels (see Dill at least at [0048]) . 07-21-aia AIA Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Kallugudde in view of Kaitha, in further view of Pachouri, and in further view of US 20090276347 A1 (“Kargman”) . Regarding claim 8, the combination of Kallugudde, Kaitha, and Pachouri disclose the limitations of claim 1, as discussed above. Kallugudde does not expressly disclose the next transaction cryptogram includes a maximum second payment value to limit a value of the second transaction . However, Kargman discloses the next transaction cryptogram includes a maximum second payment value to limit a value of the second transaction (The limits may be encoded into the temporary number or otherwise linked to the number. See at least Abstract and [0015]. See also [0036]. The user set limits may be a limit as to an amount of a single purchase or payment, a limit on cumulative purchases or payments, a time limit, such as an expiration time, a limit on times of the day, on days of the week or other time limits within which purchases are authorized, a limit as to the recipient that may receive the payment or on a type or location of recipient or business that may receive the payment or other criteria for the recipient of the payment. Other limits are also possible. See at least [0008].). From the teaching of Kargman, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the next transaction cryptogram of Kallugudde to include a maximum second payment value, as taught by Kargman, in order to improve transaction security (see Kargman at least at [0037]) . 07-21-aia AIA Claim s 9 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Kallugudde in view of Kaitha, in further view of Pachouri, and in further view of WO 2017127867 A1 (“Wilson”) . Regarding claim 9, the combination of Kallugudde, Kaitha, and Pachouri disclose the limitations of claim 1, as discussed above. Kallugudde does not expressly disclose the next transaction cryptogram includes merchant information . However, Wilson discloses the next transaction cryptogram includes merchant information (The cryptogram may also include the merchant POS/EFTPOS terminal identification number. See at least [0211].). From the teaching of Wilson, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the next transaction cryptogram of Kallugudde to include merchant information, as taught by Wilson, in order to mitigate transaction fraud and improve security (see Wilson at least at [0026]-[0031]) Regarding claim 12, the combination of Kallugudde and Kaitha disclose the limitations of claim 1, as discussed above. Kallugudde does not expressly disclose the next transaction cryptogram is time limited . However, Wilson discloses the next transaction cryptogram is time limited (the PINs may have a limited period of validity, for example, expiring one week after first use. See at least [0063].). From the teaching of Wilson, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the next transaction cryptogram of Kallugudde to be time limited, as taught by Wilson, in order to mitigate transaction fraud and improve security (see Wilson at least at [0026]-[0031]) 07-21-aia AIA Claim s 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Kallugudde in view of Kaitha, in further view of Pachouri, and in further view of US 20160019536 A1 (“Ortiz”) . Regarding claim 10, the combination of Kallugudde, Kaitha, and Pachouri disclose the limitations of claim 1, as discussed above. Kallugudde does not expressly disclose the next transaction cryptogram includes an incrementing transaction counter . However, Ortiz discloses the next transaction cryptogram includes an incrementing transaction counter (Thus, for example, at least the customer's selected payment method and the total payment amount may be encoded into the secure cryptogram. As described in more detail below, for such entity(ies) that has/have capability to decode the cryptogram, the payment instructions encoded therein may be accessed and executed, e.g., by the financial institution debiting (or crediting) the customer's selected card or account by the purchase amount. Other transaction or identification information, such as customer, device, account, and/or other credentials, an application transaction counter, or a unique derivation key, may also optionally be encoded without limitation into the secure cryptogram. See at least [0163].). From the teaching of Ortiz, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the next transaction cryptogram of Kallugudde to include an incrementing transaction counter, as taught by Ortiz, in order to improve flexibility in payment transactions and provide commercial advantages (see Ortiz at least at [0032]), and in order to improve security (see Ortiz at least at [0039]), and in order to improve efficiency of processing requests (see Ortiz at least at [0042]), and in order to reduce susceptibility to improper access and misuse of transaction data (see Ortiz at least at [0187]-[0192]), and in order to improve customer experience (see Ortiz at least at [0380]). Regarding claim 11, the combination of Kallugudde and Kaitha disclose the limitations of claim 1, as discussed above. Kallugudde does not expressly disclose the first cryptogram includes consumer identification information and the next transaction cryptogram also includes the consumer identification information . However, Ortiz discloses the first cryptogram includes consumer identification information and the next transaction cryptogram also includes the consumer identification information (Thus, for example, at least the customer's selected payment method and the total payment amount may be encoded into the secure cryptogram. As described in more detail below, for such entity(ies) that has/have capability to decode the cryptogram, the payment instructions encoded therein may be accessed and executed, e.g., by the financial institution debiting (or crediting) the customer's selected card or account by the purchase amount. Other transaction or identification information, such as customer, device, account, and/or other credentials, an application transaction counter, or a unique derivation key, may also optionally be encoded without limitation into the secure cryptogram. See at least [0163].). From the teaching of Ortiz, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the first cryptogram and next transaction cryptogram to include consumer identification information, as taught by Ortiz, in order to improve flexibility in payment transactions and provide commercial advantages (see Ortiz at least at [0032]), and in order to improve security (see Ortiz at least at [0039]), and in order to improve efficiency of processing requests (see Ortiz at least at [0042]), and in order to reduce susceptibility to improper access and misuse of transaction data (see Ortiz at least at [0187]-[0192]), and in order to improve customer experience (see Ortiz at least at [0380]) . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20220391896 A1 (“Lei”) discloses a hosted point-of-sale service that provides the security features of card-present transactions for card-not-present transactions. The various embodiments of the present disclosure can be configured to receive a merchant identifier and a transaction amount for a transaction from a merchant terminal, as well as receive the merchant identifier and encrypted payment account data for the transaction. The encrypted payment account data can then be decrypted. An authorization request for the transaction is then generated based at least in part on the merchant identifier, the transaction amount, and the payment account data. The authorization request is then sent to a payment processor, which can route the authorization request to an authorizing entity via a payment network. An authorization response is received in response from the authorizing entity via the payment processor, and the contents are forwarded on to the merchant terminal. US 20200097959 A1 (“Tran”) discloses receiving a request for payment credentials. The request indicates an account from which payment for a transaction is to be made. A payment token is looked-up that corresponds to the indicated account. Dynamic expiry data and a dynamic token verification code are generated. As a response to the request, the looked-up payment token, the generated dynamic expiry data and the generated dynamic token verification code are transmitted. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL . See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAVEN E YONO whose telephone number is (313)446-6606. The examiner can normally be reached Monday - Friday 8-5PM EST. 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, Bennett M Sigmond can be reached at (303) 297-4411. 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. /RAVEN E YONO/Primary Examiner, Art Unit 3694 Application/Control Number: 18/857,640 Page 2 Art Unit: 3694
Prosecution Insights