DETAILED ACTION
This is a non-final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 – 21 in application 18/305,239.
Claims 1-3, 9-11, and 15-18 have been amended.
Claim 20 is canceled.
Claims 1-19 and 21 are pending and have been examined on the merits.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/09/2025 has been entered.
Response to Arguments
Response to U.S.C. 102 and other arguments
Applicant's arguments filed 12/09/2025 in regards to the U.S.C. 102 rejection and the newly filed claim (claim 21) have been fully considered but they are not persuasive. The newly added claim limitation in claims 1, 8, and 15 in addition to the newly added claim 21 was not presented until the date of applicant’s arguments. The search has been updated to reflect the newly added limitations. Please see updated rejection below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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, 6-11, 13-18, and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable by Wolfond et al. (US20140207682A1) hereinafter Wolfond in view of Radu et al. (US20150287031A1) hereinafter C. Radu.
Regarding Claim 1. Wolfond discloses:
A method of facilitating a transaction between a mobile device and a processor, comprising: receiving, by the processor of a merchant checkout system, a transaction request comprising a payment token and an EMV ("EUROPAY®, MASTERCARD®, and VISA®") payment application uniform resource identifier ("URI") from the mobile device, the EMV payment application URI comprising a string of characters identifying a storage location of a remote EMV payment application on a payment application server, and
Wolfond - a merchant terminal 115 (¶ 0030). Once the customer has provided a valid payment method, for example by selecting a card (or other security token) from their digital wallet or “tapping” a card to their mobile device, a commitTransaction message can be sent in an HTTP POST request to transaction server 120 at 330 (¶ 0096, Fig. 1 and 3, Wolfond). transaction server generates a transaction identifier (Abstract, Wolfond). Transaction server may validate the initialization information and store it for future use (¶ 0049, Wolfond).
wherein the transaction request is initiated by a merchant application;
Wolfond - A transaction initiation request is received at a transaction server from a merchant device. The transaction server generates a transaction identifier, which is transmitted to the merchant device (Abstract, Wolfond).
invoking, by the processor in electronic communication with a payment application server, a remote EMV payment application based at least in part on sending the payment token and the EMV payment application URI to the payment application server,
Wolfond - generates a…identifier…along with a transaction URL that can be used by a customer device to obtain further transaction details (URL identifies where the remote payment app is addressed) (¶ 0053). the proximity communication interface of customer device 140 reads the transaction information (e.g., the transaction identifier and transaction URL) from merchant device 110 (Establishes a URL (a species of URI) that identifies the server resource) (¶ 0055). Customer device 140 may also transmit additional data to help authenticate the user (e.g., a cryptogram or OTP generated on the device, an embedded card, or a card tapped on the reader) (¶ 0059). customer device 140 and merchant device 110 activate a NFC exchange, for example by tapping one device to the other (shows the NFC exchange used to pass transaction data between phones) (¶ 0082). At 315, customer device 140 transmits an HTTP POST request to transaction server 120. The HTTP POST request may be directed to the transaction URL received from merchant device 110 (directing the HTTP request to the URL is invoking the remote application based on the URI) (¶ 0087). FIG. 6A illustrates an exemplary payment request interface 602, which may be displayed in response to an NFC exchange (e.g., at act 310 of process 300) (¶ 0119, Fig. 6A, Wolfond).
receiving, by the processor, a transaction data request for additional information to authorize the transaction request, in response to a determination by the remote EMV payment application that additional information is required to authorize the transaction request;
Wolfond - Customer device 140 may also transmit additional data to help authenticate the user (e.g., a cryptogram or OTP generated on the device, an embedded card, or a card tapped on the reader). Likewise, merchant device 110 may also transmit similar data when connecting to transaction server 120. Such additional data may be sent to transaction server 120 as a form of authentication, which may occur, for example, when the merchant or customer device connects to transaction server 120. Accordingly, transaction server 120 (or optionally issuer 190) can verify the cryptogram and/or tapped or embedded card data to identify the merchant or customer device (¶ 0059, Wolfond).
transmitting, by the processor, a transaction data request to the mobile device, including a request for additional information;
Wolfond - Customer device 140 may also transmit additional data to help authenticate the user (e.g., a cryptogram or OTP generated on the device, an embedded card, or a card tapped on the reader). Likewise, merchant device 110 may also transmit similar data when connecting to transaction server 120. Such additional data may be sent to transaction server 120 as a form of authentication, which may occur, for example, when the merchant or customer device connects to transaction server 120. Accordingly, transaction server 120 (or optionally issuer 190) can verify the cryptogram and/or tapped or embedded card data to identify the merchant or customer device (¶ 0059, Wolfond).
obtaining, by the processor, a transaction data response from the mobile device; and
Wolfond - generating a transaction identifier and transmitting the transaction identifier to the merchant device; receiving the transaction identifier from the customer device, wherein the transaction identifier has been exchanged via proximity communication with the merchant device; transmitting transaction detail data to the customer device; receiving a transaction authorization from the customer device; and in response to the transaction authorization, completing the transaction (¶0024, Wolfond).
receiving, by the processor, a transaction authorization notice from an issuer system, wherein the transaction authorization notice is based on the transaction authorization request generated by the remote EMV payment application.
Wolfond - At 940, second device 140′ optionally displays the credential data that is to be verified to a user of the second device and, if the user chooses to continue with the verification (e.g., by pressing a confirmation button), transmits an authorization associated with the transaction identifier to transaction server 120′. Customer device 140 may also transmit additional data to help authenticate the user (e.g., a cryptogram or OTP generated on the device, an embedded card, or a card tapped on the reader). Likewise, merchant device 110 may also transmit similar data when connecting to transaction server 120 (¶ 0141, Wolfond).
Wolfond does not teach, however C. Radu discloses:
invoking the remote EMV payment application comprises a merchant system kernel of the merchant checkout system interacting with the remote EMV payment application for processing the transaction request;
C. Radu - The credit card reader 3 interacts with the network access device (such as laptop computer 1 or smartphone 2) to form a client of the Virtual POS 10 (also termed here as Lite POS) “The lite POS/V-POS client is the merchant side POS software (i.e., the “kernel” POS in the merchant checkout system” Certain aspects of POS functionality are provided at the Virtual POS server 7 (¶ 0085). V-POS client can rely on the PSP for the more demanding payment logic…The V-POS server sends commands from the payment application to the V-POS client, which in turn relays these commands to the cardholder's card to obtain the payment proof required by the transaction. (¶ 0086). implementing a command filter at the CCR to protect the EMV chip card and its applications (¶ 0097).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claim invention to modify the merchant checkout flow of Wolfond with the payment processing remotely of C. Radu because doing so improves security by reducing exposure of sensitive EMV application keys on merchant endpoints.
Regarding Claims 2, 9, and 16. The combination of Wolfond and C. Radu further discloses:
The method of claim 1, system of claim 8, and the non-transitory computer-readable medium of claim 15, wherein the remote [[EMV]] payment application is configured to establish a cryptographically protected channel with the merchant system kernel to process the transaction request.
Wolfond - the credit card data collected by customer device 140, either from a physical tap or from a pre-stored virtual card, may be sent directly to the credit card issuer via a secure channel (¶ 0100, Wolfond).
Regarding Claims 3, 10, and 17. The combination of Wolfond and C. Radu further discloses:
The method of claim, 1, system of claim 8, and the non-transitory computer-readable medium of claim 15, wherein the merchant application is executed by the mobile device and the transaction request is transmitted to the computing device from the mobile device.
Wolfond - FIGS. 5A to 5G illustrate exemplary embodiments of a user interface for a merchant device and, optionally, a merchant terminal, when performing a transaction process (¶ 0010, Wolfond).
Regarding Claims 4, 11, and 18. The combination of Wolfond and C. Radu further discloses:
The method of claim 1, system of claim 8, and the non-transitory computer-readable medium of claim 15, wherein the remote [[EMV]] payment application is configured to communicate with an issuer system to process the transaction request.
Wolfond - Issuer server 190 may be a network server device comprising a network interface, processor, memory and storage for computer program instructions. Issuer server 190 may be provided by a credit card issuer or acquirer and used to validate and fulfill transactions, such as credit card transactions (¶ 0039, Wolfond).
Regarding Claims 6 and 13. The combination of Wolfond and C. Radu further discloses:
The method of claim 1 and system of claim 8, further comprising transmitting, by the processor in electronic communication with a payment network, a transaction authorization request comprising the payment token, wherein in response to receiving the transaction authorization request the payment network is configured to at least one of authorize or settle the transaction.
Wolfond - This intuitive and simple approach enables faster transactions for merchants, while allowing merchants, acquirers, and payment networks to seamlessly integrate the described systems and methods into their applications and services, such as billing and inventory (¶ 0020, Wolfond). The customer device transmits the transaction identifier to the transaction server and authorizes the transaction with the transaction server (Abstract).
Regarding Claims 7, 14, and 20. The combination of Wolfond and C. Radu further discloses:
The method of claim 1, system of claim 8, and the non-transitory computer-readable medium of claim 15, wherein the remote [[EMV]] payment application is configured to process the transaction request by generating a payment cryptogram transmitted to the issuer system to authorize the transaction request.
Wolfond - Once the digital wallet is accessed, the customer may be prompted to select a virtual credit card or other security token or credential (e.g., one-time password or cryptogram generator). A SIM/UICC or secure element may also be employed to increase the security of the transaction (e.g., by generating a credit card cryptogram). In some embodiments, credit card information may be stored in the secure element. Customer device 140 may also transmit additional data to help authenticate the user (e.g., a cryptogram or OTP generated on the device, an embedded card, or a card tapped on the reader). Likewise, merchant device 110 may also transmit similar data when connecting to transaction server 120. Such additional data may be sent to transaction server 120 as a form of authentication, which may occur, for example, when the merchant or customer device connects to transaction server 120. Accordingly, transaction server 120 (or optionally issuer 190) can verify the cryptogram and/or tapped or embedded card data to identify the merchant or customer device (¶ 0059, Wolfond).
Regarding Claim 8. Wolfond discloses:
A system comprising: a computing device comprising a processor and a memory; and instructions stored on the memory that, in response to execution by the processor, cause the computing device to at least: receive a transaction request comprising a payment token and a payment application uniform resource identifier ("URI"), the [[EMV]] payment application URI comprising a string of characters identifying a storage location of a remote [[EMV]] payment application, and
Wolfond - Once the customer has provided a valid payment method, for example by selecting a card (or other security token) from their digital wallet or “tapping” a card to their mobile device, a commitTransaction message can be sent in an HTTP POST request to transaction server 120 at 330 (¶ 0096, Fig. 1 and 3, Wolfond). transaction server generates a transaction identifier (Abstract, Wolfond). Transaction server may validate the initialization information and store it for future use (¶ 0049, Wolfond).
wherein the transaction request is initiated by a user input on a merchant application;
Wolfond - A transaction initiation request is received at a transaction server from a merchant device. The transaction server generates a transaction identifier, which is transmitted to the merchant device (Abstract, Wolfond).
invoke a remote [[EMV]] payment application based at least in part on initiating a communication channel with a payment application server, the communication channel is initiated by sending the payment token and the [[EMV]] payment application URI to the payment application server,
Wolfond - FIG. 6A illustrates an exemplary payment request interface 602, which may be displayed in response to an NFC exchange (e.g., at act 310 of process 300) (¶ 0119, Fig. 6A, Wolfond).
receive a transaction data request for additional information to authorize the transaction request, in response to a determination by the remote [[EMV]] payment application that additional information is required to authorize the transaction request transmit a transaction data request to the mobile device, including a request for additional information;
Wolfond - Customer device 140 may also transmit additional data to help authenticate the user (e.g., a cryptogram or OTP generated on the device, an embedded card, or a card tapped on the reader). Likewise, merchant device 110 may also transmit similar data when connecting to transaction server 120. Such additional data may be sent to transaction server 120 as a form of authentication, which may occur, for example, when the merchant or customer device connects to transaction server 120. Accordingly, transaction server 120 (or optionally issuer 190) can verify the cryptogram and/or tapped or embedded card data to identify the merchant or customer device (¶ 0059, Wolfond).
obtain a transaction data response from the mobile device; and
Wolfond - generating a transaction identifier and transmitting the transaction identifier to the merchant device; receiving the transaction identifier from the customer device, wherein the transaction identifier has been exchanged via proximity communication with the merchant device; transmitting transaction detail data to the customer device; receiving a transaction authorization from the customer device; and in response to the transaction authorization, completing the transaction (¶0024, Wolfond).
receive a transaction authorization notice from an issuer system, wherein the transaction authorization notice is based on the transaction authorization request generated by the remote EMV payment application.
Wolfond - At 940, second device 140′ optionally displays the credential data that is to be verified to a user of the second device and, if the user chooses to continue with the verification (e.g., by pressing a confirmation button), transmits an authorization associated with the transaction identifier to transaction server 120′. Customer device 140 may also transmit additional data to help authenticate the user (e.g., a cryptogram or OTP generated on the device, an embedded card, or a card tapped on the reader). Likewise, merchant device 110 may also transmit similar data when connecting to transaction server 120 (¶ 0141, Wolfond).
Wolfond does not teach, however C. Radu discloses:
invoking the remote EMV payment application comprises a merchant system kernel of the merchant checkout system interacting with the remote EMV payment application for processing the transaction request;
C. Radu - The credit card reader 3 interacts with the network access device (such as laptop computer 1 or smartphone 2) to form a client of the Virtual POS 10 (also termed here as Lite POS) “The lite POS/V-POS client is the merchant side POS software (i.e., the “kernel” POS in the merchant checkout system” Certain aspects of POS functionality are provided at the Virtual POS server 7 (¶ 0085). V-POS client can rely on the PSP for the more demanding payment logic…The V-POS server sends commands from the payment application to the V-POS client, which in turn relays these commands to the cardholder's card to obtain the payment proof required by the transaction. (¶ 0086). implementing a command filter at the CCR to protect the EMV chip card and its applications (¶ 0097).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claim invention to modify the merchant checkout flow of Wolfond with the payment processing remotely of C. Radu because doing so improves security by reducing exposure of sensitive EMV application keys on merchant endpoints.
Regarding Claim 15. Wolfond discloses:
A non-transitory computer-readable medium comprising instructions that, when executed by a processor of a computing device, cause the computing device to at least: receive a transaction request comprising a payment token and a payment application uniform resource identifier ("URI") from a mobile device, the EMV payment application URI comprising a string of characters identifying a storage location of a remote EMV payment application on a payment application server,
Wolfond - Once the customer has provided a valid payment method, for example by selecting a card (or other security token) from their digital wallet or “tapping” a card to their mobile device, a commitTransaction message can be sent in an HTTP POST request to transaction server 120 at 330 (¶ 0096, Fig. 1 and 3, Wolfond). transaction server generates a transaction identifier (Abstract, Wolfond). Transaction server may validate the initialization information and store it for future use (¶ 0049, Wolfond).
invoke a remote EMV payment application based at least in part on sending the payment token and the EMV payment application URI to the payment application server,
Wolfond - FIG. 6A illustrates an exemplary payment request interface 602, which may be displayed in response to an NFC exchange (e.g., at act 310 of process 300) (¶ 0119, Fig. 6A, Wolfond).
obtain a transaction data request for additional information to authorize the transaction request, in response to a determination by the remote EMV payment application that additional information is required to authorize the transaction request;
Wolfond - generating a transaction identifier and transmitting the transaction identifier to the merchant device; receiving the transaction identifier from the customer device, wherein the transaction identifier has been exchanged via proximity communication with the merchant device; transmitting transaction detail data to the customer device; receiving a transaction authorization from the customer device; and in response to the transaction authorization, completing the transaction (¶0024, Wolfond).
transmit a transaction data request to the mobile device, including a request for additional information;
Wolfond - Customer device 140 may also transmit additional data to help authenticate the user (e.g., a cryptogram or OTP generated on the device, an embedded card, or a card tapped on the reader). Likewise, merchant device 110 may also transmit similar data when connecting to transaction server 120. Such additional data may be sent to transaction server 120 as a form of authentication, which may occur, for example, when the merchant or customer device connects to transaction server 120. Accordingly, transaction server 120 (or optionally issuer 190) can verify the cryptogram and/or tapped or embedded card data to identify the merchant or customer device (¶ 0059, Wolfond).
obtain a transaction data response from the mobile device; and
Wolfond - generating a transaction identifier and transmitting the transaction identifier to the merchant device; receiving the transaction identifier from the customer device, wherein the transaction identifier has been exchanged via proximity communication with the merchant device; transmitting transaction detail data to the customer device; receiving a transaction authorization from the customer device; and in response to the transaction authorization, completing the transaction (¶0024, Wolfond).
receive a transaction authorization notice from an issuer system, wherein the transaction authorization notice is based on the transaction authorization request generated by the remote EMV payment application.
Wolfond - At 940, second device 140′ optionally displays the credential data that is to be verified to a user of the second device and, if the user chooses to continue with the verification (e.g., by pressing a confirmation button), transmits an authorization associated with the transaction identifier to transaction server 120′. Customer device 140 may also transmit additional data to help authenticate the user (e.g., a cryptogram or OTP generated on the device, an embedded card, or a card tapped on the reader). Likewise, merchant device 110 may also transmit similar data when connecting to transaction server 120 (¶ 0141, Wolfond).
Wolfond does not teach, however C. Radu discloses:
invoking the remote EMV payment application comprises a merchant system kernel of the merchant checkout system interacting with the remote EMV payment application for processing the transaction request;
C. Radu - The credit card reader 3 interacts with the network access device (such as laptop computer 1 or smartphone 2) to form a client of the Virtual POS 10 (also termed here as Lite POS) “The lite POS/V-POS client is the merchant side POS software (i.e., the “kernel” POS in the merchant checkout system” Certain aspects of POS functionality are provided at the Virtual POS server 7 (¶ 0085). V-POS client can rely on the PSP for the more demanding payment logic…The V-POS server sends commands from the payment application to the V-POS client, which in turn relays these commands to the cardholder's card to obtain the payment proof required by the transaction. (¶ 0086). implementing a command filter at the CCR to protect the EMV chip card and its applications (¶ 0097).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claim invention to modify the merchant checkout flow of Wolfond with the payment processing remotely of C. Radu because doing so improves security by reducing exposure of sensitive EMV application keys on merchant endpoints.
Regarding Claim 21. The combination of Wolfond and C. Radu further discloses:
The non-transitory computer-readable medium of claim 15, wherein the instructions that invoke the remote payment application further cause the computing device to at least: initiate an instance of the merchant system kernel for the transaction request.
C. Radu - A secure payment system comprises a merchant POS client and a remote POS server. The merchant POS client comprises a reading device for reading a customer user token and for accepting transaction details and customer verification data, and also a computing device with access to a communications network and in communication with the reading device. The merchant POS client also comprises a merchant token associated with the remote POS server. The remote POS server is in communication with the merchant POS client through the communications network, and one or more elements of the merchant POS client business logic are assured by the remote POS server and not the merchant POS client. A merchant token for use in such a merchant POS client is described, as is a suitable reader device, and a method of conducting a transaction using such a payment system (Abstract).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claim invention to modify the merchant checkout flow of Wolfond with the payment processing remotely of C. Radu because doing so improves security by reducing exposure of sensitive EMV application keys on merchant endpoints.
Claim(s) 5, 12, and 19 s/are rejected under 35 U.S.C. 103 as being unpatentable over Wolfond in view of C. Radu and in further view of Radu et al. (US20160092878A1) hereinafter Radu.
Regarding Claims 5, 12, and 19. The combination of Wolfond and C. Radu does not teach, however, Radu discloses:
The method of claim 1, system of claim 8, and the non-transitory computer-readable medium of claim 15, wherein the additional information required to authorize the transaction request comprises an indication of a biometric authentication of a user.
Radu - what the user is” (i.e., biometric data such as a fingerprint scan or a facial recognition scan) (¶ 0007, Wolfond).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the authorization of a transaction of Wolfond and processing of C. Radu with the biometric data of Radu because doing so promotes extra security to the transaction.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Chene et al. (US20180018665A1) - In a method for accessing a service, a device receives data. The device gets, based upon the received data, transaction data. The device signs the transaction data by using a private key relating to a transaction processing, a signature operation result being a transaction signature. The device generates a transaction analysis result. The device stores the transaction data and the transaction signature. The device analyses whether the transaction analysis result is or is not a transaction authorization. Only if the transaction analysis result is a transaction authorization, the device gets, based upon the received data, service data. The device sends to a first external entity the service data. The device sends the transaction data and the transaction signature to either the first external entity or a second external entity.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C whose telephone number is (571)270-7280. The examiner can normally be reached on Monday-Friday from 8am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick Mcatee, can be reached at telephone number 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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698