DETAILED ACTION
Acknowledgements
This Final Office Action is in reply to Applicant’s response filed June 25, 2026.
Claims 1, 11 are currently amended.
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 .
Claim Rejections - 35 USC § 103
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.
Claims 1, 7, 9, 11, 12, 16-17, 20, 23-25, 27, 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 and the cryptogram […] wherein the resource provider computer thereafter generates an authorization request message comprising the transaction amount, the token, and the cryptogram […], 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, wherein the plan identifier is embedded within the cryptogram so that the authorization request message includes the plan identifier in the encrypted form without expanding a size of the authorization request message to include an additional field for the plan identifier, and the plan identifier is carried only within the cryptogram until decrypted by the network processing computer; {[0014] “the mobile device may generate a cryptogram including various data elements. These data elements and the cryptogram may be sent to a service provider computer associated with the service provider application.”}
See above step (e) regarding the inclusion of the plan identifier in the cryptogram.
(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, wherein the decrypting the cryptogram comprises determining the decrypted plan identifier embedded within the cryptogram; {[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 27
US Payments in view of Macedo in view of Gordon does not teach, however Le Saint teaches:
The method of claim 1, wherein the authorization request message is an ISO 8583 message, {[0067] “An authorization request message according to some embodiments may comply with 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.”} 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. {[0067] “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, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction. The authorization request message may also include other information such as information that identifies the access device that generated the authorization request message, information about the location of the access device, etc.”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to utilize the ISO 8583 authorization request message format of Le Saint for the modified authorization request message of US Payments in view of Macedo in view of Gordon, and to insert the decrypted plan identifier and the information about cryptogram integrity verification into message fields of the ISO 8583 message, because Le Saint teaches that an ISO 8583 authorization request message may include transaction information and other information utilized in determining whether to authorize a transaction. Doing so would allow the decrypted plan identifier and the information about cryptogram integrity verification, which are used in determining whether to authorize the interaction and the certain plan, to be communicated to the authorizing entity computer using a standardized authorization request message format.
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.
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 § 103
Claims 1 and 11
Applicant has amended independent claims 1 and 11 to include two new limitations. These limitations require that the plan identifier be embedded in the cryptogram so that the authorization request message size is not expanded and additionally require that the plan identifier be decrypted when the cryptogram is decrypted. Because the previous claim already required that the cryptogram “comprise” the plan identifier and that the cryptogram later be decrypted, this language does not meaningfully change the claim construction and the previous rejections are still applicable.
Applicant argues incorporating the plan identifier of Macedo into the cryptogram of Gordon is not taught by the art. Gordon teaches a cryptogram included in an authorization request and which “includ[es] various data elements”. It was asserted in the rejection that a person of ordinary skill in the art would immediately envisage that the plan identifier, which is a piece of data in the authorization request message, could be included in the cryptogram rather than in the message but not in the cryptogram.
Applicant disagrees and states that the motivation for embedding the plan identifier in the cryptogram is to save space in the message and that none of the cited references recognize this problem. However, the prior art does not need to teach any particular motivation for the claimed solution. Additionally, the desire to make the authorization request message as small as possible is common-sensical because it reduces bandwidth requirements. See MPEP 2144(II) “Because the desire to enhance commercial opportunities by improving a product or process is universal—and even common-sensical—we have held that there exists in these situations a motivation to combine prior art references even absent any hint of suggestion in the references themselves.”
It is further noted that, in addition to Gordon’s suggestion that “various data elements” can be included in the cryptogram, Le Saint also makes the same suggestion ([0197] “In some embodiments, the transaction cryptogram can also include transaction data (e.g., transaction amount, transaction date, etc.) and user/account details (e.g., a payment token, account expiration date, etc.) that are encrypted using the cryptogram key.”). The concept of including transaction data in the cryptogram therefore appears to be well-known.
Claim 27
Applicant argues the Examiner improperly relied on applicant’s own disclosure as admitted prior art to supply the ISO 8583 limitations related to message fields. However, the application’s reference to ISO 8583 as a standard is an acknowledgement that the standard existed at the time of the application’s filing. Additionally, it is noted that an ISO 8583 authorization request is also taught by both Gordon ([0029] “An authorization request message according to some embodiments may comply with 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.”) and Le Saint ([0067] “An authorization request message according to some embodiments may comply with 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.”). Le Saint further teaches [0067] “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, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction. The authorization request message may also include other information such as information that identifies the access device that generated the authorization request message, information about the location of the access device, etc.” which supports adding the plan identifier of Macedo and other authorization information to the message.
The previous rejection has been updated to remove the reliance on Applicant Admitted Prior Art in favor of the same teaching in Le Saint.
Conclusion
THIS ACTION IS MADE FINAL. 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 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 at (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
Prosecution Insights