DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
2. Applicant filed the Request for Continued Examination on 07/06/2026. Claims 1, 4-8, 10, 12, 15, and 18-21 are amended. Claims 3, 9, and 17 are canceled. Claims 1-2, 4-8, 10-16, and 18-21 are pending.
Claim Objections
3. Claims 11, 15, and 19 are objected to because of the following informalities:
Claims 11 and 19 recite “a QR code” which is abbreviation.
The first occurrence of all acronyms or abbreviations should be written out for clarity, whether or not they may be considered well known. For example, first occurrence of “QR” in claims should be written out “QR” (Quick Response).
Claim 15 recites “decrypt the preauthorized routing packet and and validate…”, wherein the underlined word “and” is extra.
Appropriate corrections are required.
Claim Rejections - 35 USC § 112
4. 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.
5. Claims 1-2, 4-8, 10-16, and 18-21 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.
Lack of antecedent basis
6. Claim 1 recites the limitation “the data” in paragraph starting with “pairing…”. There is insufficient antecedent basis for this limitation in the claim.
Claim 11 recites the limitation “the routing packet”. There is insufficient antecedent basis for this limitation in the claim.
Examiner suggests, perhaps the applicant was referring to “the preauthorized routing packet”.
Claim 18 recites the limitation “the routing packet”. There is insufficient antecedent basis for this limitation in the claim.
Examiner suggests, perhaps the applicant was referring to “the preauthorized routing packet”.
Claim 15 recites the limitation “the second processing network” in paragraph starting with “deploy…”. There is insufficient antecedent basis for this limitation in the claim.
Examiner suggests, perhaps the applicant was referring to “the second transaction processing network”.
Unclear Scope
7. Claims 1 and 8 recite “decrypting the preauthorized routing packet and validating the set of routing configuration fields”.
Claim 15 recites “decrypt the preauthorized routing packet and [and] validate the set of routing configuration fields”.
Previously claims recite “deploying (deploy) the encrypted preauthorized routing packet to the second processing network associated with the second payment instrument”.
It is not clear how is the preauthorized routing packet decrypted if the second processing network is deployed with the encrypted preauthorized routing packet.
8. “An essential purpose of patent examination is to fashion claims that are precise, clear, correct, and unambiguous. Only in this way can uncertainties of claim scope be removed, as much as possible, during the administrative process.” Zletz, 893 F.2d at 322, 13 USPQ2d at 1322. “For example, if the language of a claim, given its broadest reasonable interpretation, is such that a person of ordinary skill in the relevant art would read it with more than one reasonable interpretation, then a rejection under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph is appropriate.” MPEP 2173.02 I.
9. Claims 2, 4-7, 10, 12-14, 16, and 19-21 are rejected under the same rationale as claims 1, 8, and 15 because claims 2, 4-7, 10, 12-14, 16, and 19-21 inherit the deficiencies of claims 1, 8, and 15 respectively due to their dependency.
Claim Rejections - 35 USC §101
10. 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.
11. Claims 1-2, 4-8, 10-16, and 18-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
12. In the instant case, claims 1, 8, and 15 are directed to a “method, one or more non-transitory computer-readable media, and system for dynamically adapting network routing instructions in real-time”.
13. Claim 1 recites “rerouting a transaction between payment instruments”. Specifically, claim recites (abstract ideas emphasized in bold) “at a mobile device application running on a device processor, the mobile device application associated with an issuer of a first payment instrument, the first payment instrument associated with a first processing network:
pairing the first payment instrument with a second payment instrument associated with a second processing network, the pairing comprising masking the data associated with the second payment instrument;
generating a preauthorized routing packet encoding data associated with the first payment instrument and a set of routing configuration fields;
displaying selectable options for activating and deactivating the preauthorized routing packet and modifying the set of routing configuration fields;
encrypting the preauthorized routing packet using a private key associated with the issuer of the first payment instrument and the first processing network, and generating a quick response (QR) code comprising the encrypted preauthorized routing packet; and
deploying the QR code comprising the encrypted preauthorized routing packet to the second processing network associated with the second payment instrument; and
at the second processing network, in response to a request associated with the second payment instrument:
decrypting the preauthorized routing packet and validating the set of routing configuration fields;
in response to a validation of the set of routing configuration fields, using a network router, rerouting the request to the first payment instrument and executing the request at the first processing network”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
14. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such as ‘in real time”, “a mobile device application running on a device processor”, “a first processing network”, “a second processing network”, “generating a preauthorized routing packet encoding data associated with the first payment instrument”, “displaying selectable options of activating and deactivating the preauthorized routing packet”, “encrypting the preauthorized routing packet using a private key”, “generating a quick response (QR) code”, and “a network router” do no more than represent the use of a computer as a tool to perform an abstract idea. The additional elements do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use, and therefore, neither improve computer functionality nor improve another technology or technical field. With respect to “deploying the QR code comprising the encrypted preauthorized routing packet to the second processing network associated with the second payment instrument” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
15. When analyzed under step 2B (MPEP 2106.04 II), as the additional elements do no more than represent the use of a computer, or computer technology, as a tool to perform rerouting a transaction between payment instruments and/or generally link the abstract idea to a particular technological environment or field of use, they do not improve computer functionality or provide an improvement to another technology or technological field.
16. Hence, claim 1 is not patent eligible.
17. Claims 8 and 15 also recite “rerouting a transaction between payment instruments”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
18. As in the case of claim 1, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of the claims 8 and 15 such as “one or more non-transitory computer-readable media”, “a processor on a computer system”, “a first processor running a mobile device application at a mobile device”, “a first processing network”, “a second processing network”, “generating a preauthorized routing packet encoding data associated with the first payment instrument”, “displaying selectable options for deactivating the preauthorized routing packet”, “encrypting the preauthorized routing packet using a private key”, “a mobile device application, running on a device processor”, “generate a preauthorized routing packet encoding payment instrument information”, and “an electronic transaction”, “a first transaction processing network”, “a second transaction processing network”, and “a network router” respectively, do no more than represent the use of a computer as a tool to perform an abstract idea. The additional elements do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use, and therefore, neither improve computer functionality nor improve another technology or technical field. And, with respect to “transmitting the encrypted preauthorized routing packet to the second processing network associated with the second payment instrument” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
19. When analyzed under step 2B (MPEP 2106.04 II), as the additional elements do no more than represent the use of a computer, or computer technology, as a tool to perform rerouting a transaction between payment instruments and/or generally link the abstract idea to a particular technological environment or field of use, they do not improve computer functionality or provide an improvement to another technology or technological field.
20. Hence, claims 8 and 15 are not patent eligible.
21. The following dependent claims recent additional elements not addressed above:
claims 11 and 19 recite “a QR code”
When considered individually, and as a whole, each of these additional elements amount to merely "apply it", as they are merely applying the abstract idea to the technical environment of the QR code.
22. Dependent claims 2, 4-7, 10-14, 16, and 18-21 merely expand upon the abstract ideas of the independent claims and are therefore rejected under the same rationale as claims 1, 8, and 15 respectively.
Conclusion of 35 USC §101
23. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
24. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
25. 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.
26. 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.
27. 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.
28. Claims 1-2, 4-8, 10-16, and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over US20140149292A1 to Kunz et al. in view of US20150127547A1 to Powell et al. and US20200005106A1 to Singh et al.
29. As per claim 1:
Kunz et al. discloses the following limitations:
A method for dynamically adapting network routing instructions in real time, the method comprising: ([0014] “…The user can change these default static rules, create new rules, or delete a rule…the user can access the proxy card system account and modify the rules at any time, including a time immediately before a payment transaction is initiated using the proxy card…”)
at a mobile device application running on a device processor, the mobile device application associated with an issuer of a first payment instrument, the first payment instrument associated with a first processing network ([0014] “…the user can access the proxy card system account using an application operating on a mobile device…”, [0028] “…The proxy card application 115 can allow the user 101 to set rules, confirm transactions, select preferred cards for a transaction, receive notice of a card selection, and provide other suitable services…”, [0045] “…the proxy card system 140 maintains one or more of the financial instrument accounts and acts as the issuer for that financial instrument account…”)
pairing the first payment instrument with a second payment instrument associated with a second processing network, the pairing comprising masking the data associated with the second payment instrument ([0013] “…proxy card payment systems enable users to utilize a single card to access multiple financial accounts maintained by multiple issuers…”, [0044] “…the user 101 activates the proxy card and associates one or more financial instrument accounts…”, [0053] “… the proxy card may be hidden from the user 101…The user 101 may choose one financial account to be the active account and the selected financial account can become the backing instrument for the proxy card.”, [0073] “American Express category codes are an example of an alternate category code system…”)
generating a preauthorized routing packet encoding data associated with the first payment instrument and a set of routing configuration fields ([0046] “… the user 101 establishes rules for selecting a payment instrument in a transaction…”, [0048] “…a particular payment instrument may be designated as the payment instrument to be selected for an identified merchant category codes (‘MCC’) or a group of codes…”, [0049] “…the proxy card system 140 has predetermined the identified card before the transaction occurs and does not require transaction details for card selection…”, [0030] “…the account information encoded in the magnetic stripe routes payment requests to the proxy card system 140 for processing.”)
displaying selectable options for activating and deactivating the preauthorized routing packet and modifying the set of routing configuration fields ([0058] “…The user 101 can make a selection by actuating a physical or virtual button, by a voice command, by tapping the appropriate representation of the payment instrument, or by any other suitable manner of selecting an instrument…”, [0044] “…the user 101 activates the proxy card and associates one or more financial instrument accounts…”, [0014] “…The user can change these default static rules, create new rules, or delete a rule…”)
deploying the QR code comprising … preauthorized routing packet to the second processing network associated with the second payment instrument ([0051] “…the proxy card system 140 sends the user proxy card account identification information to the card network…”, [0052] “…the card network stores the proxy card account identification information…”, [0036] “…the purchase is initiated by use of a permanent/temporary virtual/physical token, QR code, bar code, or other suitable machine-readable medium captured by POS terminal 134…”)
at the second processing network, in response to a request associated with the second payment instrument: ([0052] “…the account number identifies the proxy card system 140 as the issuer and payments are automatically routed from the card network to the proxy card system 140 for approval.”)
in response to a validation of the set of routing configuration fields, using a network router, rerouting the request to the first payment instrument and executing the request at the first processing network ([0061] “…the proxy card system 140 creates a second payment request and forwards the request to the payment instrument system 170 that issued the payment instrument designated as the backing instrument for the transaction…”, [0013] “…If another issuer maintains the financial account to be used for the transaction, the proxy card system will generate and send a new payment request to that issuer via the card network. The proxy card system will receive the authorization message from the issuer via the card network if the transaction is approved…”)
Kunz et al. does not disclose, however, Powell et al., as shown, discloses the following limitations:
encrypting the preauthorized routing packet … and generating a quick response (QR) code comprising the encrypted preauthorized routing packet ([0147] “…an application in the mobile device 602 may generate a dynamic QRC every time a payment is initiated in a secure manner…”, [0148] “…The token cryptogram may be optionally generated from the mobile device 602 and may serve as the domain restriction control field that may be used by the token service provider to validate the integrity of the transaction using the token.”)
deploying the QR code comprising the encrypted preauthorized routing packet to the second processing network associated with the second payment instrument ([0106] “…The payment network 210 may ensure that the domain restrictions are made available to the token vault 218 to apply the restrictions during token transaction processing.”, [0110] “…The domain restriction controls may be stored in the token vault 218.”, [0147] “…the mobile device 602 may generate a transaction request message 606 including the token, token expiry date, and token cryptogram elements, and any other data from the QRC…”)
decrypting the preauthorized routing packet and validating the set of routing configuration fields ([0124] “…The payment network 312 may verify the state of token-to-PAN mapping in the token vault 313 to ensure that the token is in an active state. The payment network 312 may validate the token cryptogram received in the authorization request message 314. The payment network 312 may also validate the domain restriction controls stored in the token vault 313 for the received token…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for generating the level of assurance associated with a token prior to authorizing a payment transaction that uses the token of Powell et al. (‘547, [0011]) with the teaching of Kunz et al. for transmitting merchant category codes to a payment instrument in a proxy transaction (‘292, [0005]) for generating a dynamic QR code carrying the packet's content (token, expiry, cryptogram) with a cryptogram computed on the device using secret-key cryptography, deploying the packet's content (token, expiry, cryptogram, QRC data) into the network with the transaction, and cryptographically verifying the received cryptogram to apply the corresponding secret key to the received cryptographic payload (‘547, [0147]-[0148], [0124]).
Neither Kunz et al. nor Powell et al. disclose, however, Singh et al., as shown, discloses the following limitations:
[encrypting] … using a private key associated with the issuer of the first payment instrument and the first processing network … ([0024] “…the acquirer FI, the issuer FI, or the payment processor first creates a key pair (a public key and a private key) …”, [0035] “…The private key is not shared and is used only by the signer to electronically sign documents…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for generating the level of assurance associated with a token prior to authorizing a payment transaction that uses the token of Powell et al. (‘547, [0011]) and a method for generating a secure quick response (QR) code for use in purchase transactions at the time a consumer is ready to pay for a selected item or service of Singh et al. (‘106, [0020]) with the teaching of Kunz et al. for transmitting merchant category codes to a payment instrument in a proxy transaction (‘292, [0005]) for generating a private key that held by the issuer financial institution within the transaction-processing framework and used to cryptographically bind data (‘106, [0024], [0035])
Claim 15 is rejected using the same rationale that was used for the rejection of claim 1.
As per claim 15 Kunz et al. additionally discloses the following limitations:
A system for adapting network protocols for rerouting an electronic transaction to an alternate mode of payment, the system comprising: a first transaction processing network; a second transaction processing network ([0073] “American Express category codes are an example of an alternate category code system…”, [0028] “…The proxy card application 115 can allow the user 101 to set rules, confirm transactions, select preferred cards for a transaction, receive notice of a card selection, and provide other suitable services.”, [0066] “…the proxy card system 140 can attempt the transaction with an alternate payment instrument.”)
30. As per claim 2:
Kunz et al. does not disclose, however, Powell et al., as shown, discloses the following limitations:
The method of claim 1, the method further comprising, at the mobile device application, receiving approval of the pairing from a party associated with the second payment instrument ([0050] “…the token service provider may formally process token requestor's application to participate in the token service system…”, [0105] “…The outcome of the registration function is an approval or decline decision on the registration application of the prospective token requestor 114…”, [0075] “…The token service provider 116 may register the token requestor 114 and provision the generated token on requestor's devices.”, [0103] “…a token provisioned onto a secure element, other secure memory of the mobile device…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for generating the level of assurance associated with a token prior to authorizing a payment transaction that uses the token of Powell et al. (‘547, [0011]) with the teaching of Kunz et al. for transmitting merchant category codes to a payment instrument in a proxy transaction (‘292, [0005]) for issuing and maintaining the second payment instrument (i.e., the token) and approving the request for pairing the token to the PAN and sending to the mobile device (‘547, [0050], [0075], [0105]).
Claim 16 is rejected using the same rationale that was used for the rejection of claim 2.
31. As per claim 4:
Kunz et al. discloses the following limitations:
The method of claim 1, wherein validating the set of routing configuration fields comprises validating a condition encoded in the preauthorized routing packet against transaction information encoded in the request ([0057] “…the proxy card system 140 identifies the MCC in the transaction details in the transaction request from the merchant system 130…”, [0048] “…a particular payment instrument may be designated as the payment instrument to be selected for an identified merchant category codes (“MCC”) or a group of codes…”, [0058] “…the proxy card system 140 identifies the payment instrument to use based on the MCC or other rules…”)
Claims 10 and 18 are rejected using the same rationale that was used for the rejection of claim 4.
32. As per claim 5:
Kunz et al. does not disclose, however, Powell et al., as shown, discloses the following limitations:
The method of claim 1, the second processing network comprising a decryption key configured to decrypt the QR code ([0124] “…The payment network 312 may validate the token cryptogram received in the authorization request message 314…”, [0148] “…The token cryptogram may be optionally generated from the mobile device 602 and may serve as the domain restriction control field that may be used by the token service provider to validate the integrity of the transaction using the token…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for generating the level of assurance associated with a token prior to authorizing a payment transaction that uses the token of Powell et al. (‘547, [0011]) with the teaching of Kunz et al. for transmitting merchant category codes to a payment instrument in a proxy transaction (‘292, [0005]) for generating the cryptogram on the device and validating at the network that requires the network to hold and apply the corresponding secret key to the received cryptographic data (‘547, [0124], [0148]).
33. As per claim 6:
Kunz et al. does not disclose, however, Powell et al., as shown, discloses the following limitations:
The method of claim 5, the QR code encoding a limit associated with routing a charge initiated at the second payment instrument to the first payment instrument ([0147] “…the mobile device 602 may generate a transaction request message 606 including the token, token expiry date, and token cryptogram elements, and any other data from the QRC…”, [0045] “…token attributes may include a type of token, frequency of use, token expiry date and/or expiry time, a number of associated tokens, a transaction lifecycle expiry date…”, [0073] “…tokens that are generated in response to a token request from the token requestor 114 are only valid for transactions within the token domain for which the token has been issued.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for generating the level of assurance associated with a token prior to authorizing a payment transaction that uses the token of Powell et al. (‘547, [0011]) with the teaching of Kunz et al. for transmitting merchant category codes to a payment instrument in a proxy transaction (‘292, [0005]) for encoding the token expiry date, and a token initiated charge is de-tokenized and routing to the first instrument (i.e., PAN) (‘547, [0045], [0073], [0147]).
Claim 20 is rejected using the same rationale that was used for the rejection of claim 6.
34. As per claim 7:
Kunz et al. discloses the following limitations:
The method of claim 1, wherein rerouting the request to the first payment instrument comprises rerouting a charge from the second processing network associated with the second payment instrument to the first processing network associated with the first payment instrument ([0061] “…the proxy card system 140 creates a second payment request and forwards the request to the payment instrument system 170 that issued the payment instrument designated as the backing instrument for the transaction…”, [0066] “…the proxy card system 140 can attempt the transaction with an alternate payment instrument.”)
35. As per claim 8:
Kunz et al. discloses the following limitations:
One or more non-transitory computer-readable media storing computer-executable instructions which, when executed by a processor on a computer system, perform a method for dynamically adapting network routing instructions in real time, the method comprising: ([claim 8] “…a non-transitory computer-readable storage device having computer-readable program instructions embodied thereon that when executed by a computer perform a method…”)
at a first processor running a mobile device application at a mobile device: ([0014] “…the user can access the proxy card system account using an application operating on a mobile device…”, [0023] “…or any other wired or wireless, processor-driven device…”)
pairing a first payment instrument associated with a first processing network with a second payment instrument associated with a second processing network ([0013] “…proxy card payment systems enable users to utilize a single card to access multiple financial accounts maintained by multiple issuers…”, [0044] “…the user 101 activates the proxy card and associates one or more financial instrument accounts…”, [0073] “American Express category codes are an example of an alternate category code system…”)
generating a preauthorized routing packet encoding data associated with the first payment instrument and a set of routing configuration fields ([0046] “… the user 101 establishes rules for selecting a payment instrument in a transaction…”, [0048] “…a particular payment instrument may be designated as the payment instrument to be selected for an identified merchant category codes (‘MCC’) or a group of codes…”, [0049] “…the proxy card system 140 has predetermined the identified card before the transaction occurs and does not require transaction details for card selection…”)
displaying selectable options for deactivating the preauthorized routing packet and modifying the set of routing configuration fields ([0014] “…The user can change these default static rules, create new rules, or delete a rule…”, [0058] “…The user 101 can make a selection by actuating a physical or virtual button, by a voice command, by tapping the appropriate representation of the payment instrument, or by any other suitable manner of selecting an instrument…”)
at a second processor running the second processing network, in response to a request associated with the second payment instrument: ([0052] “…the account number identifies the proxy card system 140 as the issuer and payments are automatically routed from the card network to the proxy card system 140 for approval.”, [0023] “…or any other wired or wireless, processor-driven device…”)
in response to validation of the set of routing configuration fields, rerouting the request to the first payment instrument and executing the request at the first processing network ([0061] “…the proxy card system 140 creates a second payment request and forwards the request to the payment instrument system 170 that issued the payment instrument designated as the backing instrument for the transaction…”, [0013] “…If another issuer maintains the financial account to be used for the transaction, the proxy card system will generate and send a new payment request to that issuer via the card network. The proxy card system will receive the authorization message from the issuer via the card network if the transaction is approved…”)
[in response to failed] … executing the request at the second processing network ([0049] “…the particular payment instrument may be designated as the default payment instrument for all transactions that do not trigger any other rule for card selection. That is, if no rule conditions are met for a particular transaction, then the default payment instrument is employed.”, [0013] “…If the proxy card system is the issuer of the financial account, the proxy card system will approve or decline the transaction…”)
Kunz et al. does not disclose, however, Powell et al., as shown, discloses the following limitations:
encrypting the preauthorized routing packet … and the first processing network ([0148] “…The token cryptogram may be optionally generated from the mobile device 602 and may serve as the domain restriction control field that may be used by the token service provider to validate the integrity of the transaction using the token.”)
transmitting the encrypted preauthorized routing packet to the second processing network associated with the second payment instrument ([0050] “…A requestor may interface with a network token system through any suitable communication networks and/or protocols (e.g., using HTTPS, SOAP and/or an XML interface among others) …”, [0106] “…The payment network 210 may ensure that the domain restrictions are made available to the token vault 218 to apply the restrictions during token transaction processing.”, [0110] “…The domain restriction controls may be stored in the token vault 218.”)
decrypting the preauthorized routing packet and validating the set of routing configuration fields ([0124] “…The payment network 312 may verify the state of token-to-PAN mapping in the token vault 313 to ensure that the token is in an active state. The payment network 312 may validate the token cryptogram received in the authorization request message 314. The payment network 312 may also validate the domain restriction controls stored in the token vault 313 for the received token…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for generating the level of assurance associated with a token prior to authorizing a payment transaction that uses the token of Powell et al. (‘547, [0011]) with the teaching of Kunz et al. for transmitting merchant category codes to a payment instrument in a proxy transaction (‘292, [0005]) for generating a dynamic QR code carrying the packet's content (token, expiry, cryptogram) with a cryptogram computed on the device using secret-key cryptography, transmitting the preauthorized routing packet to the second processing network: the token request message carrying the PAN and the domain restriction controls is conveyed to the token service provider (the payment network) over encrypted transport (HTTPS), and cryptographically verifying the received cryptogram to apply the corresponding secret key to the received cryptographic payload (‘547, [0050], [0106], [0148], [0124]).
Neither Kunz et al. nor Powell et al. disclose, however, Singh et al., as shown, discloses the following limitations:
[encrypting] … using a private key associated with an issuer of the first payment instrument … ([0024] “…the acquirer FI, the issuer FI, or the payment processor first creates a key pair (a public key and a private key) …”, [0035] “…The private key is not shared and is used only by the signer to electronically sign documents…”)
in response to a failed validation of the set of routing configuration fields… ([0059] “…If the Hash is invalid, which could mean that the data has been tampered with, then the directory service computer transmits 526 a transaction denied message to the issuer FI, and the process ends…”, [claim 5] “…determining, by the directory service computer, that the merchant ID does not match a stored merchant ID; and transmitting, by the directory service computer to the issuer FI computer, a transaction denied message.”, [claim 6] “…invalidating, by the directory service computer, the Hash…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for generating the level of assurance associated with a token prior to authorizing a payment transaction that uses the token of Powell et al. (‘547, [0011]) and a method for generating a secure quick response (QR) code for use in purchase transactions at the time a consumer is ready to pay for a selected item or service of Singh et al. (‘106, [0020]) with the teaching of Kunz et al. for transmitting merchant category codes to a payment instrument in a proxy transaction (‘292, [0005]) for generating a private key that held by the issuer financial institution within the transaction-processing framework and used to cryptographically bind data, performing a failure path handling, wherein upon a failed validation of the payload's fields the network side service disposing of the request, transmitting a transaction denied message (‘106, [0024], [0035], [0059], [claims 5 and 6]).
36. As per claim 11:
Kunz et al. discloses the following limitations:
The media of claim 8, wherein the routing packet is a QR code ([0031] “…the proxy card is an account accessible by a wireless tap of a user device 110, an account identification number, a bar code or QR code, a token, or other form of account identification or access…”, [0030] “… the account information encoded in the magnetic stripe routes payment requests to the proxy card system 140 for processing.”)
37. As per claim 12:
Kunz et al. does not disclose, however, Powell et al., as shown, discloses the following limitations:
The media of claim 11, the QR code encoding a limit associated with routing a charge initiated at the second payment instrument to the first payment instrument ([0147] “…the mobile device 602 may generate a transaction request message 606 including the token, token expiry date, and token cryptogram elements, and any other data from the QRC…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for generating the level of assurance associated with a token prior to authorizing a payment transaction that uses the token of Powell et al. (‘547, [0011]) with the teaching of Kunz et al. for transmitting merchant category codes to a payment instrument in a proxy transaction (‘292, [0005]) for applying the QR payload that encodes expiry and usage limits bounding the routing of a token initiated charge to the paired PAN (‘547, [0147]).
38. As per claim 13:
Kunz et al. does not disclose, however, Powell et al., as shown, discloses the following limitations:
The media of claim 12, wherein the limit is a time limit ([0045] “…token attributes may include a type of token, frequency of use, token expiry date and/or expiry time, a number of associated tokens, a transaction lifecycle expiry date…”, [0187] “…deployable as static or dynamic (e.g., limited use, time limits) …”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for generating the level of assurance associated with a token prior to authorizing a payment transaction that uses the token of Powell et al. (‘547, [0011]) with the teaching of Kunz et al. for transmitting merchant category codes to a payment instrument in a proxy transaction (‘292, [0005]) for having token expiration date and/or expiration time, transaction lifecycle expiry date (‘547, [0045], [0187]).
39. As per claim 14:
Kunz et al. discloses the following limitations:
The media of claim 12, wherein the limit is a credit limit ([0048] “…proxy card system 140 may be directed to select the payment instrument with the lowest balance or the most available credit…”)
40. As per claim 19:
Kunz et al. discloses the following limitations:
The system of claim 15, wherein the preauthorized routing packet is a QR code ([0031] “…the proxy card is an account accessible by a wireless tap of a user device 110, an account identification number, a bar code or QR code, a token, or other form of account identification or access…”)
41. As per claim 21:
Kunz et al. discloses the following limitations:
The system of claim 15, the preauthorized routing packet comprising an instruction to route a charge from the second transaction processing network associated with the second payment instrument to the first transaction processing network associated with the first payment instrument ([0048] “…a particular payment instrument may be designated as the payment instrument to be selected for an identified merchant category codes (“MCC”) or a group of codes…”, [0061] “…the proxy card system 140 creates a second payment request and forwards the request to the payment instrument system 170 that issued the payment instrument designated as the backing instrument for the transaction…”)
Response to Arguments
42. After careful consideration of applicant arguments, the examiner finds them to be not persuasive. Claims 1-2, 4-8, 10-16, and 18-21 are rejected.
Rejection under 35 USC § 101
43. Applicant’s arguments toward 35 U.S.C. § 101 rejection is not persuasive. Amended independent claims do not have additional elements that could lead to an improvement in the functioning of a computer, or an improvement to other technology or technical field.
44. Applicant is of the opinion that “the claims are not directed to an abstract idea”. Applicant argues that “The amended claims further recite specific network architecture in which the mobile device application is associated with a first network and a first payment instrument, but the preauthorized routing packet may be deployed to a second network associated with a second payment instrument. When a routine request is processed with a second instrument at the second network, the second network may access the routing packet, validate routing configuration fields, and in response subvert the conventional processing at the second network and dynamically reroute the request. The specific improvements obtained though the mobile device application and deployed preauthorized routing packet enable a user to reroute a request based on real-time conditions without reprogramming a router.” And concludes that “These features go beyond merely routing a transaction to integrate the alleged abstract idea into a practical application”.
Examiner respectfully disagrees.
Mentioned above the claim features performed by using the computer components. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)).
45. Applicant is of the opinion that the claimed invention does not recite an abstract idea as an Example 2 Subject Matter Eligibility. Applicant argues that in the claimed invention, similarly to Example 2, the claims directed to a technological improvement that modifies the ordinary protocol for processing a network request. And concludes that “As in Example 2, the claims recite a solution to a technology-based problem and not merely performance of a commercial practice on the internet”.
Examiner respectfully disagrees.
Analysis of subject matter eligibility is performed according to 2019 Revised Patent Subject Matter Eligibility Guidance which is integrated to the MPEP 2106. Analysis is shown that the claims recite the abstract idea grouped under “Certain methods of organizing human activity” (e.g., commercial interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
46. Applicant is also of the opinion that the claimed invention focused on the additional network functions recited in the claims such as generation, encryption, modification, and deployment of a preauthorized routing packet, that is similar to Example 42 of the Subject Matter Eligibility Examples: Abstract Ideas, which specific network functions such as conversion of records to a standardized format integrated the recited idea into a practical application.
Examiner respectfully disagrees.
In Example 42 additional elements integrated into a practical application because the system allows users to share information in real time that all received non-standardized information converted into the standardized format.
However, the claimed invention limitations “pairing the first payment instrument with a second payment instrument…; generating a preauthorized routing packet…; displaying selectable options…; encrypting the preauthorized routing packet…; deploying the QR code …; decrypting the preauthorized routing packet…; and rerouting the request …” are not integrated into a practical application. The claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claim is directed to the abstract idea.
The claims are not patent eligible.
Rejections under 35 U.S.C. § 112(b)
47. Rejection of claims 1, 8, and 15 based on “Lack of antecedent basis” due to amendments are withdrawn.
Conclusion
48. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20130110670A1 – Webber et al. – Discloses a method for monitoring, transmitting, and recording usage of a computer or mobile device connected to a network, the one or more programs including instructions for establishing a first account, the settings of the first account being stored in a database.
US10002348B1 – Doctor et al. – Discloses a payment routing and processing platform that configured to collect various attributes for use in identifying an optimal payment processor for a particular payment transaction message.
US20120265625A1 – Pletz et al. – Discloses a method and a system for implementing a card product or access mechanism with multiple relationships with an issuing entity, where each relationship may be defined by one or more sets of rules that are customized for a particular customer.
US20190087815A1 – Goldschmidt – Discloses methods, apparatus and systems for providing merchant quick response code services, wherein a digital enablement services computer receives a request for a merchant quick-response code from a merchant acquirer financial institution computer.
US20170053276A1 – Gullett et al. – Discloses systems and methods for transaction routing in accordance with embodiments of the invention, wherein a method for routing transactions includes obtaining transaction data using an account servicing server system.
49. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692 September 6, 2026
Prosecution Insights