DETAILED ACTION
Acknowledgements
This Non-Final Office Action is in reply to Applicant’s RCE filed November 10, 2025.
Claim 14 is currently cancelled. Claims 1, 11, 21, 27, 28 are currently amended. Claims 29-30 are new.
Claims 1, 7, 9, 11, 12, 16, 17, 20-25, 27-30 are currently pending.
Claims 1, 7, 9, 11, 12, 16, 17, 20-25, 27-30 have been examined.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on November 10, 2025 has been entered.
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:
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.
Claims 1, 7, 9, 11, 12, 16-17, 20, 23-25, 28, 30 are rejected under 35 U.S.C. 103 as being unpatentable over US Payments Forum: “EMV Payment Tokenization Primer and Lessons Learned” (1/17/23 IDS) in view of Macedo (US 20170193497 A1) in view of Gordon (US 20160241402 A1) in view of Le Saint (US 20160065370 A1).
Regarding claim 1
US Payments teaches:
A method comprising:
(a) receiving, via a network, by a user device from a resource provider computer operated by a resource provider, […] a transaction amount for an interaction, […], wherein the resource provider computer is a merchant computer; {page 26 “The cardholder verifies the amount and selects the token for payment. […] The payment token is sent to the merchant acquirer/processor [resource provider computer] in the authorization request [transaction amount].”}
(b) displaying, on the user device, a webpage of a website operated by the resource provider computer, […]; {page 23 “This section details the process flows for several of the following… Network pay button payments at e-commerce sites”}
(d) […] implementing predefined cryptographic algorithms, the encryption key being used for cryptographic protection […]; {page 10 “Cryptography protects information by transforming it into a format only readable by authorized entities. Cryptography is often used to secure sensitive information, such as a PIN, or to authenticate an entity, such as an issuer or cardholder.”}
(f) transmitting, by the user device to the resource provider computer via the network, a token […] wherein the resource provider computer, thereafter generates an authorization request message comprising the transaction amount, the token, […], and transmits, over the network to a network processing computer, the authorization request message; {Fig. 7 step 1 “The cardholder verifies the amount and selects the token for payment. The mobile wallet authenticates the user with a biometric factor, PIN or passcode, and returns a payment token with a cryptogram to the mobile application. The payment token is sent to the merchant acquirer/processor [resource provider computer] in the authorization request [transaction amount].”}
PNG
media_image1.png
284
622
media_image1.png
Greyscale
(g) receiving, by the network processing computer from the resource provider computer via the network, the authorization request message for the interaction; {Figure 7 step 2}
(j) detokenizing, by the network processing computer, the token to obtain a credential associated with the token; {Figure 7 steps 3 and 4}
(l) modifying, by the network processing computer, the authorization request message to include […] (3) the credential instead of the token; {Figure 7 step 5 “The payment network forwards the transaction with the clear PAN to the appropriate issuer processor.”}
(m) transmitting, by the network processing computer via the network, the modified authorization request message comprising […], the transaction amount, and the credential to an authorizing entity computer, {Figure 7 step 5 “The payment network forwards the transaction with the clear PAN to the appropriate issuer processor.”} the modified authorization request message being a request for the authorizing entity computer to authorize the interaction and the certain plan associated with the plan identifier based on at least the transaction amount and the information related to the verification of the cryptogram;
What the request is for is interpreted as an intended result not given patentable weight.
(n) receiving, by the network processing computer from the authorizing entity computer via the network, an authorization response message containing an indication that both the interaction and […] are authorized; {Figure 7 step 8 “The issuer processor sends the authorization response to the payment network.”}
(o) transmitting, by the network processing computer to the resource provider computer via the network, the authorization response message; {Figure 7 step 9 “The payment network sends the authorization response to the merchant acquirer/processor”}
(p) receiving, by the user device from the resource provider computer via the network, the authorization response message; and {Figure 7 step 10 “The merchant acquirer/processor responds to the mobile application with the transaction response.”}
(q) displaying, by the user device on the interactive graphical user interface, a webpage of the website operated by the resource provider computer including a message conveying the indication that both the interaction and […] are authorized. {Figure 7 step 10 “The merchant acquirer/processor responds to the mobile application with the transaction response.”; page 23 “This section details the process flows for several of the following… Network pay button payments at e-commerce sites”}
US Payments does not teach, however Macedo teaches the following bolded language:
(a) receiving, via a network, by a user device from a resource provider computer operated by a resource provider, one or more plan identifiers and a transaction amount for an interaction, each of the one or more plan identifiers being an alphanumeric string that identifies a particular plan, wherein the resource provider computer is a merchant computer; {[0013] “The client device 102 may be operated to interact with a merchant 104, such as, for example, over an Internet connection or the like. A user of the client device 102 may interact with a merchant website or merchant application to select one or more products or services to add to a shopping cart. When prompted with an option to checkout or complete the purchase, the user may select an option to checkout using a wallet pursuant to the present disclosure. The user may then be prompted to login to the user's wallet and select one or more payment options including, for example, the ability to select a payment card type from among credit, debit and combo-card. The wallet server will redirect the user to the merchant webpage to complete the transaction and, pursuant to some embodiments, may display one or more installment options [plan identifiers] to the user depending on the type of payment card selected as well as information associated with the merchant.”}
(b) displaying, on the user device, a webpage of a website operated by the resource provider computer, the webpage including the one or more plan identifiers presented in an interactive graphical user interface configured to enable a user selection; {Figure 5A}
PNG
media_image2.png
291
672
media_image2.png
Greyscale
(c) receiving, at the user device, an electronic signal corresponding to a user input through a button displayed in the interactive graphical user interface, the user input indicating a selection of a certain plan corresponding to a plan identifier among the one or more plan identifiers; {Figure 5A}
(d) generating, by the user device, an encryption key using at least a network processing computer public key and implementing predefined cryptographic algorithms, the encryption key being used for cryptographic protection of at least plan data associated with the certain plan; {[0014] “Pursuant to some embodiments, the authorization request includes information about one or more wallet or transaction options selected pursuant to the present disclosure (e.g., such as information specifying details of an installment plan selected by the user of the client device”}
(f) transmitting, by the user device to the resource provider computer via the network, a token and the cryptogram comprising, in an encrypted form, the plan identifier, the user device identifier, and the transaction amount wherein the resource provider computer, thereafter generates an authorization request message comprising the transaction amount, the token, and the cryptogram comprising, in the encrypted form, the plan identifier, the user device identifier, and the transaction amount, and transmits, over the network to a network processing computer, the authorization request message; {[0014] “Pursuant to some embodiments, the authorization request includes information about one or more wallet or transaction options selected pursuant to the present disclosure (e.g., such as information specifying details of an installment plan selected by the user of the client device”}
(l) modifying, by the network processing computer, the authorization request message to include (1) the decrypted plan identifier identifying the certain plan, (2) information related to the verification of the cryptogram, and (3) the credential instead of the token; {[0014] “Pursuant to some embodiments, the authorization request includes information about one or more wallet or transaction options selected pursuant to the present disclosure (e.g., such as information specifying details of an installment plan selected by the user of the client device”}
(m) transmitting, by the network processing computer via the network, the modified authorization request message comprising the information related to the verification of the cryptogram, the decrypted plan identifier identifying the certain plan, the transaction amount, and the credential to an authorizing entity computer, the modified authorization request message being a request for the authorizing entity computer to authorize the interaction and the certain plan associated with the plan identifier based on at least the transaction amount and the information related to the verification of the cryptogram; {[0014] “Pursuant to some embodiments, the authorization request includes information about one or more wallet or transaction options selected pursuant to the present disclosure (e.g., such as information specifying details of an installment plan selected by the user of the client device”}
(n) receiving, by the network processing computer from the authorizing entity computer via the network, an authorization response message containing an indication that both the interaction and the certain plan are authorized; {[0014] “Pursuant to some embodiments, the authorization request includes information about one or more wallet or transaction options selected pursuant to the present disclosure (e.g., such as information specifying details of an installment plan selected by the user of the client device”; [0015] “The authorization response generated by the payment card issuer server computer 112 may be routed back to the merchant 104 via the payment network 110 and the acquirer computer 108.”}
(q) displaying, by the user device on the interactive graphical user interface, a webpage of the website operated by the resource provider computer including a message conveying the indication that both the interaction and the certain plan are authorized. {[0014] “Pursuant to some embodiments, the authorization request includes information about one or more wallet or transaction options selected pursuant to the present disclosure (e.g., such as information specifying details of an installment plan selected by the user of the client device”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add the installment plan selection of Macedo to the tokenized authorization process of US Payments because it would allow merchants to sell to people who couldn’t otherwise afford to purchase, thereby broadening the pool of potential customers.
US Payments in view of Macedo does not teach, however Gordon teaches the following bolded language:
(e) generating, by the user device, a cryptogram by encrypting, with the encryption key, at least the plan identifier and additional data including the transaction amount and a user device identifier identifying the user device, wherein the cryptogram is generated for the interaction using interaction-specific data including the plan identifier, the transaction amount, and the user device identifier, such that the cryptogram is unique to the interaction and verifiable for integrity; {[0014] “the mobile device may generate a cryptogram including various data elements. These data elements may include, but are not limited to, a user identification (ID) associated with the user, a timestamp, a device ID associated with the mobile device, a service provider application ID associated with the service provider application, and a service provider device ID. These data elements and the cryptogram may be sent to a service provider computer associated with the service provider application.”; [0029] “An authorization request message may also comprise additional data elements corresponding to ‘identification information’ including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or ‘account number’), a payment token, a user name, an expiration date, etc. An authorization request message may also comprise ‘transaction information,’ such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction.”; [0006] “wherein the generated cryptogram was generated by a mobile device and encrypts the user ID, the timestamp, the device ID, and the service provider application ID. The method also includes decrypting, by the service provider, the received generated cryptogram.”}
Gordon does not explicitly teach encrypting the plan identifier and additional data including the transaction amount to generate a cryptogram. However, Gordon teaches encrypting a device identifier and “various data elements”, not limited to the ones explicitly mentioned, to generate a cryptogram. Gordon further teaches the potential data elements comprising any information associated with a current transaction. Therefore, one of ordinary skill in the art would immediately envisage that any combination of transaction data elements could be included, such as the transaction amount and installment plan. See MPEP 2131.02 Genus-Species Situations III.
(f) transmitting, by the user device to the resource provider computer via the network, a token and the cryptogram comprising, in an encrypted form, the plan identifier, the user device identifier, and the transaction amount wherein the resource provider computer, thereafter generates an authorization request message comprising the transaction amount, the token, and the cryptogram comprising, in the encrypted form, the plan identifier, the user device identifier, and the transaction amount, and transmits, over the network to a network processing computer, the authorization request message; {[0014] “These data elements and the cryptogram may be sent to a service provider computer associated with the service provider application.”}
(i) decrypting, by the network processing computer with the decryption key, the cryptogram to obtain a decrypted plan identifier, a decrypted user device identifier, and a decrypted transaction amount; {[0006] “The method also includes decrypting, by the service provider [network processing computer], the received generated cryptogram.”}
(k) verifying, by the network processing computer, the cryptogram for integrity by confirming that the decrypted user device identifier and the decrypted transaction amount respectively correspond to a stored user device identifier stored in a memory of the network processing computer and the transaction amount included in the authorization request message separately from the cryptogram; {[0006] “The method further includes verifying, by the service provider computer, the cryptogram by determining a plurality of data elements encoded within the cryptogram, and then comparing the determined plurality of data elements to the user ID, the timestamp, the device ID, the service provider application ID, and the service provider device ID received by the service provider computer.”}
(l) modifying, by the network processing computer, the authorization request message to include (1) the decrypted plan identifier identifying the certain plan, (2) information related to the verification of the cryptogram, and (3) the credential instead of the token; {Abstract “The service provider computer may decrypt the cryptogram”}
“Information related to the verification of the cryptogram” is not given patentable weight because it is merely a description of data which has no function in the claimed method. Additionally, “related” is interpreted consistent with its broadest reasonable interpretation and therefore the transaction amount and/or installment plan reads on this limitation.
(m) transmitting, by the network processing computer via the network, the modified authorization request message comprising the information related to the verification of the cryptogram, the decrypted plan identifier identifying the certain plan, the transaction amount, and the credential to an authorizing entity computer, the modified authorization request message being a request for the authorizing entity computer to authorize the interaction and the certain plan associated with the plan identifier based on at least the transaction amount and the information related to the verification of the cryptogram;
See explanation above with respect to the “modifying” step.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add the cryptogram of Gordon to the authorization request of US Payments in view of Macedo because it would provide security by confirming to the payment network that the mobile application is “communicating from the correct device and that they are being used by the correct user” [0002].
US Payments in view of Macedo in view of Gordon does not teach, however Le Saint teaches the following bolded language:
(d) generating, by the user device, an encryption key using at least a network processing computer public key and implementing predefined cryptographic algorithms, the encryption key being used for cryptographic protection of at least plan data associated with the certain plan; {Abstract “Embodiments of the invention introduce efficient methods for securely generating a cryptogram by a user device, and validating the cryptogram by a server computer. In some embodiments, a secure communication can be conducted whereby a user device provides a cryptogram without requiring the user device to persistently store an encryption key or other sensitive data used to generate the cryptogram. For example, the user device and server computer can mutually authenticate and establish a shared secret. Using the shared secret, the server computer can derive a session key and transmit key derivation parameters encrypted using the session key to the user device. The user device can also derive the session key [encryption key] using the shared secret”}
(h) generating, by the network processing computer, a decryption key corresponding to the network processing computer public key; {Abstract “Embodiments of the invention introduce efficient methods for securely generating a cryptogram by a user device, and validating the cryptogram by a server computer. In some embodiments, a secure communication can be conducted whereby a user device provides a cryptogram without requiring the user device to persistently store an encryption key or other sensitive data used to generate the cryptogram. For example, the user device and server computer [network processing computer] can mutually authenticate and establish a shared secret. Using the shared secret, the server computer can derive a session key and transmit key derivation parameters encrypted using the session key to the user device. The user device can also derive the session key [decryption key] using the shared secret”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use the key generation of Le Saint to generate the cryptogram encryption/decryption keys in the method of US Payments in view of Macedo in view of Gordon because it has the advantage that secure communication can be conducted “without requiring the user device to persistently store an encryption key or other sensitive data used to generate the cryptogram”.
Regarding claim 7
US Payments teaches:
The method of claim 1, wherein detokenizing the token to obtain the credential comprises:
providing, by the network processing computer, the token to a token provider computer, wherein the token provider computer determines the credential associated with the token; and {Fig. 7 step 3}
receiving, by the network processing computer, the credential from the token provider computer. {Fig. 7 step 4}
Regarding claim 9
US Payments teaches:
The method of claim 1 wherein detokenizing the token to obtain the credential comprises:
providing, by the network processing computer, the credential to a token provider computer, wherein the token provider computer determines the token associated with the credential; and
receiving, by the network processing computer, the token from the token provider computer. {page 9 Fig. 1 “Token Requestor […] Requests tokens for PANs [credential]”, “2. The token requestor [network processing computer] sends a provisioning request.”, “4. The token is generated.” and “Token Service Provider […] Acts as token delivery mechanism to Token requestor”}
Regarding claim 11
Claim 11 is substantially similar to claim 1 and is treated the same with respect to prior art rejections.
Regarding claim 12
US Payments teaches:
The system of claim 11, wherein the network processing computer further comprises a network interface coupled to the second processor. {Fig. 7 Payment Network}
Regarding claim 16
The system of claim 11 wherein the network processing computer further comprises, on the second computer readable medium: a communication module; and a plan processing module.
US Payments in view of Macedo, as discussed above, teaches a payment network which processes communications including installment plan identifiers. Therefore, the payment network of this method reads on including a communication module and a plan processing module.
Regarding claim 17
US Payments teaches:
The system of claim 11, wherein the credential comprises a PAN. {Fig. 7 step 4 “The TSP verifies the cryptogram and returns the clear PAN to the payment network.”}
Regarding claim 20
US Payments teaches:
The method of claim 1, wherein the user device is a mobile phone. {Fig. 7}
This limitation is not given any patentable weight because it does not change the claimed method in any way. However, it is taught by US Payments figure 7 because it shows a mobile phone.
Regarding claim 23
The method of claim 1, wherein the merchant computer is a merchant Web server.
The above is not a method step and does not affect any claimed method step and therefore is not given patentable weight.
Regarding claim 24
US Payments teaches:
The method of claim 23, wherein the merchant Web server has a checkout page with the transaction amount, which is displayed on the user device. {page 26 step 1 “The cardholder verifies the amount”}
The above is interpreted as a step of displaying, on the user device, the transaction amount. The user verifying the amount implies it is displayed to them.
Regarding claim 25
The method of claim 1, wherein the merchant computer is a POS terminal.
The above is not a method step and does not affect any claimed method step and therefore is not given patentable weight.
Regarding claim 28
Macedo teaches:
The method of claim 1, wherein the one or more plan identifiers are received by the resource provider from a service provider computer, wherein the service provider computer is selected by a user input using the interactive graphical user interface during the interaction, and {Figure 5B; [0035] “In some embodiments, this may be done by authorizing the wallet service provider computer [resource provider] 103 to contact the issuers [service provider] of the payment card accounts to initiate a process of loading the relevant account data into the user's digital wallet.”; [0042] “Pursuant to some embodiments, not all merchants or payment account issuers may support the user of installment payments.”}
PNG
media_image3.png
316
726
media_image3.png
Greyscale
This limitation is not given patentable weight because it does not claim a method step and no method steps are affected by it. However, it is implied by Macedo. Selecting the credit card in Fig. 5B reads on selecting the service provider because each credit card would have an associated issuer (service provider). Macedo teaches the wallet service provider computer (resource provider) receiving account data from the issuer which implicitly includes supported installment plans since installment payment support is determined based on who the payment account issuer is.
wherein the service provider computer is a wallet server computer.
The above is not a method step and does not affect any claimed method step and therefore is not given patentable weight.
Regarding claim 30
Le Saint teaches:
The method of claim 1, wherein the generating the encryption key further comprises performing a Diffie-Hellman key exchange between the user device and the network processing computer to derive a shared secret; and deriving the encryption key from the shared secret using a key derivation function. {[0044] “For example, a Diffie-Hellman based algorithm, such as Elliptic-Curve Diffie-Hellman (ECDH) may be used to generate a shared secret from a private key and a public key. In some cases, a shared secret may be used to generate a session key [encryption key].”}
The reasons for combining the encryption method of Le Saint with the authorization process of US Payments in view of Macedo in view of Gordon is given above with respect to claim 1.
Claim 27 is rejected under 35 U.S.C. 103 as being unpatentable over US Payments Forum: “EMV Payment Tokenization Primer and Lessons Learned” (1/17/23 IDS) in view of Macedo (US 20170193497 A1) in view of Gordon (US 20160241402 A1) in view of Le Saint (US 20160065370 A1) as applied to claim 1 above, and further in view of Applicant Admitted Prior Art.
Regarding claim 27
Applicant Admitted Prior Art teaches:
The method of claim 1, wherein the authorization request message is an ISO 8583 message, and wherein the modifying the authorization request message further comprises inserting the information about cryptogram integrity verification and the decrypted plan identifier into message fields of the ISO 8583 message. {[0032] “International Organization for Standardization (ISO) 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user using a payment device or payment account”}
The messages of US Payments need to have some format, and it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use an international standard.
Claims 21, 22, 29 are rejected under 35 U.S.C. 103 as being unpatentable over US Payments Forum: “EMV Payment Tokenization Primer and Lessons Learned” (1/17/23 IDS) in view of Macedo (US 20170193497 A1) in view of Gordon (US 20160241402 A1) in view of Le Saint (US 20160065370 A1) as applied to claim 1 above, and further in view of Wikipedia Base64.
Regarding claim 21
The method of claim 1, wherein the cryptogram is a TAVV cryptogram. {page 1 “In computer science, Base64 is a group of binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation. […] Common to all binary-to-text encoding schemes, Base64 is designed to carry data stored in binary formats across channels that only reliably support text content. Base64 is particularly prevalent on the World Wide Web”}
The above is interpreted as requiring that the cryptogram be a 20-byte Base64-encoded value.
Base64 teaches base64 is a well-known encoding type, and is commonly used on the web. Since US Payments teaches use of an e-commerce site, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use base64 encoding.
No cited reference explicitly teaches the cryptogram being 20 bytes long. However, the specific length of the cryptogram is deemed obvious because it doesn’t lead to any unexpected result and a person of ordinary skill in the art could immediately envisage any particular byte length of the cryptogram taught by Gordon. See MPEP 2144.04 IV. A. Changes in Size/Proportion.
Regarding claim 22
The method of claim 1, wherein the cryptogram is a 20-byte Base64-encoded value.
See claim 21.
Regarding claim 29
US Payments in view of Macedo in view of Gordon does not teach, however Le Saint teaches the following bolded text:
The method of claim 1, wherein the generating the cryptogram further comprises encrypting the plan identifier, the user device identifier, and the transaction amount into a 20-byte Base64-encoded value using a symmetric encryption algorithm.
See claim 1. Le Saint teaches deriving a session key based on a shared secret.
US Payments in view of Macedo in view of Gordon in view of Le Saint does not teach, however Base64 teaches the following bolded text:
The method of claim 1, wherein the generating the cryptogram further comprises encrypting the plan identifier, the user device identifier, and the transaction amount into a 20-byte Base64-encoded value using a symmetric encryption algorithm.
See claim 21 regarding the 20-byte Base64-encoded value.
Response to Arguments
35 USC § 112(b)
The rejection to claim 28 is withdrawn due to the amendment.
35 USC § 101
The 101 rejections are withdrawn in response to Applicant’s arguments.
Independent claim 1 contains the abstract ideas of authorizing a transaction, authorizing a payment plan, and tokenizing a payment credential, which are commercial interactions. However, the claim also contains the steps of “generating… a cryptogram by encrypting…”, “decrypting… the cryptogram…”, and “verifying…the cryptogram by comparing…”. These steps are not part of the abstract idea and are directed towards improving computer security. The abstract ideas are therefore integrated into a practical application.
Independent claim 11 is substantially similar to claim 1 and is treated the same. The remaining claims are all dependent on claims 1 or 11 and the rejections are withdrawn for the same reason.
35 USC § 103
Applicant submitted several arguments regarding why the cited art does not teach both the previously existing and newly amended claim limitations. However, the rejection has been significantly revised in response to Applicant’s amendments and arguments and all of Applicant’s arguments have been addressed.
The secondary references have all been replaced. The rejection is now over US Payments in view of Macedo in view of Gordon in view of Le Saint. US Payments teaches an authorization process using a tokenized credential. Macedo teaches the addition of an installment plan identifier to an authorization process. Gordon teaches the addition of a cryptogram which is generated by encrypting transaction data and verified by decrypting the cryptogram and comparing the contents to the transaction data included in the authorization request separately from the cryptogram. Le Saint also teaches a cryptogram and further teaches the claimed key generation steps used to encrypt and decrypt the cryptogram.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT MICHAEL DIROMA whose telephone number is (571)272-6430. The examiner can normally be reached Monday - Friday 12:30 pm - 8:30 pm.
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, Patrick McAtee can be reached on (571) 272-7575. 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.
/S.M.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698