DETAILED ACTION
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 .
Status of Claims
This communication is responsive to the submission filed March 11, 2026.
Claims 1-20 are pending.
Response to Remarks
35 U.S.C. § 103
Applicant contends that the independent claims are allowable over the combination of Kalgi, Aciicmez, and Sheets. First, Applicant contends that Kalgi fails to disclose “transmitting . . . a token for an account to the wallet provider based at least in part on the determination of whether the purchase request is authorized” because Kalgi fails to disclose “determining, by the wallet client layer executed on the client device, whether the purchase request is authorized based at least in part on data provided from the wallet provider in association with the security attestation.” Examiner respectfully disagrees. Kalgi discloses a system where wallet software, i.e., the EWCP, is executed on a customer’s device and communicates with the EWCP server to facilitate a transaction with a merchant. While Kalgi fails to disclose that the determination step is performed using the security attestation, Kalgi does disclose determining whether the purchase request is authorized using data from the wallet provider, as claimed. Specifically, Kalgi at ¶ 41 discloses that the EWCP sends to the EWCP server the customer’s EWCP login information. In response to a successful verification of EWCP login information, the EWCP server provides a payment selection to the client (see ¶ 42). In response, the EWCP determines that the purchase request is authorized by displaying a payment method for selection (see ¶ 43). However, as noted above, this functionality is based on verification of login information rather than an attestation report as claimed. It is the combination of Kalgi and Aciicmez that discloses this claim limitation, as discussed below.
Applicant also contends that Aciicmez fails to disclose “generating, by the wallet client layer executed on the client device, a security attestation for the purchase request based at least in part on executing a security library installed in the client device, the security attestation being provided to a wallet provider” and cites to ¶ 19 of Aciicmez. However, the non-final Office Action did not cite to ¶ 19 but rather to ¶ 34. Paragraph 34 discloses that a client computer prepares an attestation report and transmits it to the server. In other words, Aciicmez discloses a technique for a client device to generate an attestation report and send it to a server, which provides a service to the client device. Such a technique is applicable to the client and server disclosed in Kalgi with the client device in Aciicmez corresponding to the customer device in Kalgi and the server in Aciicmez corresponding to the EWCP server in Kalgi. Therefore, it is the combination of Kalgi and Aciicmez that discloses this claim limitation.
Applicant next contends that Aciicmez fails to disclose “determining, by the wallet client layer executed on the client device, whether the purchase request is authorized based at least in part on data provided from the wallet provider in association with the security attestation.” Examiner respectfully disagrees. As discussed above, Kalgi discloses determining whether the client request is authorized based at least in part on data provided from the server. However, Kalgi fails to disclose that such determination is performed in association with the security attestation. However, Aciicmez cures this deficiency as it discloses the server authorizing the client device based on the received attestation report. Based on this authorization, the server transmits to the client device security requirements for the trusted agent to enforce (see ¶ 36). The client device, via the trusted agent, then enforces the security requirements (see ¶ 36). In other words, Aciicmez discloses the technique that the client device has determined that the server has authorized the client device to perform an action using services provided by the server. This technique may then be applied to the customer EWCP client software and EWCP server so that such a technique is used for a purchase request. Therefore, it is the combination of Kalgi and Aciicmez as a whole, rather than as individual references, that discloses the subject matter of these claim limitations.
Accordingly, this ground of rejection is maintained.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-5, 8-12, and 15-19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,165,132. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Claims 1, 8, and 15
‘132 Patent
A method comprising: identifying, by a wallet client layer executed on a client device, a purchase request from a merchant application executed on the client device;
Claim 1: A method comprising: identifying, by a wallet client layer executed on a client device, an in-app purchase request from a merchant application executed on the client device
generating, by the wallet client layer executed on the client device, a security attestation for the purchase request based at least in part on executing a security library installed in the client device, the security attestation being provided to a wallet provider;
Claim 1: determining, by the wallet client layer executed on the client device, that the client device is secure by executing the security library in response to receiving the instruction, the execution of the security library generating a device response for the wallet provider;
determining, by the wallet client layer executed on the client device, whether the purchase request is authorized based at least in part on data provided from the wallet provider in association with the security attestation; and
Claim 1: determining, by the wallet client layer executed on the client device, a security code based at least in part on data received from the wallet provider in association with the device response, the security code representing a security risk score for the in-app purchase request;
transmitting, by the wallet client layer executed on the client device, a token for an account to the wallet provider based at least in part on the determination of whether the purchase request is authorized.
Claim 1: transmitting, by the wallet client layer executed on the client device, a token to the wallet provider based at least in part on the security code
Claims 2, 9, and 16
‘132 Patent
wherein the purchase request representing a selection of an item for purchase on the merchant application.
Claim 1: the in-app purchase request representing a selection of an item for purchase on the merchant application
Claims 3, 10, and 17
‘132 Patent
authenticating, by the wallet client layer executed on the client device, the account with the wallet provider based at least in part on a selection of the account on the client device for the purchase request.
Claim 1: authenticating, by the wallet client layer executed on the client device, the account with the wallet provider based at least in part on a selection of the account on the client device for the purchase request.
Claims 4, 11, and 18
‘132 Patent
wherein the execution of the security library is initiated based at least in part on a receipt of an instruction from the wallet provider.
Claim 1: receiving, by the wallet client layer executed on the client device, an instruction from the wallet provider to execute a security library stored in the client device;
Claims 5, 12, and 19
‘132 Patent
wherein the data provided from the wallet provider comprises a modified unpredictable number (MUN), the MUN representing an unpredicted number that has been encoded with a security code from the wallet provider, wherein the security code represents a security risk score for the purchase request.
Claim 7: receiving, by the wallet client layer executed on the client device, a modified unpredictable number (MUN) from the wallet provider
Claims 6-7, 13-14, and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,165,132 in view of U.S. Patent Pub. No. 2016/0092878 to Radu et al. because:
Claims 6, 13, and 20
‘132 Patent
generating, by the wallet client layer executed on the client device, an in-app payment cryptogram based at least in part on the MUN, the security code, or a session key; and
Claim 11: generate a payment cryptogram for the in-app purchase request based at least in part on the security code, wherein the payment cryptogram is generated using the security code.
Radu
transmitting, by the wallet client layer executed on the client device, the token and the in-app payment cryptogram to the wallet provider.
¶ 107: At block 914, the mobile wallet 612 may send a request to the payment application 616 (i.e., to the payment application that corresponds to the selected card account) to have the payment application 616 generate a cryptogram over the transaction amount, an unpredictable number that was supplied by the merchant, and at least one aspect of the user authentication credentials received by the mobile wallet 612 at block 910. The payment application 616 then generates the cryptogram (e.g., in accordance with the standard practices for DSRP) and transmits the cryptogram to the mobile wallet 612. The mobile wallet then sends the cryptogram to the wallet server 614.)
Claims 7 and 14
Radu
generating, by the wallet client layer executed on the client device, a payment payload by appending the token to the in-app payment cryptogram; and
¶ 87: Thus the wallet server 206 may retrieve or generate all the data provided at the point of sale in connection with a conventional EMV transaction, including the PAN or payment token for the account selected by the user, a user authentication flag having a “valid” value, an application cryptogram (AC) in some cases, etc.
transmitting, by the wallet client layer executed on the client device, the payment payload to the wallet provider.
¶ 87: Thus the wallet server 206 may retrieve or generate all the data provided at the point of sale in connection with a conventional EMV transaction, including the PAN or payment token for the account selected by the user, a user authentication flag having a “valid” value, an application cryptogram (AC) in some cases, etc.
Claims 1, 3-8, 10-15, and 17-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,620,641. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Claims 1, 8, and 15
‘641 Patent
A method comprising: identifying, by a wallet client layer executed on a client device, a purchase request from a merchant application executed on the client device;
Claim 1: A method comprising: identifying, by a client device, a purchase transaction request from a merchant application executed on the client device;
generating, by the wallet client layer executed on the client device, a security attestation for the purchase request based at least in part on executing a security library installed in the client device, the security attestation being provided to a wallet provider;
Claim 1: wherein the execution of the security library generates a device attestation response, and the device attestation response is transmitted to the payment network;
determining, by the wallet client layer executed on the client device, whether the purchase request is authorized based at least in part on data provided from the wallet provider in association with the security attestation; and
Claim 1: receiving, by the client device, an updated LUPC from the payment network.
transmitting, by the wallet client layer executed on the client device, a token for an account to the wallet provider based at least in part on the determination of whether the purchase request is authorized.
Claim 2: transmitting, by the client device, the selection of the payment instrument to a wallet service provider for the purchase transaction request.
Claims 3, 10, and 17
‘641 Patent
authenticating, by the wallet client layer executed on the client device, the account with the wallet provider based at least in part on a selection of the account on the client device for the purchase request.
Claim 3: transmitting, by the client device, to the wallet service provider a user credential for authentication of the payment instrument
Claims 4, 11, and 18
‘641 Patent
wherein the execution of the security library is initiated based at least in part on a receipt of an instruction from the wallet provider.
Claim 1: determining, by the client device, that the client device is secure by executing a security library stored in the client device in response to receiving the request to update the LUPC
Claims 5, 12, and 19
‘641 Patent
wherein the data provided from the wallet provider comprises a modified unpredictable number (MUN), the MUN representing an unpredicted number that has been encoded with a security code from the wallet provider, wherein the security code represents a security risk score for the purchase request.
Claim 4: wherein the transaction security data comprises an unpredictable number generated by the wallet service provider, wherein the LUPC is generated based at least in part on the unpredictable number.
Claims 6, 13, and 20
‘641 Patent
generating, by the wallet client layer executed on the client device, an in-app payment cryptogram based at least in part on the MUN, the security code, or a session key; and
Claim 1: generating, by the client device, an in-app payment cryptogram for the purchase transaction request based at least in part on a limited use payment credential (LUPC);
transmitting, by the wallet client layer executed on the client device, the token and the in-app payment cryptogram to the wallet provider.
Claim 1: providing, by the client device, the in-app payment cryptogram to the merchant application, wherein the merchant application transmits the in-app payment cryptogram to a merchant computing device;
Claims 7 and 14
‘641 Patent
generating, by the wallet client layer executed on the client device, a payment payload by appending the token to the in-app payment cryptogram; and
Claim 5: wherein providing the in-app payment cryptogram to the merchant application further comprises providing a token associated with the payment instrument to the merchant application.
transmitting, by the wallet client layer executed on the client device, the payment payload to the wallet provider.
Claim 5: wherein providing the in-app payment cryptogram to the merchant application further comprises providing a token associated with the payment instrument to the merchant application.
Claims 2, 9, and 16 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,620,641 in view of U.S. Patent Pub. No. 2013/0013499 to Kalgi because:
Claims 2, 9, and 16
Kalgi
wherein the purchase request representing a selection of an item for purchase on the merchant application.
¶ 34: The customer may wish to purchase two 204 Micro SD cards 202 at a price 206 of $3.45 each. The customer may click the “Buy” button 208 a to purchase these items
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-4, 8-11, and 15-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Pub. No. 2013/0013499 to Kalgi in view of U.S. Patent Pub. No. 2009/0300348 to Aciicmez et al. and U.S. Patent Pub. No. 2015/0019443 to Sheets et al.
Per Claim 1: Kalgi discloses:
A method comprising: (see Kalgi at Abstract: The ELECTRONIC WALLET CHECKOUT PLATFORM APPARATUSES, METHODS AND SYSTEMS (“EWCP”) transform customer purchase requests triggering electronic wallet applications via EWCP components into electronic purchase confirmation and receipts.)
identifying, by a wallet client layer executed on a client device, a purchase request from a [[merchant]] application executed on the client device; (see Kalgi at ¶ 34: The mobile EWCP application may detect that the merchant's website uses an EWCP-supported protocol (see FIG. 5 for additional details regarding detecting merchant support for an EWCP-supported protocol), and may prompt the customer to use an E-Wallet to facilitate payment. In one embodiment, the E-Wallet may be a part of the mobile EWCP application. In another embodiment, the E-Wallet may be a different mobile EWCP application. In yet another embodiment, the E-Wallet may be a website associated with the EWCP provider, and the customer may be redirected to this website.)
transmitting, by the wallet client layer executed on the client device, a token for an account to the wallet provider based at least in part on the determination of whether the purchase request is authorized. (see Kalgi at ¶ 37: As illustrated in screen 221, the customer may be presented with a choice of payment methods 222 a-222 d (e.g., credit cards, debit cards, gift cards, and/or the like) available in the wallet selected by the customer. In one embodiment, the available payment methods in the wallet may be presented to the customer. Upon selecting a payment method (e.g., 222 a), the customer may use the “Complete the purchase . . . ” button 224 to submit payment information.)
However, Kalgi fails to disclose but Aciicmez, an analogous art of remote attestation, discloses:
generating, by the wallet client layer executed on the client device, a security attestation for the purchase request based at least in part on executing a security library installed in the client device, the security attestation being provided to a wallet provider; (see Aciicmez at ¶ 34: The TPM to ensure authenticity to the server, and transmits the report to the server at step 206. The attestation report (typically containing a subset of hashed measurement values) may be signed using the TPM's certificate, a process sometimes referred to as quoting in trusted computing. Essentially, the server is requesting that the client send a report of its software configuration. Given that the client is a trusted computing platform in this embodiment or scenario, at step 206 the client is able to prepare an attestation report and transmit it to the server. At step 208 the server receives the report in response to the challenge it made at step 204.)
determining, by the wallet client layer executed on the client device, whether the purchase request is authorized based at least in part on data provided from the wallet provider in association with the security attestation; and (see Aciicmez at ¶¶ 36-37: Returning to step 210, if the server finds that the requesting client has a trusted agent, at step 216 the server transmits the security requirements of the service being requested to the agent. The types of security requirements can vary widely, have many different flavors and vary widely in complexity and objective. In a relatively simple example, a security policy or rule set may consist of a single rule such as “Fulfill the service request if the client has not requested any service from the server in the last 60 seconds” or “There must be a 10 minute period between consecutive accesses to the service.” As those skilled in the art will recognize, security requirements and policies can be quite complex and would be generally knowledgeable of the wide range of security policies that may be implemented by the server or any computing system offering services in a network (the complexity and parameters of such requirements may also depend on the hardware capabilities of the computing system). At step 218 the trusted agent enforces the security requirements. The agent has logic and software means that allows it to perform this enforcement function. From one perspective, the trusted agent may be described as now “looking out” for the interests of the server even though it resides on the client. A suitable protocol for the interaction between the server and the trusted agent within the client may be used. If a standard protocol is defined and utilized, a trusted client device may only need a single trusted agent installed and running and to be able to have numerous servers leverage the functionality of the single trusted agent by virtue of the standard protocol. At step 220 the server provides the service to the client upon receiving a verification message from the trusted agent that the service request being made is within the parameters of the security requirements.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalgi so that the customer’s device is first verified as being secure using the remote attestation techniques disclosed in Aciicmez. One of ordinary skill in the art would have been motivated to do so to increase the security of the transactions.
However, the combination of Kalgi and Aciicmez fails to disclose but Sheets, an analogous art of making purchases within a merchant application, discloses using a merchant application to perform the transaction (see Sheets at ¶ 7: For example, embodiments of the present invention allow consumers to use a mobile device comprising secure and sensitive payment credentials during a remote payment transaction initiated through a merchant website or merchant application.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalgi so that a merchant application, rather than a merchant website, is used for the transaction. It would have been obvious to one of ordinary skill in the art as it would have been obvious to try a merchant application which discloses it as an alternative to a merchant website for performing transactions.
Per Claim 8: Claim 8 recites subject matter similar to that discussed above in connection with claim 1 and does so in the context of a system. Claim 8 further recites and Kalgi further discloses:
A system, comprising: a client device comprising a processor and a memory; and machine-readable instructions stored in the memory that, when executed by the processor, cause the client device to at least: (see Kalgi at ¶ 148: In turn, computers employ processors to process information; such processors 2003 may be referred to as central processing units (CPU). One form of processor is referred to as a microprocessor. CPUs use communicative circuits to pass binary encoded signals acting as instructions to enable various operations. These instructions may be operational and/or data instructions containing and/or referencing other instructions and data in various processor accessible and operable areas of memory 2029 (e.g., registers, cache memory, random access memory, etc.). Such communicative instructions may be stored and/or transmitted in batches (e.g., batches of instructions) as programs and/or data components to facilitate desired operations. These stored instruction codes, e.g., programs, may engage the CPU circuit components and other motherboard and/or system components to perform desired operations.)
Per Claim 15: Claim 15 recites subject matter similar to that discussed above in connection with claim 1 and does so in the context of a manufacture which Kalgi discloses (see ¶ 152: A computer systemization 2002 may comprise a clock 2030, central processing unit (“CPU(s)” and/or “processor(s)” (these terms are used interchangeably throughout the disclosure unless noted to the contrary)) 2003, a memory 2029 (e.g., a read only memory (ROM) 2006, a random access memory (RAM) 2005, etc.))
Per Claims 2, 9, and 16: The combination of Kalgi, Aciicmez, and Sheets discloses the subject matter of claims 1, 8, and 15, from which claims 2, 9, and 16 depend, respectively. Kalgi further discloses:
wherein the purchase request representing a selection of an item for purchase on the [[merchant]] application. (see Kalgi at ¶ 34: The customer may wish to purchase two 204 Micro SD cards 202 at a price 206 of $3.45 each. The customer may click the “Buy” button 208 a to purchase these items)
However, the combination of Kalgi and Aciicmez fails to disclose but Sheets discloses using a merchant application to perform the transaction (see Sheets at ¶ 7: For example, embodiments of the present invention allow consumers to use a mobile device comprising secure and sensitive payment credentials during a remote payment transaction initiated through a merchant website or merchant application.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalgi so that a merchant application, rather than a merchant website, is used for the transaction. It would have been obvious to one of ordinary skill in the art as it would have been obvious to try a merchant application which discloses it as an alternative to a merchant website for performing transactions.
Per Claims 3, 10, and 17: The combination of Kalgi, Aciicmez, and Sheets discloses the subject matter of claims 1, 8, and 15, from which claims 3, 10, and 17 depend, respectively. Kalgi further discloses:
authenticating, by the wallet client layer executed on the client device, the account with the wallet provider based at least in part on a selection of the account on the client device for the purchase request. (see Kalgi at ¶ 54: The user's authentication information (e.g., login information for the EWCP) may be obtained. For example, the protocol handler may request authentication information to determine whether to allow the user access to the E-Wallet. A determination may be made at 517 regarding whether the authentication is Near Field Communication (NFC) based. For example, if the user taps the client with an NFC capable credit card, the authentication may be NFC based, otherwise, if the user enters a password, the authentication may be non-NFC based. If the authentication is non-NFC based, the user's non-NFC based authentication information may be obtained at 520. For example, a password associated with the E-Wallet entered by the user may be obtained. If the authentication is NFC based, the user's NFC based authentication information may be obtained at 522. For example, if the user tapped the client with an NFC capable credit card and provided a pin associated with that credit card (e.g., a pin that decrypts a certificate associated with the client that decrypts data from a tag associated with the credit card), information transmitted via NFC and the pin may be obtained.)
Per Claims 4, 11, and 18: The combination of Kalgi, Aciicmez, and Sheets discloses the subject matter of claims 1, 8, and 15, from which claims 4, 11, and 18 depend, respectively. However, Kalgi fails to disclose but Aciicmez discloses:
wherein the execution of the security library is initiated based at least in part on a receipt of an instruction from the wallet provider. (see Aciicmez at ¶ 34: At step 204 the server, in response to receiving the service request, transmits an attestation challenge to the client. As described above, an attestation challenge requires that the receiver of the challenge to create and transmit an attestation report.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalgi so that the digital wallet requests the customer’s device to perform an attestation using the techniques disclosed in Aciicmez. One of ordinary skill in the art would have been motivated to do so to increase the security of the transactions.
Claim(s) 5, 12, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kalgi, Aciicmez, and Sheets as applied to claims 1, 8, and 15 above, and further in view of U.S. Patent Pub. No. 2016/0275492 to Brickell et al.
Per Claims 5, 12, and 19: The combination of Kalgi, Aciicmez, and Sheets discloses the subject matter of claims 1, 8, and 15 from which claims 5, 12, and 19 depend, respectively. However, the combination of Kalgi, Aciicmez, and Sheets fails to disclose but Brickell, an analogous art of transactions, discloses:
wherein the data provided from the wallet provider comprises a modified unpredictable number (MUN), the MUN representing an unpredicted number that has been encoded with a security code from the wallet provider, wherein the security code represents a security risk score for the purchase request. (Examiner’s Note: the claim language “the MUN representing an unpredicted number that has been encoded with a security code from the wallet provider, wherein the security code represents a security risk score for the purchase request” has been considered. However, this claim language, i.e., what the MUN represents or how it was formed by an unclaimed system, appears to fail to affect the operation of the claimed method/system/manufacture. Therefore, it fails to distinguish over the prior art. The following citation is provided: see Brickell at ¶ 93: In block 640, the account management system 130 receives the unpredictable number and communicates the unpredictable number to the digital wallet application 115.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalgi so that the wallet provider sends an unpredictable number to the customer device using the techniques disclosed in Brickell. One of ordinary skill in the art would have been motivated to do so to increase the security of the transaction.
Claim(s) 6-7, 13-14, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kalgi, Aciicmez, Sheets, and Brickell as applied to claims 5, 12, and 19 above, and further in view of U.S. Patent Pub. No. 2016/0092878 to Radu et al.
Per Claims 6, 13, and 20: The combination of Kalgi, Aciicmez, Sheets, and Brickell discloses the subject matter of claims 5, 12, and 19, from which claims 6, 13, and 20 depend, respectively. However, the combination of Kalgi, Aciicmez, Sheets, and Brickell fails to disclose but Radu, an analogous art of transactions, discloses:
generating, by the wallet client layer executed on the client device, an in-app payment cryptogram based at least in part on the MUN, the security code, or a session key; and (see Radu at ¶ 107: At block 914, the mobile wallet 612 may send a request to the payment application 616 (i.e., to the payment application that corresponds to the selected card account) to have the payment application 616 generate a cryptogram over the transaction amount, an unpredictable number that was supplied by the merchant, and at least one aspect of the user authentication credentials received by the mobile wallet 612 at block 910. The payment application 616 then generates the cryptogram (e.g., in accordance with the standard practices for DSRP) and transmits the cryptogram to the mobile wallet 612. The mobile wallet then sends the cryptogram to the wallet server 614.)
transmitting, by the wallet client layer executed on the client device, the token and the in-app payment cryptogram to the wallet provider. (see Radu at ¶ 107: At block 914, the mobile wallet 612 may send a request to the payment application 616 (i.e., to the payment application that corresponds to the selected card account) to have the payment application 616 generate a cryptogram over the transaction amount, an unpredictable number that was supplied by the merchant, and at least one aspect of the user authentication credentials received by the mobile wallet 612 at block 910. The payment application 616 then generates the cryptogram (e.g., in accordance with the standard practices for DSRP) and transmits the cryptogram to the mobile wallet 612. The mobile wallet then sends the cryptogram to the wallet server 614.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalgi so that a transaction cryptogram is generated and transmitted using the techniques disclosed in Radu. One of ordinary skill in the art would have been motivated to do so to increase the security of the transaction.
Per Claims 7 and 14: The combination of Kalgi, Aciicmez, Sheets, Brickell, and Radu discloses the subject matter of claims 6 and 13 from which claims 7 and 14 depend, respectively. However, the combination of Kalgi, Aciicmez, Sheets, and Brickell fails to disclose but Radu discloses:
generating, by the wallet client layer executed on the client device, a payment payload by appending the token to the in-app payment cryptogram; and (see Radu at ¶ 87: Thus the wallet server 206 may retrieve or generate all the data provided at the point of sale in connection with a conventional EMV transaction, including the PAN or payment token for the account selected by the user, a user authentication flag having a “valid” value, an application cryptogram (AC) in some cases, etc.)
transmitting, by the wallet client layer executed on the client device, the payment payload to the wallet provider. (see Radu at ¶ 87: Thus the wallet server 206 may retrieve or generate all the data provided at the point of sale in connection with a conventional EMV transaction, including the PAN or payment token for the account selected by the user, a user authentication flag having a “valid” value, an application cryptogram (AC) in some cases, etc.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalgi so that a payment transaction is created based on the selected payment credential and a cryptogram using the techniques disclosed in Radu. One of ordinary skill in the art would have been motivated to do so to increase the security of the transaction.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Pub. No. 2020/0053560 discloses techniques for enhancing the security of a communication device may include providing an application agent and a transaction application that executes on a communication device. The application agent may receive, from the application, a cryptogram key generated by a remote computer, and store the cryptogram key on the communication device. When the application agent receives a request to conduct a transaction from the application, the application agent may generate a transaction cryptogram using the cryptogram key, and provides the transaction cryptogram to an access device.
U.S. Patent Pub. No. 2023/0410171 discloses systems and methods for use with a service provider and a consumer electronic device include a trusted remote attestation agent (TRAA) configured to perform a set of checking procedures or mechanisms to help ensure the security status of a consumer electronic device (e.g., a mobile terminal or phone) that holds financial instruments. The checking procedures may include: self-verifying integrity by the TRAA; checking for presence of a provisioning SIM card (one that was present when the financial instruments were enabled on the device); checking that a communication connection between the consumer electronic device and the service provider is available and active; and checking that communication connectivity to a home mobile network is available and active. The frequency of the checking mechanisms may be adjusted, for example, according to a risk-profile of a user associated with the device or the location (e.g., GPS location) of the device. The checks may be used, for example, to temporarily disable or limit the use of the financial instruments from the device.
U.S. Patent Pub. No. 2010/0306531 discloses systems and methods are provided for a device to engage in a zero-knowledge proof with an entity requiring authentication either of secret material or of the device itself. The device may provide protection of the secret material or its private key for device authentication using a hardware security module (HSM) of the device, which may include, for example, a read-only memory (ROM) accessible or programmable only by the device manufacturer. In the case of authenticating the device itself a zero-knowledge proof of knowledge may be used. The zero-knowledge proof or zero-knowledge proof of knowledge may be conducted via a communication channel on which an end-to-end (e.g., the device at one end and entity requiring authentication at the other end) unbroken chain of trust is established, unbroken chain of trust referring to a communication channel for which endpoints of each link in the communication channel mutually authenticate each other prior to conducting the zero-knowledge proof of knowledge and for which each link of the communication channel is protected by at least one of hardware protection and encryption.
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 NILESH B KHATRI whose telephone number is (571)270-7083. The examiner can normally be reached 8:30 AM - 5:30 PM Monday-Friday, alternating Fridays off.
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, Neha Patel can be reached at (571) 270-1492. 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.
/NILESH B KHATRI/Primary Examiner, Art Unit 3699
Prosecution Insights