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, 2, 8, 9, 15 and 16 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 .
Response to Arguments
Response to U.S.C. 103
Applicant's arguments filed 05/19/2026 in regards to the U.S.C. 103 rejection have been fully considered and are partially persuasive. Although Wolfond alone does not teach the newly amended limitation requiring the remote payment application to establish a cryptographically protected channel with and authenticate the merchant system kernel, a new prior art reference was found to teach this limitation in combination of the previous prior art references. Please see the 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 and in further view of Collinge (US20200302441A1) hereinafter Collinge.
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 payment application uniform resource identifier ("URI") from the mobile device, the payment application URI comprising a string of characters identifying a storage location of a remote 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). transaction server generates a transaction identifier (Abstract, Wolfond). Transaction server may validate the initialization information and store it for future use (¶ 0049).
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).
invoking, by the processor in electronic communication with a payment application server, the remote payment application based at least in part on sending the payment token and the 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).
receiving, by the processor, a transaction data request for additional information 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).
transmitting, by the processor, a transaction data request to the mobile device, including a request for additional information; and
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).
transmitting, by the processor, a transaction authorization notice to the merchant application.
Wolfond - If the payment was successful, in response to the transaction authorization, transaction server 120 directly or indirectly sends notifications (e.g., e-mail, push notifications, etc.) to both customer device 140 and merchant device 110, at 250, to complete the transaction (¶ 0062). The merchant can be notified of the amount paid by the customer and whether the payment was accepted or rejected (¶ 0063). 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 does not teach, however C. Radu discloses:
invoking the remote payment application comprises a merchant system kernel of the merchant checkout system interacting with the remote 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 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 application keys on merchant endpoints.
The combination of Wolfond and C. Radu does not discloses, however Collinge discloses:
the remote payment application establishing a cryptographically protected channel with the merchant system kernel system for authenticating the merchant system kernel and to process the transaction request;
Collinge - the merchant identity and using the merchant identity and the transaction seed data to generate a cryptogram for the tokenised transaction; and the payment offering party providing the cryptogram to the payment accepting party for transmission to the transaction scheme provider for authorisation of the tokenised transaction (¶ 0009). (the merchant) has been provided with a merchant identity and a merchant certificate associated with that identity by the transaction scheme provider (¶ 0046). Authenticated delivery of information can be used to improve the security of the payment solution and may be used further for channel locking (¶ 0068). The wallet to authenticate the merchant (¶ 0071). the merchant can drive the user experience of the wallet while delivering information in a secure way between the merchant and the wallet (¶ 0077). The successful validation of the transaction is used to confirm that the merchant is a genuine merchant eligible to receive a Merchant Certificate (¶ 0087). The payment offering party validating the merchant identity and using the merchant identity and the transaction seed data to generate a cryptogram for the tokenised transaction (Claim 1).
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 and the payment processing remotely of C. Radu with the cryptographic merchant authentication technique of Collinge because doing so increases security of the remote payment processing channel by preventing an unauthorized or spoofed merchant system from participating transaction data exchanged during remote processing.
Regarding Claims 2, 9, and 16. The combination of Wolfond, C. Radu, and Collinge further discloses:
The method of claim 1, system of claim 8, and the non-transitory computer-readable medium of claim 15, wherein transmitting the transaction data request to the mobile device is further based at least in part on an instruction from the remote payment application.
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, C. Radu, and Collinge 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, C. Radu, and Collinge further discloses:
The method of claim 1, system of claim 8, and the non-transitory computer-readable medium of claim 15, wherein the remote 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, C. Radu, and Collinge 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, C. Radu, and Collinge further discloses:
The method of claim 1, system of claim 8, and the non-transitory computer-readable medium of claim 15, wherein the remote 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 payment application URI comprising a string of characters identifying a storage location of a remote 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). transaction server generates a transaction identifier (Abstract, Wolfond). Transaction server may validate the initialization information and store it for future use (¶ 0049).
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).
invoke a remote 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 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).
receive a transaction data request for additional information to authorize the transaction request, in response to a determination by the remote 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; and
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).
transmit a transaction authorization notice to the merchant application.
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).
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 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).
the remote payment application establishing a cryptographically protected channel with the merchant system kernel […]
Wolfond - data communications may use Transport Layer Security (TLS) to encrypt and secure communications (¶ 0031).
Wolfond does not teach, however C. Radu discloses:
invoking the remote payment application comprises a system kernel of the merchant checkout system interacting with the remote 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 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 application keys on merchant endpoints.
The combination of Wolfond and C. Radu does not discloses, however Collinge discloses:
[…] for authenticating the merchant system kernel and to process the transaction request;
Collinge - the merchant identity and using the merchant identity and the transaction seed data to generate a cryptogram for the tokenised transaction; and the payment offering party providing the cryptogram to the payment accepting party for transmission to the transaction scheme provider for authorisation of the tokenised transaction (¶ 0009). (the merchant) has been provided with a merchant identity and a merchant certificate associated with that identity by the transaction scheme provider (¶ 0046). the payment offering party validating the merchant identity and using the merchant identity and the transaction seed data to generate a cryptogram for the tokenised transaction (Claim 1).
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 and the payment processing remotely of C. Radu with the cryptographic merchant authentication technique of Collinge because doing so increases security of the remote payment processing channel by preventing an unauthorized or spoofed merchant system from participating transaction data exchanged during remote processing.
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 payment application URI comprising a string of characters identifying a storage location of a remote 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). transaction server generates a transaction identifier (Abstract). Transaction server may validate the initialization information and store it for future use (¶ 0049).
invoke a remote payment application based at least in part on sending the payment token and the 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).
obtain a transaction data request for additional information 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).
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).
transmit a transaction authorization notice to a merchant 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).
the remote payment application establishing a cryptographically protected channel with the merchant system kernel […]
Wolfond - data communications may use Transport Layer Security (TLS) to encrypt and secure communications (¶ 0031).
Wolfond does not teach, however C. Radu discloses:
invoking the remote payment application comprises a merchant system kernel of the merchant checkout system interacting with the remote 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 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 application keys on merchant endpoints.
The combination of Wolfond and C. Radu does not disclose, however Collinge discloses:
[…] for authenticating the merchant system kernel and to process the transaction request;
Collinge - the merchant identity and using the merchant identity and the transaction seed data to generate a cryptogram for the tokenised transaction; and the payment offering party providing the cryptogram to the payment accepting party for transmission to the transaction scheme provider for authorisation of the tokenised transaction (¶ 0009). (the merchant) has been provided with a merchant identity and a merchant certificate associated with that identity by the transaction scheme provider (¶ 0046). the payment offering party validating the merchant identity and using the merchant identity and the transaction seed data to generate a cryptogram for the tokenised transaction (Claim 1).
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 and the payment processing remotely of C. Radu with the cryptographic merchant authentication technique of Collinge because doing so increases security of the remote payment processing channel by preventing an unauthorized or spoofed merchant system from participating transaction data exchanged during remote processing.
Regarding Claim 21. The combination of Wolfond, C. Radu, and Collinge 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 and the payment processing remotely of C. Radu with the cryptographic merchant authentication technique of Collinge because doing so increases security of the remote payment processing channel by preventing an unauthorized or spoofed merchant system from participating transaction data exchanged during remote processing.
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, C. Radu, and Collinge 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 skilled of the art before the effective filing date of the claim invention to modify the merchant checkout flow of Wolfond and the payment processing remotely of C. Radu and the cryptographic merchant authentication technique of Collinge
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.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 CHRISTINA C STEVENSON 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
Prosecution Insights