CTNF 18/563,356 CTNF 100075 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Information Disclosure Statement The information disclosure statements (IDS) submitted on April 29, 2024 is being considered by the examiner. Status of the Claims This is a non-final rejection prepared in response to U.S. Patent Application 18/563,356 filed on June 4, 2024. Claims 1-20 are pending. Claims 21-23 are cancelled. Specification 06-16 AIA Applicant is reminded of the proper language and format for an abstract of the disclosure. The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details. The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided. The abstract of the disclosure is objected to because it exceeds the maximum count of 150 words. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b). Claim Objections 07-29-01 AIA Claim s 1, 4, 7 and 20 are objected to because of the following informalities: Claim 1 recites the limitation "the payment device" in line 2. There is insufficient antecedent basis for this limitation in the claim. Claim 4 recites the limitation "the authentication system" in line 5. There is insufficient antecedent basis for this limitation in the claim. Claim 7, the recited “an authorisation request message” on line 2 should be amended to “the authorization request message” as “an authorisation request message” was previously recited on claim 1. Claim 20, the recited “an authorisation system” on line 2 should be amended to “the authorization system” as “an authorization system” was previously recited on claim 17 . Appropriate correction is required. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Step 1: Claims 1-20 are directed to a method. Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II). Step 2A Prong One: Claim 13, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). A method at a payment device of generating data for verification during a transaction process between the payment device and a terminal, the method comprising: receiving, from the terminal, a request to generate cryptogram data for verification; generating a first digest over a plurality of transaction data items relating to the transaction process, the transaction data items being exchanged between the payment device and the terminal during the transaction process; generating a cryptogram unique to the transaction process, using the first digest and a subset of the plurality of transaction data items; generating a cryptogram response message containing the cryptogram, the first digest and the subset of transaction data items used to generate the cryptogram; and transmitting, to the terminal, the cryptogram response message. Claim 13, recites (i.e., sets forth or describes) a method for exchanging and verifying data between different parties. The claim achieves this by receiving a request to generate cryptogram from a first party, generating a first digest (hash) over received transaction data, generating the cryptogram utilizing the first digest and a subset of the transaction data received, generating a response message containing the first digest and a subset of the transaction data; and transmitting the cryptogram to a second party. As such the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas (i.e., fundamental economic practices and commercial or legal interactions). Claims 1 and 17 are similar to claim 13 but further includes the additional limitation of : generating, by the terminal, a second digest using a stored plurality of transaction data items exchanged between the payment device and the terminal during the transaction process; comparing, by the terminal, the first digest with the second digest; if the first digest matches the second digest, proceeding, by the terminal, with further authentication and subsequently generating an authorization request message for provision to an authorization system ; and if the first digest does not match the second digest, aborting, by the terminal, the transaction process. These additional limitations still recite an abstract idea under “certain methods of organizing human activity” grouping of abstract ideas (i.e., fundamental economic practices and commercial or legal interactions). Further, in regards to “generating a first digest over a plurality of transaction data items relating to the transaction process” in claim 1 and 13 and “generating, by the terminal, a second digest using a stored plurality of transaction data items exchanged between the payment device and the terminal during the transaction process” in claims 1 and 17 the examiner finds these to further recite an abstract idea as the recitations recite mental process using pen and paper and mathematical concept. Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to determine whether the claim recites additional elements that recite a practical application of the abstract ideas. Here, the additional elements of a payment device, a terminal and an authorization system merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas. Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Dependent Claims: Claims 2-12, 14-16 and 18-20 have also been analyzed for subject matter eligibility. However, claims 2-12, 14-16 and 18-20 also fail to recite patent eligible subject matter for the following reasons: Claims 2 and 14 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). the cryptogram response message includes an authorization data element containing proprietary information for provision by the terminal to the authorization system , and wherein generating the cryptogram response message comprises inserting, by the payment device, the first digest into a fixed location within the authorization data element The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of the terminal, the authorization system and payment device fail to recite a practical application or significantly more than the abstract idea because they merely serve as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Claim 3 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). comparing by the terminal , the first digest with the second digest, comprises extracting the first digest from the fixed location within the authorization data element. The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of the terminal fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Claims 4 and 18 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). the authorization request message comprises the cryptogram and the authorization data element containing the first digest, the method further comprising: verifying, by the authentication system, the cryptogram received in the authorization request message. The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of the authentication system to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Claims 5 and 15 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). identifying, by the payment device, one or more additional data items associated with the transaction process that are desired to be verified; and wherein generating the cryptogram response message comprises including, by the payment device, an envelope containing the one or more additional data items. The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of the payment device to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Claims 6 and 16 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). the plurality of transaction data items used to generate the first digest comprise at least a portion of the cryptogram response message including the envelope containing the one or more additional data items The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. Claim 7 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). generating, by the terminal, an authorization request message for provision to an authorization system comprises appending the envelope containing the one or more additional data items to the authorization request message. The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of an authorization system to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Claim 8 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). the one or more additional data items comprise one or more of the following: information regarding a biometric authentication of a user of the payment device; verification information and/or status of the user of the payment device; terminal risk management data; a verification decision relating to the user of the payment device; relay resistance data including one or more processing times associated with the transaction process; one or more characteristics of the payment device; one or more characteristics of the mechanism used for the payment transaction. The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. Claim 9 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). the plurality of transaction data items used to generate the first digest comprise static transaction data items and dynamic transaction data items. The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. Claim 10 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). the static transaction data items comprise a hash generated over data records associated with the payment device. The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. Claim 11 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). the payment device corresponds to a physical payment card; or to a mobile computing device comprising a digital wallet acting as a proxy for a digital payment card. The non-bolded additional element of a payment device to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Claim 12 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). the terminal corresponds to a mobile device having a payment processing application installed thereon. The non-bolded additional element of an authorization system to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Claim 19 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). the authorization request message further comprises an authorization data element containing proprietary information for provision by the terminal to the authorization system, and wherein the first digest is contained at a fixed location within the authorization data element. The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. Claim 20 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). the cryptogram response message comprises an envelope containing one or more additional data items associated with the transaction process that are desired to be verified by the payment device , and wherein generating an authorization request message for provision to an authorization system comprises appending the envelope containing the one or more additional data items to the authorization request message. The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of a payment device and an authorization system to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Claim Rejections - 35 USC § 102 07-07-aia AIA 07-07 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – 07-08-aia AIA (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. 07-12-aia AIA (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. 07-15 AIA Claim s 13-16 are rejected under 35 U.S.C. 102( a)(1) and (a)(2 ) as being anticipated by Wong (US 2021/0042753 A1) . Regarding claim 13, Wong discloses: Receiving, from the terminal, a request to generate cryptogram data for verification; (¶0008, generating, by the communication device, a transaction cryptogram using the LUK, and a signature using the signature key, and sending, to an access device, the transaction cryptogram and the signature to request access to a good or a service associated with the transaction. For an offline data authentication transaction, access to the good or service associated with the transaction can be granted based on authentication of the signature prior to verifying the transaction cryptogram. ¶0111, Once the mobile application of portable communication device 201 receives terminal transaction data 210, the mobile application may increment its Application Transaction Counter (ATC) and generate dynamic transaction processing information using at least some of the received terminal transaction data 210, and send a set of transaction processing information 212 including the generated dynamic transaction processing information to access device 260. The dynamic transaction processing information 212 returned to access device 260 may include a transaction cryptogram generated using the LUK. For an ODA transaction, portable communication device 201 may also need to generate a signature based on at least some of the received terminal transaction data 210. “A cryptogram is generated based on the data/request received from the access device” ) generating a first digest over a plurality of transaction data items relating to the transaction process, the transaction data items being exchanged between the payment device and the terminal during the transaction process; (¶0122, In some embodiments, the signature may have been generated by applying a signing function to a hash value of at least some of the terminal transaction data 210 provided from access device 260 to portable communication device 201. ¶0153, In addition to being used in transaction cryptogram generation, in some embodiments, the LUK can be used to generate an authentication code when the mobile application communicates with the other components or entities of the cloud-based transaction system. For example, an authentication code or hash code can be generated over the transaction verification log details using the LUK as a key during the account parameters replenishment process. ¶0164, Process 600 may begin by generating a hash value 606 by applying a hash function 604 over dynamic transaction data 602. The dynamic transaction data 602 may include, for example, at least some or all of the terminal transaction data 310 provided from the access device to the mobile application of the portable communication device during execution of the transaction. In some embodiments, the dynamic transaction data 602 may include the terminal transaction data such as a terminal unpredictable number, an amount authorizes, and a transaction currency code, and/or card authentication related data. The card authentication related data may include a data authentication version number, a communication device unpredictable number, and transaction qualifiers. Additional data elements that can be included as the input to hash function 604 may also include the following data elements: a signed data format indicating the format of the signature being generated, a hash algorithm indicator indicating the hash function being used, communication device dynamic data (e.g., application transaction counter (ATC)) and length of the dynamic data, and/or a suitable padding pattern suitable for the hash function 604. Hash function 604 can be a secure hash algorithm (SHA) function such as SHA-1 or other variants, or a message digest algorithm (MD) such as MD5 or other variants. ¶0165, Once the hash value 606 has been generated, the signature 612 for the ODA transaction can be generated applying a signing function 610 using the signature key 608 to at least the hash value 606. ¶0172, In some embodiments, the communication device may receive terminal transaction data from the access device, and generating the signature may include generating a hash value over at least a portion of the terminal transaction data, and applying a signing function with the signature key to at least the hash value.) generating a cryptogram unique to the transaction process, using the first digest and a subset of the plurality of transaction data items; (¶0008, The process may further include generating, by the communication device, a transaction cryptogram using the LUK, and a signature using the signature key… ¶0153, With respect to the transaction cryptogram, in some embodiments, the input data used to generate the transaction cryptogram may include dynamic data (e.g., data that changes for each transaction) received from the contactless reader of an access device during the transaction (e.g., terminal transaction data). ¶0162, The transaction cryptogram 520 may be generated by encrypting dynamic transaction data 516 using the LUK 514 as an encryption key in encryption function 518. The dynamic transaction data 516 may include, for example, some or all of the terminal transaction data 310 provided from the access device to the mobile application of the portable communication device during execution of the transaction. ¶0172, At block 806, the communication device may generate a transaction cryptogram using the LUK and a signature using the signature key.) generating a cryptogram response message containing the cryptogram, the first digest and the subset of transaction data items used to generate the cryptogram; (¶0173, In some embodiments, the transaction cryptogram and the signature can be sent to the access device in the same communication. See Fig 2A 212) transmitting, to the terminal, the cryptogram response message. (¶0008, sending, to an access device, the transaction cryptogram and the signature to request access to a good or a service associated with the transaction. ¶0089, For example, in some embodiments, an account identifier or token, and additional information (e.g., a transaction cryptogram, account parameters, etc.) can be transmitted to access device 160 in APDU responses that are responsive to a series of APDU commands received from access device 160. ¶0111, The dynamic transaction processing information 212 returned to access device 260 may include a transaction cryptogram generated using the LUK. ¶0112, The transaction processing information 212 can be sent in the form of a GPO response to access device 260. . The transaction processing information 212 may include a transaction cryptogram dynamically generated using the LUK as indicated above, track-2 equivalent data, and addition data such as issuer application data (IAD), form factor indicator (FFI), card transaction qualifiers (CTQ), cryptogram information data (CID), the updated ATC, and/or an application PAN sequence number (PSN). ¶0173, At block 808, the communication device may send the transaction cryptogram and the signature to the access device to request access to a good or service associated with the transaction. See fig 2A 210-212.) Furthermore, the claimed limitation “the transaction data items being exchanged between the payment device and the terminal during the transaction process” only describe characteristics of the transaction data items which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics. Regarding claim 14, the combination of Wong and Mizuno discloses: the cryptogram response message includes an authorisation data element containing proprietary information for provision by the terminal to the authorisation system, and wherein generating the cryptogram response message comprises inserting, by the payment device, the first digest into a fixed location within the authorisation data element. (Wong ¶0164, Process 600 may begin by generating a hash value 606 by applying a hash function 604 over dynamic transaction data 602. The dynamic transaction data 602 may include, for example, at least some or all of the terminal transaction data 310 provided from the access device to the mobile application of the portable communication device during execution of the transaction. In some embodiments, the dynamic transaction data 602 may include the terminal transaction data such as a terminal unpredictable number, an amount authorizes, and a transaction currency code, and/or card authentication related data. The card authentication related data may include a data authentication version number, a communication device unpredictable number, and transaction qualifiers. Additional data elements that can be included as the input to hash function 604 may also include the following data elements: a signed data format indicating the format of the signature being generated, a hash algorithm indicator indicating the hash function being used, communication device dynamic data (e.g., application transaction counter (ATC)) and length of the dynamic data, and/or a suitable padding pattern suitable for the hash function 604. Hash function 604 can be a secure hash algorithm (SHA) function such as SHA-1 or other variants, or a message digest algorithm (MD) such as MD5 or other variants. ¶0165, Once the hash value 606 has been generated, the signature 612 for the ODA transaction can be generated applying a signing function 610 using the signature key 608 to at least the hash value 606. For example, the input data elements to the signing function 610 may include a data header, a signed data format indicating the format of the signature being generated, a hash algorithm indicator indicating the hash function being used, communication device dynamic data (e.g., application transaction counter (ATC)) and length of the dynamic data, a suitable padding pattern, hash value 606, and a data trailer. “authorization data element i.e. signature” ) Further, the claimed limitation “…containing proprietary information…” is non-functional material that does not move to distinguish over prior art. Furthermore, the claimed limitation “for…” in “the cryptogram response message includes an authorisation data element containing proprietary information for provision by the terminal to the authorisation system” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution. Regarding claim 15, the combination of Wong and Mizuno further disclose: identifying, by the payment device, one or more additional data items associated with the transaction process that are desired to be verified; and wherein generating the cryptogram response message comprises including, by the payment device, an envelope containing the one or more additional data items. (Wong ¶0173, In some embodiments, the communication device may also send a token (e.g., a substitute for an account identifier) instead of a real account identifier to the access device for the transaction. ¶0174, The communication device may also send, to the access device, a communication device public key certificate including a communication device public key that is used to authenticate the signature, a certificate authority public key index, and an issuer public key certificate. The certificate authority public key index can be used by the access device to identify a proper certificate authority public key to authenticate the issuer public key certificate, and the issuer public key certificate may include an issuer public key that is used to authenticate the communication device public key certificate. The communication device may also send a token (e.g., a substitute for an account identifier) instead of a real account identifier to the access device for the transaction.) Regarding claim 16, the combination of Wong and Mizuno further disclose: the plurality of transaction data items used to generate the first digest comprise at least a portion of the cryptogram response message including the envelope containing the one or more additional data item (Wong ¶0164, Process 600 may begin by generating a hash value 606 by applying a hash function 604 over dynamic transaction data 602. The dynamic transaction data 602 may include, for example, at least some or all of the terminal transaction data 310 provided from the access device to the mobile application of the portable communication device during execution of the transaction. In some embodiments, the dynamic transaction data 602 may include the terminal transaction data such as a terminal unpredictable number, an amount authorizes, and a transaction currency code, and/or card authentication related data. The card authentication related data may include a data authentication version number, a communication device unpredictable number, and transaction qualifiers. Additional data elements that can be included as the input to hash function 604 may also include the following data elements: a signed data format indicating the format of the signature being generated, a hash algorithm indicator indicating the hash function being used, communication device dynamic data (e.g., application transaction counter (ATC)) and length of the dynamic data, and/or a suitable padding pattern suitable for the hash function 604.) Further, the claimed limitation “wherein the plurality of transaction data items used to generate the first digest comprise at least a portion of the cryptogram response message including the envelope containing the one or more additional data item” only describe characteristics of the plurality of transaction data items which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics . Claim Rejections - 35 USC § 103 07-20-aia AIA The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 07-21-aia AIA Claim s 1-12 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Wong (US 2021/0042753 A1) in view of Mizuno (US 20060259786 A1) . Regarding claim 1, Wong discloses: providing, by the terminal to the payment device, a request to generate cryptogram data for verification; (¶0008, generating, by the communication device, a transaction cryptogram using the LUK, and a signature using the signature key, and sending, to an access device, the transaction cryptogram and the signature to request access to a good or a service associated with the transaction. For an offline data authentication transaction, access to the good or service associated with the transaction can be granted based on authentication of the signature prior to verifying the transaction cryptogram. ¶0111, Once the mobile application of portable communication device 201 receives terminal transaction data 210, the mobile application may increment its Application Transaction Counter (ATC) and generate dynamic transaction processing information using at least some of the received terminal transaction data 210, and send a set of transaction processing information 212 including the generated dynamic transaction processing information to access device 260. The dynamic transaction processing information 212 returned to access device 260 may include a transaction cryptogram generated using the LUK. For an ODA transaction, portable communication device 201 may also need to generate a signature based on at least some of the received terminal transaction data 210. “A cryptogram is generated based on the data/request received from the access device” ) generating, by the payment device, a first digest over a plurality of transaction data items relating to the transaction process, the transaction data items being exchanged between the payment device and the terminal during the transaction process; (¶0122, In some embodiments, the signature may have been generated by applying a signing function to a hash value of at least some of the terminal transaction data 210 provided from access device 260 to portable communication device 201. ¶0153, In addition to being used in transaction cryptogram generation, in some embodiments, the LUK can be used to generate an authentication code when the mobile application communicates with the other components or entities of the cloud-based transaction system. For example, an authentication code or hash code can be generated over the transaction verification log details using the LUK as a key during the account parameters replenishment process. ¶0164, Process 600 may begin by generating a hash value 606 by applying a hash function 604 over dynamic transaction data 602. The dynamic transaction data 602 may include, for example, at least some or all of the terminal transaction data 310 provided from the access device to the mobile application of the portable communication device during execution of the transaction. In some embodiments, the dynamic transaction data 602 may include the terminal transaction data such as a terminal unpredictable number, an amount authorizes, and a transaction currency code, and/or card authentication related data. The card authentication related data may include a data authentication version number, a communication device unpredictable number, and transaction qualifiers. Additional data elements that can be included as the input to hash function 604 may also include the following data elements: a signed data format indicating the format of the signature being generated, a hash algorithm indicator indicating the hash function being used, communication device dynamic data (e.g., application transaction counter (ATC)) and length of the dynamic data, and/or a suitable padding pattern suitable for the hash function 604. Hash function 604 can be a secure hash algorithm (SHA) function such as SHA-1 or other variants, or a message digest algorithm (MD) such as MD5 or other variants. ¶0165, Once the hash value 606 has been generated, the signature 612 for the ODA transaction can be generated applying a signing function 610 using the signature key 608 to at least the hash value 606. ¶0172, In some embodiments, the communication device may receive terminal transaction data from the access device, and generating the signature may include generating a hash value over at least a portion of the terminal transaction data, and applying a signing function with the signature key to at least the hash value.) generating, by the payment device, a cryptogram unique to the transaction process, using the first digest and a subset of the plurality of transaction data items; (¶0008, The process may further include generating, by the communication device, a transaction cryptogram using the LUK, and a signature using the signature key… ¶0153, With respect to the transaction cryptogram, in some embodiments, the input data used to generate the transaction cryptogram may include dynamic data (e.g., data that changes for each transaction) received from the contactless reader of an access device during the transaction (e.g., terminal transaction data). ¶0162, The transaction cryptogram 520 may be generated by encrypting dynamic transaction data 516 using the LUK 514 as an encryption key in encryption function 518. The dynamic transaction data 516 may include, for example, some or all of the terminal transaction data 310 provided from the access device to the mobile application of the portable communication device during execution of the transaction. ¶0172, At block 806, the communication device may generate a transaction cryptogram using the LUK and a signature using the signature key.) generating, by the payment device, a cryptogram response message containing the cryptogram, the first digest and the subset of transaction data items used to generate the cryptogram; (¶0173, In some embodiments, the transaction cryptogram and the signature can be sent to the access device in the same communication. See Fig 2A 212) transmitting, by the payment device, the cryptogram response message to the terminal; (¶0008, sending, to an access device, the transaction cryptogram and the signature to request access to a good or a service associated with the transaction. ¶0089, For example, in some embodiments, an account identifier or token, and additional information (e.g., a transaction cryptogram, account parameters, etc.) can be transmitted to access device 160 in APDU responses that are responsive to a series of APDU commands received from access device 160. ¶0111, The dynamic transaction processing information 212 returned to access device 260 may include a transaction cryptogram generated using the LUK. ¶0112, The transaction processing information 212 can be sent in the form of a GPO response to access device 260. . The transaction processing information 212 may include a transaction cryptogram dynamically generated using the LUK as indicated above, track-2 equivalent data, and addition data such as issuer application data (IAD), form factor indicator (FFI), card transaction qualifiers (CTQ), cryptogram information data (CID), the updated ATC, and/or an application PAN sequence number (PSN). ¶0173, At block 808, the communication device may send the transaction cryptogram and the signature to the access device to request access to a good or service associated with the transaction. See fig 2A 210-212.) comparing, by the terminal, the first digest with the second digest; if the first digest matches the second digest, proceeding, by the terminal, with further authentication and subsequently generating an authorisation request message for provision to an authorisation system; and if the first digest does not match the second digest, aborting, by the terminal, the transaction process. (¶0181, At block 918, the access device authenticates the signature based on the communication device public key associated with the communication device. For example, authenticating the signature may include deciphering the signature using the communication device public key to obtain a hash value, and comparing the hash value against an access device hash value computed by the access device. In some embodiments, the hash value included in the signature can be computed over at least some of the terminal transaction data provided to the communication device from the access device.) Wong does not explicitly disclose, however Mizuno teaches: generating, by the terminal, a second digest using a stored plurality of transaction data items exchanged between the payment device and the terminal during the transaction process; (¶0035, the comparison unit 204 calculates a hash value 1 after a plain text has been input to the comparison unit 204 at step 301 and calculates a hash value 2 from a decrypted text at step 303. Then, the hash value 1 is compared with the hash value 2 at step 304. ¶0040, In this case, the same as in the encryption process, comparison with the use of hash values may be carried out. When applied to the flowchart of decryption process of FIG. 4, after a cryptogram is input to the comparison unit 204 at step 401, the comparison unit 204 calculates a hash value 1 and calculates a hash value 2 from the cryptogram at step 403 and then compares the hash value 1 and the hash value 2 at step 404. Then, MP 100 checks the result of comparison at step 405.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the disclosure of Wong by further incorporating Mizuno’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to verify that the previously exchanged data remains consistent and has not been altered before transferring it to the authentication system. Further, the claimed limitation “for…” in “…subsequently generating an authorisation request message for provision to an authorisation system” consist of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution. Furthermore, the claimed limitation “the transaction data items being exchanged between the payment device and the terminal during the transaction process” only describe characteristics of the transaction data items which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics. Finally, the claim limitations “if the first digest matches the second digest, proceeding, by the terminal, with further authentication and subsequently generating an authorisation request message for provision to an authorisation system;” and “if the first digest does not match the second digest, aborting, by the terminal, the transaction process.” are conditional limitations which means that the claim limitations are only required when the stated conditions are met. Regarding claim 2, the combination of Wong and Mizuno discloses: the cryptogram response message includes an authorisation data element containing proprietary information for provision by the terminal to the authorisation system, and wherein generating the cryptogram response message comprises inserting, by the payment device, the first digest into a fixed location within the authorisation data element. (Wong ¶0164, Process 600 may begin by generating a hash value 606 by applying a hash function 604 over dynamic transaction data 602. The dynamic transaction data 602 may include, for example, at least some or all of the terminal transaction data 310 provided from the access device to the mobile application of the portable communication device during execution of the transaction. In some embodiments, the dynamic transaction data 602 may include the terminal transaction data such as a terminal unpredictable number, an amount authorizes, and a transaction currency code, and/or card authentication related data. The card authentication related data may include a data authentication version number, a communication device unpredictable number, and transaction qualifiers. Additional data elements that can be included as the input to hash function 604 may also include the following data elements: a signed data format indicating the format of the signature being generated, a hash algorithm indicator indicating the hash function being used, communication device dynamic data (e.g., application transaction counter (ATC)) and length of the dynamic data, and/or a suitable padding pattern suitable for the hash function 604. Hash function 604 can be a secure hash algorithm (SHA) function such as SHA-1 or other variants, or a message digest algorithm (MD) such as MD5 or other variants. ¶0165, Once the hash value 606 has been generated, the signature 612 for the ODA transaction can be generated applying a signing function 610 using the signature key 608 to at least the hash value 606. For example, the input data elements to the signing function 610 may include a data header, a signed data format indicating the format of the signature being generated, a hash algorithm indicator indicating the hash function being used, communication device dynamic data (e.g., application transaction counter (ATC)) and length of the dynamic data, a suitable padding pattern, hash value 606, and a data trailer. “authorization data element i.e. signature” ) Further, the claimed limitation “…containing proprietary information…” is non-functional material that does not move to distinguish over prior art. Furthermore, the claimed limitation “for…” in “the cryptogram response message includes an authorisation data element containing proprietary information for provision by the terminal to the authorisation system” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution. Regarding claim 3, the combination of Wong and Mizuno disclose: comparing by the terminal, the first digest with the second digest, comprises extracting the first digest from the fixed location within the authorisation data element. (¶0181, For example, authenticating the signature may include deciphering the signature using the communication device public key to obtain a hash value, and comparing the hash value against an access device hash value computed by the access device. In some embodiments, the hash value included in the signature can be computed over at least some of the terminal transaction data provided to the communication device from the access device.) Regarding claims 4 and 18, the combination of Wong and Mizuno further discloses: the authorisation request message comprises the cryptogram and the authorisation data element containing the first digest, the method further comprising: (Wong ¶0033, The authorization request message may include information that can be used to identify an account. An authorization request message may also comprise additional data elements such as one or more of a service code, 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, 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. ¶0089, Access device 160 or a merchant computer coupled to access device 160 may then generate an authorization request message including the account identifier or token, and additional information such as a transaction cryptogram and other transaction data, and forward the authorization request message to acquirer 174 associated with the merchant. The authorization request message can then be sent by acquirer 174 to payment processing network 194. verifying, by the authentication system, the cryptogram received in the authorisation request message. (Wong ¶0091, Upon receiving the authorization request message, payment processing network 194 may forward the authorization request message received from acquirer 174 to the corresponding issuer/host system 172 of the account of the user of portable communication device 101. After issuer/host system 172 receives the authorization request message, the authorization request message may be parsed, and the information in the authorization request message may be verified. For example, issuer/host system 172 may verify that the transaction cryptogram was generated by a valid LUK, and that the set of one or more limited-use thresholds associated with the LUK has not been exceeded. ¶0094, At some time after the transaction, access device 160 may send an authorization request message to obtain authorization for the transaction from issuer/host system 172. ¶0124, According to some embodiments, some or all of the data elements in the transaction processing information 212 and account data transmissions can be used by access device 260 to generate a transaction authorization request message. At a later time (e.g., when access device 260 establishes network connectivity) after the user has been granted access to a good or service based on authentication of the signature, access device 260 may route the authorization request message to request authorization of the transaction from the issuer. For example, in some embodiments, the authorization request message may include at least the track-2 equivalent data and the transaction cryptogram generated with the LUK, and the transaction can be authorized based on at least verifying that the transaction cryptogram was generated correctly and that the LUK used in generation of the transaction cryptogram has not exhausted the LUK's set of one or more limited use thresholds.) Regarding claim 5, the combination of Wong and Mizuno further disclose: identifying, by the payment device, one or more additional data items associated with the transaction process that are desired to be verified; and wherein generating the cryptogram response message comprises including, by the payment device, an envelope containing the one or more additional data items. (Wong ¶0173, In some embodiments, the communication device may also send a token (e.g., a substitute for an account identifier) instead of a real account identifier to the access device for the transaction. ¶0174, The communication device may also send, to the access device, a communication device public key certificate including a communication device public key that is used to authenticate the signature, a certificate authority public key index, and an issuer public key certificate. The certificate authority public key index can be used by the access device to identify a proper certificate authority public key to authenticate the issuer public key certificate, and the issuer public key certificate may include an issuer public key that is used to authenticate the communication device public key certificate. The communication device may also send a token (e.g., a substitute for an account identifier) instead of a real account identifier to the access device for the transaction.) Regarding claim 6, the combination of Wong and Mizuno further disclose: the plurality of transaction data items used to generate the first digest comprise at least a portion of the cryptogram response message including the envelope containing the one or more additional data item (Wong ¶0164, Process 600 may begin by generating a hash value 606 by applying a hash function 604 over dynamic transaction data 602. The dynamic transaction data 602 may include, for example, at least some or all of the terminal transaction data 310 provided from the access device to the mobile application of the portable communication device during execution of the transaction. In some embodiments, the dynamic transaction data 602 may include the terminal transaction data such as a terminal unpredictable number, an amount authorizes, and a transaction currency code, and/or card authentication related data. The card authentication related data may include a data authentication version number, a communication device unpredictable number, and transaction qualifiers. Additional data elements that can be included as the input to hash function 604 may also include the following data elements: a signed data format indicating the format of the signature being generated, a hash algorithm indicator indicating the hash function being used, communication device dynamic data (e.g., application transaction counter (ATC)) and length of the dynamic data, and/or a suitable padding pattern suitable for the hash function 604.) Further, the claimed limitation “wherein the plurality of transaction data items used to generate the first digest comprise at least a portion of the cryptogram response message including the envelope containing the one or more additional data item” only describe characteristics of the plurality of transaction data items which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics. Regarding claim 7, the combination of Wong and Mizuno further discloses: generating, by the terminal, an authorisation request message for provision to an authorisation system comprises appending the envelope containing the one or more additional data items to the authorisation request message. (Wong ¶0173, In some embodiments, the communication device may also send a token (e.g., a substitute for an account identifier) instead of a real account identifier to the access device for the transaction. ¶0174, The communication device may also send, to the access device, a communication device public key certificate including a communication device public key that is used to authenticate the signature, a certificate authority public key index, and an issuer public key certificate. The certificate authority public key index can be used by the access device to identify a proper certificate authority public key to authenticate the issuer public key certificate, and the issuer public key certificate may include an issuer public key that is used to authenticate the communication device public key certificate. The communication device may also send a token (e.g., a substitute for an account identifier) instead of a real account identifier to the access device for the transaction.) Regarding claim 8, the combination of Wong and Mizuno further discloses: the one or more additional data items comprise one or more of the following: information regarding a biometric authentication of a user of the payment device; verification information and/or status of the user of the payment device; terminal risk management data; a verification decision relating to the user of the payment device; relay resistance data including one or more processing times associated with the transaction process; one or more characteristics of the payment device; one or more characteristics of the mechanism used for the payment transaction. (Wong ¶0162, The dynamic transaction data 516 may include, for example, some or all of the terminal transaction data 310 provided from the access device to the mobile application of the portable communication device during execution of the transaction. In some embodiments, the dynamic transaction data 516 may include the following data elements: authorized amount, other amount, terminal country code, terminal verification results, transaction currency code, transaction date, transaction type, and unpredictable number; and/or may include the application interchange profile (AIP), application transaction counter (ATC), and issuer application data (IAD). In some embodiments, some data elements may be omitted, and/or additional data elements not specifically described can be included. ¶0164, The dynamic transaction data 602 may include, for example, at least some or all of the terminal transaction data 310 provided from the access device to the mobile application of the portable communication device during execution of the transaction. In some embodiments, the dynamic transaction data 602 may include the terminal transaction data such as a terminal unpredictable number, an amount authorizes, and a transaction currency code, and/or card authentication related data. The card authentication related data may include a data authentication version number, a communication device unpredictable number, and transaction qualifiers. Additional data elements that can be included as the input to hash function 604 may also include the following data elements: a signed data format indicating the format of the signature being generated, a hash algorithm indicator indicating the hash function being used, communication device dynamic data (e.g., application transaction counter (ATC)) and length of the dynamic data, and/or a suitable padding pattern suitable for the hash function 604.) Further, the claimed limitation “wherein the one or more additional data items comprise one or more of the following: information regarding a biometric authentication of a user of the payment device;…” only describe characteristics of the one or more additional data items which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics. Regarding claim 9, the combination of Wong and Mizuno further disclose: the plurality of transaction data items used to generate the first digest comprise static transaction data items and dynamic transaction data items. (Wong ¶0128, The transaction cryptogram embedded in the track-2 equivalent data may be a cryptogram generated by using the LUK as an encryption key. In some embodiments, the transaction cryptogram that is embedded in the track-2 equivalent data may be different than the transaction cryptogram that is provided in the transaction processing information 312 (e.g., GPO response). For example, the transaction cryptogram embedded in the track-2 equivalent data (may be referred to as a “decimalized transaction cryptogram”) may have a reduced-length (e.g., reduced to six digits), and/or may be generated by encrypting a static data (e.g., a predetermined numeric string) instead of terminal transaction data. ¶0162, The transaction cryptogram 520 may be generated by encrypting dynamic transaction data 516 using the LUK 514 as an encryption key in encryption function 518.) Regarding claim 10, the combination of Wong and Mizuno further disclose: the static transaction data items comprise a hash generated over data records associated with the payment device. (Wong ¶0037, “Account parameters” may refer to information relating to an account that can be used to conduct a transaction on the account. Examples of account parameters may include information that can be used to identify an account of the user (e.g., real account identifier, alternate account identifier, token, etc.), data or information relating to the status of the account, one or more keys that are used to generate cryptographic information, data or information relating to the one or more keys, etc. An account parameter can be semi-static or dynamic. A dynamic account parameter may be an account parameter that has a limited lifespan, and which once expired, can no longer be used to conduct a transaction until the account parameter is replenished, refreshed, or renewed. A dynamic account parameter may be replenished frequently during the lifetime of an account. A semi-static account parameter may be an account parameter that has an extended lifespan that is longer than a dynamic account parameter, and can be replenished less frequently than a dynamic account parameter or not at all during the lifetime of the account. ¶0153, With respect to the transaction cryptogram, in some embodiments, the input data used to generate the transaction cryptogram may include dynamic data (e.g., data that changes for each transaction) received from the contactless reader of an access device during the transaction (e.g., terminal transaction data). In addition to being used in transaction cryptogram generation, in some embodiments, the LUK can be used to generate an authentication code when the mobile application communicates with the other components or entities of the cloud-based transaction system. For example, an authentication code or hash code can be generated over the transaction verification log details using the LUK as a key during the account parameters replenishment process.) Regarding claim 11, the combination of Wong and Mizuno further disclose: the payment device corresponds to a physical payment card; or to a mobile computing device comprising a digital wallet acting as a proxy for a digital payment card. (Wong ¶0027, A portable communication device may be in the form of a mobile device such as a mobile phone (e.g., smart phone, cellular phone, etc.), tablets, portable media player, personal digital assistant devices (PDAs), wearable computing device (e.g., watch), electronic reader device, etc., or in the form of a card (e.g., smart card) or a fob, etc. Examples of portable communication devices may also include portable computing devices (e.g., laptops, netbooks, ultrabooks, etc.). A portable communication device may also be in the form of a vehicle (e.g., an automobile such as car) equipped with communication capabilities. ¶0087, In secure element based implementations, a contactless application (e.g., a mobile wallet or payment application for contactless transactions) using a contactless interface to communicate with a contactless reader of an access device would have to be coded for and be executed on a secure element in order to gain access to the contactless interface. ¶0105, The communications can be carried out between a mobile application running on portable communication device 201 and a contactless reader of access device 260. ¶0116, The consumer payment device form factor may indicate that portable communication device 201 is a standard card (e.g., ID-1 card type as specified in ISO 7811), a mini-card, a non-card form factor (e.g., key fob, watch, wristband, ring, sticker, etc.), or a mobile phone.) Regarding claim 12, the combination of Wong and Mizuno further disclose: the terminal corresponds to a mobile device having a payment processing application installed thereon. (Wong ¶0032, An access device may be in any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, Websites, and the like. ¶0105, The communications can be carried out between a mobile application running on portable communication device 201 and a contactless reader of access device 260.) Regarding claim 17, Wong discloses: transmitting, to the payment device, a request to generate cryptogram data for verification; (¶0008, generating, by the communication device, a transaction cryptogram using the LUK, and a signature using the signature key, and sending, to an access device, the transaction cryptogram and the signature to request access to a good or a service associated with the transaction. For an offline data authentication transaction, access to the good or service associated with the transaction can be granted based on authentication of the signature prior to verifying the transaction cryptogram. ¶0111, Once the mobile application of portable communication device 201 receives terminal transaction data 210, the mobile application may increment its Application Transaction Counter (ATC) and generate dynamic transaction processing information using at least some of the received terminal transaction data 210, and send a set of transaction processing information 212 including the generated dynamic transaction processing information to access device 260. The dynamic transaction processing information 212 returned to access device 260 may include a transaction cryptogram generated using the LUK. For an ODA transaction, portable communication device 201 may also need to generate a signature based on at least some of the received terminal transaction data 210. “A cryptogram is generated based on the data/request received from the access device” ) receiving, from the payment device, a cryptogram response message containing:(i) a first digest generated over a plurality of transaction data items relating to the transaction process, the transaction data items being exchanged between the payment device and the terminal during the transaction process, (ii) a cryptogram unique to the transaction process, generated using the first digest and a subset of the plurality of transaction data items, and (iii) the subset of transaction data items used to generate the cryptogram; (¶0008, sending, to an access device, the transaction cryptogram and the signature to request access to a good or a service associated with the transaction. ¶0089, For example, in some embodiments, an account identifier or token, and additional information (e.g., a transaction cryptogram, account parameters, etc.) can be transmitted to access device 160 in APDU responses that are responsive to a series of APDU commands received from access device 160. ¶0111, The dynamic transaction processing information 212 returned to access device 260 may include a transaction cryptogram generated using the LUK. ¶0112, The transaction processing information 212 can be sent in the form of a GPO response to access device 260. . The transaction processing information 212 may include a transaction cryptogram dynamically generated using the LUK as indicated above, track-2 equivalent data, and addition data such as issuer application data (IAD), form factor indicator (FFI), card transaction qualifiers (CTQ), cryptogram information data (CID), the updated ATC, and/or an application PAN sequence number (PSN). ¶0173, At block 808, the communication device may send the transaction cryptogram and the signature to the access device to request access to a good or service associated with the transaction… In some embodiments, the transaction cryptogram and the signature can be sent to the access device in the same communication. See fig 2A 210-212.) comparing the first digest with the second digest; if the first digest matches the second digest, proceeding with further authentication and subsequently generating an authorisation request message for provision to an authorisation system; and if the first digest does not match the second digest, aborting the transaction process. (¶0181, At block 918, the access device authenticates the signature based on the communication device public key associated with the communication device. For example, authenticating the signature may include deciphering the signature using the communication device public key to obtain a hash value, and comparing the hash value against an access device hash value computed by the access device. In some embodiments, the hash value included in the signature can be computed over at least some of the terminal transaction data provided to the communication device from the access device.) Wong does not explicitly disclose, however Mizuno teaches: generating a second digest using a stored plurality of transaction data items exchanged between the payment device and the terminal during the transaction process; (¶0035, the comparison unit 204 calculates a hash value 1 after a plain text has been input to the comparison unit 204 at step 301 and calculates a hash value 2 from a decrypted text at step 303. Then, the hash value 1 is compared with the hash value 2 at step 304. ¶0040, In this case, the same as in the encryption process, comparison with the use of hash values may be carried out. When applied to the flowchart of decryption process of FIG. 4, after a cryptogram is input to the comparison unit 204 at step 401, the comparison unit 204 calculates a hash value 1 and calculates a hash value 2 from the cryptogram at step 403 and then compares the hash value 1 and the hash value 2 at step 404. Then, MP 100 checks the result of comparison at step 405.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the disclosure of Wong by further incorporating Mizuno’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to verify that the preciously exchanged data remains consistent and has not been altered before transferring it to the authentication system. Further, the claimed limitation “for…” in “…proceeding with further authentication and subsequently generating an authorisation request message for provision to an authorisation system…” consist of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution. Furthermore, the claimed limitation “the transaction data items being exchanged between the payment device and the terminal during the transaction process” only describe characteristics of the transaction data items which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics. Finally, the claim limitations “if the first digest matches the second digest, proceeding, by the terminal, with further authentication and subsequently generating an authorisation request message for provision to an authorisation system;” and “if the first digest does not match the second digest, aborting, by the terminal, the transaction process.” are conditional limitations which means that the claim limitations are only required when the stated conditions are met. Regarding claim 19, the combination of Wong and Mizuno disclose: the authorisation request message further comprises an authorisation data element containing proprietary information for provision by the terminal to the authorisation system, and wherein the first digest is contained at a fixed location within the authorisation data element. (¶0009, The operations may further include generating, by the communication device, a transaction cryptogram using the LUK, and a signature using the signature key, and sending, to an access device, the transaction cryptogram and the signature to request access to a good or a service associated with the transaction. ¶0173, At block 808, the communication device may send the transaction cryptogram and the signature to the access device to request access to a good or service associated with the transaction.) Further, the claimed limitation “wherein the authorisation request message further comprises an authorisation data element containing proprietary information for provision by the terminal to the authorisation system, and wherein the first digest is contained at a fixed location within the authorisation data element.” only describe characteristics of the authorisation request message and the first digest which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics. Regarding claim 20, the combination of Wong and Mizuno further disclose: the cryptogram response message comprises an envelope containing one or more additional data items associated with the transaction process that are desired to be verified by the payment device, and wherein generating an authorization request message for provision to an authorisation system comprises appending the envelope containing the one or more additional data items to the authorisation request message. (Wong ¶0173, In some embodiments, the communication device may also send a token (e.g., a substitute for an account identifier) instead of a real account identifier to the access device for the transaction. ¶0174, The communication device may also send, to the access device, a communication device public key certificate including a communication device public key that is used to authenticate the signature, a certificate authority public key index, and an issuer public key certificate. The certificate authority public key index can be used by the access device to identify a proper certificate authority public key to authenticate the issuer public key certificate, and the issuer public key certificate may include an issuer public key that is used to authenticate the communication device public key certificate. The communication device may also send a token (e.g., a substitute for an account identifier) instead of a real account identifier to the access device for the transaction.) Further, the claimed limitation “for…” in “… generating an authorization request message for provision to an authorisation system comprises appending the envelope containing the one or more additional data items to the authorisation request message” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution. Conclusion 07-96 The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US 20190188731 A1 to Roberts discloses: A method for a goods manager to authenticate products at the point of sale is provided. The method comprises: providing an authentication device to a merchant, wherein the authentication device is not associated with a product but is configured to receive product information from a merchant terminal; once information about a product has been received by the authentication device from the merchant terminal, obtaining from the authentication device a signed message comprising information about the authentication device and information about the product received from the merchant terminal; and providing authorization data to the authentication device if the information fulfils one or more criteria, thereby associating the authentication device with the product. A method for a merchant to authenticate goods at the point of sale and a merchant terminal to perform such a method are also provided. US 20180268406 A1 to Rice discloses: A method for providing scripts for execution as part of an electronic transaction includes: storing, in a memory of an integrated circuit payment card, at least one or more executable scripts, payment credentials, and a cryptogram rule; receiving, by a receiving device of the integrated circuit payment card, a transaction request from a point of sale device, wherein the transaction request includes at least one or more transaction items and a script request; generating, by a generation module of the integrated circuit payment card, at least one payment cryptogram based on at least the cryptogram rule and at least one of the one or more transaction items; and electronically transmitting, by a transmitting device of the integrated circuit payment card, at least one of the one or more executable scripts, the payment credentials, and the generated at least one payment cryptogram to the point of sale device. US 20230237485 A1 to Graham discloses: There is discussed a method of authorising an electronic transaction in which a user device receives a shared secret and a shared secret identifier. Subsequently, on receipt of transaction data from a transaction terminal, the user device calculates a one-way hash of data comprising the shared secret to generate a hash value, generates authentication data comprising the hash value and the shared secret identifier, and transmits the authentication data to the transaction terminal. US 20170308899 A1 to Smets discloses: A payment transaction is performed at a POS (point of sale) device. The device includes a terminal component and a reader component. The reader component includes a contact interface for establishing a data signal path via conductive contact with an integrated circuit (IC) payment card. A payment transaction is initiated. The data signal path is established between the reader component and the IC payment card. The IC payment card is commanded to generate a cryptogram for verification by an issuer of the card. The cryptogram is received from the card. In response to receiving the cryptogram, a command is issued to disable contact reading operation by the reader component. US 20160307186 A1 to Noe discloses: A communication channel is established between a mobile device and a remote payment support service computer. The mobile device exchanges data communications with a contactless IC (integrated circuit) payment device, and triggers the payment device to generate a cryptogram. The mobile device receives the cryptogram and transmits it to the remote payment support service computer. The mobile device receives provisioning of payment credentials from the remote payment support service computer. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm. 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. /J.L./Examiner, Art Unit 3698 /STEVEN S KIM/Primary Examiner, Art Unit 3698 Application/Control Number: 18/563,356 Page 2 Art Unit: 3698 Application/Control Number: 18/563,356 Page 4 Art Unit: 3698 Application/Control Number: 18/563,356 Page 5 Art Unit: 3698 Application/Control Number: 18/563,356 Page 7 Art Unit: 3698 Application/Control Number: 18/563,356 Page 8 Art Unit: 3698 Application/Control Number: 18/563,356 Page 9 Art Unit: 3698 Application/Control Number: 18/563,356 Page 10 Art Unit: 3698 Application/Control Number: 18/563,356 Page 11 Art Unit: 3698 Application/Control Number: 18/563,356 Page 12 Art Unit: 3698 Application/Control Number: 18/563,356 Page 13 Art Unit: 3698 Application/Control Number: 18/563,356 Page 14 Art Unit: 3698 Application/Control Number: 18/563,356 Page 15 Art Unit: 3698 Application/Control Number: 18/563,356 Page 16 Art Unit: 3698 Application/Control Number: 18/563,356 Page 17 Art Unit: 3698 Application/Control Number: 18/563,356 Page 18 Art Unit: 3698 Application/Control Number: 18/563,356 Page 20 Art Unit: 3698 Application/Control Number: 18/563,356 Page 21 Art Unit: 3698 Application/Control Number: 18/563,356 Page 22 Art Unit: 3698 Application/Control Number: 18/563,356 Page 23 Art Unit: 3698 Application/Control Number: 18/563,356 Page 24 Art Unit: 3698 Application/Control Number: 18/563,356 Page 25 Art Unit: 3698 Application/Control Number: 18/563,356 Page 26 Art Unit: 3698 Application/Control Number: 18/563,356 Page 27 Art Unit: 3698 Application/Control Number: 18/563,356 Page 28 Art Unit: 3698 Application/Control Number: 18/563,356 Page 29 Art Unit: 3698 Application/Control Number: 18/563,356 Page 30 Art Unit: 3698 Application/Control Number: 18/563,356 Page 31 Art Unit: 3698 Application/Control Number: 18/563,356 Page 32 Art Unit: 3698 Application/Control Number: 18/563,356 Page 33 Art Unit: 3698 Application/Control Number: 18/563,356 Page 34 Art Unit: 3698 Application/Control Number: 18/563,356 Page 35 Art Unit: 3698 Application/Control Number: 18/563,356 Page 36 Art Unit: 3698 Application/Control Number: 18/563,356 Page 37 Art Unit: 3698 Application/Control Number: 18/563,356 Page 38 Art Unit: 3698 Application/Control Number: 18/563,356 Page 39 Art Unit: 3698 Application/Control Number: 18/563,356 Page 40 Art Unit: 3698 Application/Control Number: 18/563,356 Page 41 Art Unit: 3698
Prosecution Insights