DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA . 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 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.
This Office Action is in response Applicant communication filed on 1/23/2026.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/23/2026 has been entered.
Claims
Claims 1, 8, 12, 20, and 25 have been amended.
Claims 5 and 13-19 have been cancelled.
Claims 1-4, 6-12, and 20-28 are currently pending in the application.
Response to Arguments
103
The applicant argues that Arora fails to disclose “receive, over a network, a checkout request from a first server” and “open, in response to receiving the checkout request, a communication field” as recited in claim 1 (see page 9 of applicant’s arguments/remarks).
The examiner respectfully disagrees. Arora in section [0053] recites “Further, at step 510, based on the user details received, the transaction server 120 may provide an NFC transaction request including an NFC transaction link via an SMS, email, and/or a push notification to the user mobile device 105 in order to initiate the NFC transaction”. Here Arora discloses that a transaction server sends a NFC transaction request to the user device in order to allow them to initiate an NFC transaction. Once the user selects the NFC transaction link, it allows the user to bring their NFC card in a predefined proximity to the user mobile device to perform the payment transaction. Therefore Arora discloses these limitations as written.
The applicant further argues that Rule/Arora/Brand does not teach or suggest “retrieve, upon matching the decrypted user identification data with the user account, checkout data, wherein the checkout data comprises a virtual card number (VCN) of a virtual payment card restricted to a predetermined area for use in satisfying the checkout request” in claim 1 (see applicant’s arguments/remarks page 9).
The examiner respectfully disagrees. The limitation “wherein the checkout data comprises a virtual card number (VCN) of a virtual payment card restricted to a predetermined area for use in satisfying the checkout request” does not distinguish over the prior art because it is describing the checkout data and is not positively recited as a step/function of the claims. The description of the checkout data does not affect the steps/functions of the claims in a manipulative sense. Even assuming that this limitation does hold patentable weight, Arora in sections [0022] and [0028] discloses that the NFC card can be either a physical NFC-enabled card or a virtual NFC card stored in the user mobile device. Both the physical and virtual NFC cards can be used to retrieve card details for a payment transaction.
The examiner has considered all of the applicants arguments but maintains the 103 rejection.
Rejections under 35 § U.S.C. 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all
obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4, 6-10, 12, 20-22, and 24-28 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200242588 A1 (“Rule”) and US 20240257097 A1 (“Arora”) and US 20170195298 A1 (“Brand”).
Per claims 1, 12, and 20, Rule discloses:
a processor in a user device (e.g. As used in this application, the terms “system” and “component” and “module” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 800. For example, a component can be, but is not limited to being, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer) (Section [0098]-[0100] and Fig. 1A);;
a memory in the user device storing a software application that, when executed by the processor, causes the processor to: (e.g. As used in this application, the terms “system” and “component” and “module” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 800. For example, a component can be, but is not limited to being, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer) (Section [0098]-[0100] and Fig. 1A);
receive a payload from a card via the communication field, the payload comprising encrypted user identification data (e.g. The contactless card 101 may then encrypt the customer identifier 107 using the diversified key 106 to generate the encrypted customer ID 109. The contactless card 101 may then transmit the encrypted customer ID 109 to the account application 113 of the mobile device 110 (e.g., via an NFC connection, Bluetooth connection, etc.)) and a first authentication credential (e.g. Applets 440 may be configured to respond to one or more requests, such as near field data exchange requests, from a reader, such as a mobile NFC reader (e.g., of the mobile device 110), and produce an NDEF message that comprises a cryptographically secure OTP encoded as an NDEF text tag) (Section [0026], [0037], and [0060]);
decrypt the encrypted user identification data using the private key (e.g. The management application 123 may then decrypt the encrypted customer ID 109 received via the network 130 using the diversified key 106, which reveals the data transmitted by the contactless card 101 (e.g., at least the customer identifier 107)) (Section [0038]);
match, upon decrypting the encrypted user identification data, the decrypted user identification data with a user account (e.g. Doing so allows the management application 123 to verify the data transmitted by the contactless card 101 via the mobile device 110, e.g., by comparing the decrypted customer ID 107 to a customer ID in the account data 124 for the account, where a match of the customer ID values verifies the encrypted data received from the contactless card 101) (Section [0038]);
retrieve, upon matching the decrypted user identification data with the user account, checkout data, wherein the checkout data… (e.g. In at least one embodiment, the management application 123 encrypts the card data 103 before sending to the account application 113. As stated, the card data 103 may include the account number, CVV, and/or expiration date of the contactless card 101. The card data 103 may further include the account holder's first name, last name, shipping address, and billing address. In one embodiment, the account number of the card data 103 is the virtual card number generated subsequent to the verification of the encrypted customer ID 109 by the management application 123) (Section [0039], [0040], and [0043]).
Note: Although Rule discloses both a “software application on a mobile device” that receives a payload from a card via the communication field and a “server” that decrypts the encrypted user identification data, matches the decrypted user identification data with a user account, and retrieves checkout data to satisfy the checkout request. Rule fails to explicitly disclose that they are integrated. However, it would have been an obvious matter of design choice to integrate them into a single computing device, and it appears that Rule would perform equally well with a single computing device. Such a modification would have achieved predictable benefits from economies of scale in addition to offering increased security, improved data management, fast response, and room for expansion while reducing both operating and capital costs. It is the examiner’s position that when the difference between the claimed invention and the prior art is that the prior art does not disclose particular elements as integral, as a matter of law, it would have been obvious to one having ordinary skill in the art to make the elements integral. See MPEP §2144.04 V. B. and In re Larson, 340 F.2d 965, 968, 144 USPQ 347, 349 (CCPA 1965).
Although Rule discloses receiving a payload from a card via a communication field to perform a payment process during an e-commerce checkout. Rule does not specifically disclose:
receive, over a network, a checkout request from a first server;
open, in response to receiving the checkout request, a communication field;
…the payload further comprising a private key;
…checkout data comprises a virtual card number (VCN) of a virtual payment card restricted to a predetermined area for use in satisfying the checkout request.
However Arora, in analogous art of NFC card transactions with mobile devices, discloses:
receive, over a network, a checkout request from a first server (e.g. Further, at step 510, based on the user details received, the transaction server 120 may provide an NFC transaction request including an NFC transaction link via an SMS, email, and/or a push notification to the user mobile device 105 in order to initiate the NFC transaction) (Section [0053]);
open, in response to receiving the checkout request, a communication field (e.g. At step 515, in response to the user clicking on or selecting the NFC transaction link, the BNS 260 may in turn provide the recipient information to the transaction server 120. At step 520, the transaction server 120 may verify the recipient based on the recipient information and provide a transaction approval to the BNS 260. Based on the transaction approval, at step 525, the BNS 260 may prompt, such as by visual and/or auditory means, the user to bring the NFC card 110 in predefined proximity to the user mobile device 105) (Section [0041] and [0053]);
…checkout data comprises a virtual card number (VCN) of a virtual payment card restricted to a predetermined area for use in satisfying the checkout request (e.g. For example, the user mobile device 105 may be configured to retrieve the card details when the NFC card 110 is within a pre-defined physical proximity range with the user mobile device 105. In another example, the user mobile device 105 may be configured to retrieve the card details from the virtual NFC card stored in the user mobile device 105) (Section [0022], [0028], and [0053]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the checkout process of Rule to include the opening of a communication field when a checkout request is received, as taught by Arora, in order to achieve the predictable result of increasing the security of the payment system by only allowing the user to use the communication field with their card when they intend to.
Although Rule/Arora discloses opening a communication field in response to receiving a checkout request, receiving a payload from a card via a communication field to perform a payment process during an e-commerce checkout, and decrypting user identification data included in the payload, Rule/Arora does not specifically disclose:
…the payload further comprising a private key.
However Brand, in analogous art of secure computer communication, discloses:
…the payload further comprising a private key (e.g. If communications are server-initiated, the seed may already have a value such that a symmetric key is calculated and included in the first asymmetrically encrypted payload transmitted to the mobile handset) (Section [0034], [0038], and [0081]-[0085]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the data payload of Rule/Arora to include a private encryption key, as taught by Brand, in order to achieve the predictable result of increasing the security of the payment system by allowing the computing devices to more securely communicate and protect against attackers trying to steal the data (See Brand paragraph [0003]).
Per claims 2 and 28, Rule/Arora/Brand discloses all of the limitations of claims 1 and 12 above. Rule further discloses:
wherein the first authentication credential comprises a unique customer identifier associated with the card (e.g. In some examples, the contactless card 101 and server 120 may include certain data such that the card may be properly identified. The contactless card 101 may comprise one or more unique identifiers (not pictured)) (Section [0063]).
Per claim 3, Rule/Arora/Brand discloses all of the limitations of claim 1 above. Arora further discloses:
wherein the user identification data comprises a number associated with a user device (e.g. In some embodiments, the transaction server 120 may assign the PTIDs dynamically using multiple techniques including, but not limited to, using additional information related to the user mobile device 105 such as, but not limited to, a mobile number of the user and a location of the user mobile device 105 detected and/or identified. In another embodiment, the acquirer 125 or the transaction processor 130 may also assign different terminal identifications (TIDs) to the multiple mobile and/or electronic devices and the transaction server 120 may not be configured to implement the dynamic assigning of the PTIDs. In some embodiments, the transaction server 120 may be configured to combine the PTID assigned to the user mobile device 105 with the recipient information, such as the recipient ID, to uniquely identify each recipient identified based on the recipient information received corresponding to each application) (Section [0048]).
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself that is in the substitution of the identifiers of Arora for the identification data of Rule/Brand. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Per claims 4 and 26, Rule/Arora/Brand discloses all of the limitations of claims 1 and 12 above. Rule further discloses:
wherein the first authentication credential comprises a one-time password (OTP) (e.g. Applets 440 may be added to contactless cards to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. Applets 440 may be configured to respond to one or more requests, such as near field data exchange requests, from a reader, such as a mobile NFC reader (e.g., of the mobile device 110), and produce an NDEF message that comprises a cryptographically secure OTP encoded as an NDEF text tag) (Section [0060]).
Per claim 6, Rule/Arora/Brand discloses all of the limitations of claim 1 above. Rule further discloses:
wherein the checkout data comprises at least one selected from the group of an address associated with the user account, a phone number associated with the user account, and an email associated with the user account (e.g. In at least one embodiment, the management application 123 encrypts the card data 103 before sending to the account application 113. As stated, the card data 103 may include the account number, CVV, and/or expiration date of the contactless card 101. The card data 103 may further include the account holder's first name, last name, shipping address, and billing address) (Section [0039] and [0043]).
Per claims 7 and 27, Rule/Arora/Brand discloses all of the limitations of claims 1 and 12 above. Rule further discloses:
wherein the checkout data comprises at least one selected from the group of a card number, a card verification value (CVV), and a card expiration date associated with the card (e.g. In at least one embodiment, the management application 123 encrypts the card data 103 before sending to the account application 113. As stated, the card data 103 may include the account number, CVV, and/or expiration date of the contactless card 101. The card data 103 may further include the account holder's first name, last name, shipping address, and billing address) (Section [0039] and [0043]).
Per claim 8, Rule/Arora/Brand discloses all of the limitations of claim 1 above. Rule further discloses:
wherein the checkout data is retrieved from a second server (e.g. after verifying the encrypted customer ID 109 of FIG. 1A, the management application 123 of the server 120 transmits the card data 103 from the server 120 to the mobile device 110) (Section [0038]-[0040]).
Per claims 9 and 24, Rule/Arora/Brand discloses all of the limitations of claims 1 and 12 above. Arora further discloses:
wherein the software application is associated with a merchant mobile application configured to perform one or more mobile transactions (e.g. The user mobile device 105 may have one or more applications installed or stored in the user mobile device 105. The applications may include system applications that may be pre-installed by a device manufacturer and/or installed applications that may downloaded from an application distribution platform and/or installed by the user in the user mobile device 105 via the network 115. Examples of the applications include, but are not limited to, merchant applications, ecommerce applications, financial applications such as banking applications and/or payment or fund transfer applications, travel, transit tickets and toll applications, donation collection applications, loyalty applications and service provider applications such as, short service message (SMS), email, and/or push notifications, that facilitate and/or aid financial transactions) (Section [0022]).
The motivation to combine Arora with Rule/Brand is disclosed above with reference to claims 1, 12, and 20.
Per claim 10, Rule/Arora/Brand discloses all of the limitations of claim 1 above. Rule further discloses:
the first authentication credential is a message authentication code (MAC) (e.g. After communication has been established between mobile device 110 and contactless card 101, the contactless card 101 generates a message authentication code (MAC) cryptogram. In some examples, this may occur when the contactless card 101 is read by the account application 113) (Section [0025]);
the card has generated the MAC over a counter value a unique customer identifier, and a session key (e.g. At this point, the counter value 104 maintained by the contactless card 101 may be updated or incremented, which may be followed by “Read NDEF file.” At this point, the message may be generated which may include a header and a shared secret. Session keys may then be generated. The MAC cryptogram may be created from the message, which may include the header and the shared secret. The MAC cryptogram may then be concatenated with one or more blocks of random data, and the MAC cryptogram and a random number (RND) may be encrypted with the session key) (Section [0025]).
the software application has caused the processor to decrypt the MAC using the private key… (e.g. As stated, the counter value 104 may be specified in the data received from the mobile device 110, or a counter value 104 maintained by the server 120 to implement key diversification for the contactless card 101. The output of the encryption may be the same diversified key value 106 that was created by the contactless card 101. The management application 123 may then decrypt the encrypted customer ID 109 received via the network 130 using the diversified key 106, which reveals the data transmitted by the contactless card 101 (e.g., at least the customer identifier 107). Doing so allows the management application 123 to verify the data transmitted by the contactless card 101 via the mobile device 110, e.g., by comparing the decrypted customer ID 107 to a customer ID in the account data 124 for the account) (Section [0027]).
Brand further discloses:
…private key received in the payload (e.g. If communications are server-initiated, the seed may already have a value such that a symmetric key is calculated and included in the first asymmetrically encrypted payload transmitted to the mobile handset) (Section [0034], [0038], and [0081]-[0085]).
The motivation to combine Brand with Rule/Arora is disclosed above with reference to claims 1, 12, and 20.
Per claim 21, Rule/Arora/Brand discloses all of the limitations of claim 1 above. Rule further discloses:
wherein the encrypted user identification data is encrypted using a hash function (e.g. More generally, when preparing to send data (e.g., to the server 120 and/or the mobile device 110), the contactless card 101 may increment the counter value 104. The contactless card 101 may then provide the master key 105 and counter value 104 as input to a cryptographic algorithm, which produces a diversified key 106 as output. The cryptographic algorithm may include encryption algorithms, hash-based message authentication code (HMAC) algorithms, cipher-based message authentication code (CMAC) algorithms, and the like. Non-limiting examples of the cryptographic algorithm may include a symmetric encryption algorithm such as 3DES or AES128; a symmetric HMAC algorithm, such as HMAC-SHA-256; and a symmetric CMAC algorithm such as AES-CMAC) (Section [0026] and [0028]).
Per claim 22, Rule/Arora/Brand discloses all of the limitations of claim 12 above. Rule further discloses:
wherein the checkout data is retrieved from the user device (e.g. In another embodiment, the account number of the card data 103 is a record from the account numbers 108. In one embodiment, the first and last names are stored in the account application 113 (or another element of the OS). In such embodiments, the account application 113 may provide the locally stored names to the autofill service 114 with the card data 103. Furthermore, as stated, the account number may comprise a virtual account number. The account application 113 may then receive the card data 103 and decrypt the received card data 103 (if the card data 103 has been encrypted). The account application 113 may then provide the card data 103 to an API of the autofill service 114 (and/or the accessibility service 117)) (Section [0039]).
Per claim 25, Rule/Arora/Brand discloses all of the limitations of claim 12 above. Rule further discloses:
transmitting, by the software application, the decrypted user identification data to a second server (e.g. the account application 113 of the mobile device 110 may then transmit the encrypted customer ID 109 to the server 120 via the network 130. In at least one embodiment, the contactless card 101 transmits the counter value 104 along with the encrypted customer ID 109) (Section [0037]-[0038]);
receiving, by the software application, checkout data from the second server wherein the second server has matched the decrypted user identification data with a user account, the user account comprising at least the checkout data (e.g. The management application 123 may then decrypt the encrypted customer ID 109 received via the network 130 using the diversified key 106, which reveals the data transmitted by the contactless card 101 (e.g., at least the customer identifier 107). Doing so allows the management application 123 to verify the data transmitted by the contactless card 101 via the mobile device 110, e.g., by comparing the decrypted customer ID 107 to a customer ID in the account data 124 for the account, where a match of the customer ID values verifies the encrypted data received from the contactless card 101. In some embodiments, once the management application 123 verifies the encrypted customer ID 109, the management application 123 generates a virtual card number for the associated account, or causes a virtual card number for the associated account to be generated). (e.g. As shown in FIG. 1B, after verifying the encrypted customer ID 109 of FIG. 1A, the management application 123 of the server 120 transmits the card data 103 from the server 120 to the mobile device 110) (Section [0038]-[0039]);
Note: Although Rule discloses both a “software application on a mobile device” that receives a payload from a card via the communication field and a “server” that decrypts the encrypted user identification data, matches the decrypted user identification data with a user account, and retrieves checkout data to satisfy the checkout request. Rule fails to explicitly disclose that they are integrated. However, it would have been an obvious matter of design choice to integrate them into a single computing device, and it appears that Rule would perform equally well with a single computing device. Such a modification would have achieved predictable benefits from economies of scale in addition to offering increased security, improved data management, fast response, and room for expansion while reducing both operating and capital costs. It is the examiner’s position that when the difference between the claimed invention and the prior art is that the prior art does not disclose particular elements as integral, as a matter of law, it would have been obvious to one having ordinary skill in the art to make the elements integral. See MPEP §2144.04 V. B. and In re Larson, 340 F.2d 965, 968, 144 USPQ 347, 349 (CCPA 1965).
Claims 11 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Rule/Arora/Brand, as applied to claims 1 and 12 above, in further view of US 20190095989 A1 (“Archer”).
Per claims 11 and 23, although Rule/Arora/Brand discloses a software application that gets checkout data based on receiving a payload from a card, Rule/Arora/Brand do not specifically disclose:
receiving an account creation request, the account creation request further comprising the checkout data;
generate, in response to receiving the account creation request, a second user account.
However Archer, in analogous art of online transactions, discloses:
receiving an account creation request, the account creation request further comprising the checkout data (e.g. The process 300 receives (305) a request from a client to create a new account. Clients can include (but are not limited to) merchant POS terminals, mobile applications, and websites. Requests can include a variety of information, including (but not limited to) information about a consumer to be associated with the card, information about the account set up, and/or information about a merchant or retailer that initiated the request for the new account. Such information can include (but is not limited to) credit scores, credit history, pre-load amounts, geographic locations, a number of previous requests for new accounts, and/or an amount of funds that have been loaded into other new accounts) (Section [0045]);
generate, in response to receiving the account creation request, a second user account (e.g. The process provides (335) the proxy and retrieved account information to the client that initiated the request. Clients in accordance with many embodiments use a proxy and associated account information to initialize a card (e.g., a pre-paid card), and to associate the card with the newly created account. In many embodiments, consumers can use such cards to transfer funds, withdraw funds, make purchases at various retailers, and/or to add additional funds to the associated account) (Section [0049]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the NFC checkout process of Rule/Arora/Brand to include the account creation process, as taught by Archer, in order to achieve the predictable result of providing convenience to the user so that they can easily perform transactions in the future using the same account.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US Publication Number 20190303915 A1 to Hammad teaches user’s card that sends identification information to a user’s device via NFC in order to perform a payment transaction. US Publication Number 20210342816 A1 to Benkreira teaches a system and method that receives an encrypted customer identifier from a contactless card and then decrypts it to match the customer ID to retrieve customer payment credentials.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY P SAX whose telephone number is (571) 272-2935. The examiner can normally be reached on M-F 8-4:30.
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.
/TS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698