Acknowledgements
This communication is in response to applicant’s response filed on 02/18/2026.
Claims 1 and 11 have been amended.
Claims 1-20 are pending and have been examined.
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
Regarding applicant’s arguments:
Applicant’s arguments, see pgs. 9-11, filed 02/18/2026, with respect to the rejection(s) of claims 1 and 11 under Claim Rejections - 35 USC § 102(a)(2) that Aabye does not teach the amended limitations, specifically, “establishing a transport control protocol/internet protocol (TCP/IP) communication session with the CP upon connection of the EV to the CP, the TCP/IP communication session including a secure parallel communication session such that transaction information is communicated separately from a communication channel used to exchange EV charging information, the communication channel including an ISO 15118 communication session; receiving, via the TCP/IP communication session, transaction information from the CP, the transaction information including a CP identifier, a charge point operator identifier, an acquirer identifier, and a list of supported payment methods” have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is in view of Bae (US 20230001810) and in further view of Dubey (US 20230047717).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7, 10-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Aabye (WO 2024206244) in view of Bae (US 20230001810) in further view of Dubey (US 20230047717).
Regarding Claims 1 and 11, Aabye teaches storing a digital card identifier (ID) within a digital wallet of the EV, wherein the digital card ID is associated with a primary account number (PAN) associated with a payment account (Paragraphs 0037 and 0061 teach “payment credentials” may include information directly related to the account or may be derived from information related to the account; examples of account information may include a PAN (primary account number or “account number”); in-vehicle access application enables in-vehicle computing system to access resources for the vehicle; the in-vehicle access application may allow a user of vehicle to execute a transaction (e.g., a payment transaction) with a resource provider computer without requiring the user to use another device such as the user’s payment card or mobile device; in-vehicle access application may store account credentials or tokens, or reference identifiers thereof for various accounts, allow a user to select a particular account, and transmit the account credentials or tokens (or references identifiers thereof) associated with the selected account to a user device and/or server upon approval by the user); receiving, via the TCP/IP communication session, transaction information from the CP, the transaction information including a list of supported payment methods (Paragraphs 0094-0095 teach if the energy supply terminal does support an ISO 15118 type charging and communication session; at least three payment options can be presented to the user; the three payment options can include a third “plug and charge” option where a credential or token is received by the electricity supply terminal from the electric vehicle; the user can then choose a preferred option); selecting the digital card ID from the digital wallet based on the payment methods accepted by the CP (Paragraphs 0099-0100 teach the user may have chosen to perform payment via an ISO 15118 type charging and communication session, where a credential or token is transmitted from the electric vehicle to the electricity supply terminal); signing the transaction information using a private key associated with the EV (Paragraph 0100 teaches in the ISO 15118 type charging and communication session, the electric vehicle returns the payment information (e.g., encrypted payment information) to the energy supply terminal and the payment transaction is processed as described in further detail below); transmitting the signed transaction information, including the digital card ID, to the CP via the TCP/IP session (Paragraphs 0129 and 0131-0132 teach the credential or the token can be stored in a memory (such as a secure element) in the electric vehicle and can be obtained from the memory; in response to receiving the interaction details request, the electric vehicle can determine an amount of charge needed to fill the battery in the electric vehicle with electricity; the electric vehicle can generate an encrypted data packet by encrypting interaction data including at least the credential or token; prior to doing so, the electric vehicle 103 can verify that the mobility operator service provider digital certificate is valid and authentic; an authorization request message comprising the encrypted data packet, the challenge, and the signed challenge may be generated by the electric vehicle and then transmitted to the energy supply terminal); continuing a charging session setup in parallel by initiating an ISO 15118 communication session with the CP (Paragraphs 0113, 0132, 0134, and 0137-0139 teach a communication session can then be established between the electric vehicle, which may comprise a first processor and the energy supply terminal, which may comprise a second processor via the charging cable; the first processor in the electric vehicle and the second processor in the energy supply terminal can communicate using a protocol such as ISO 15118-20; the message that is used to transmit the encrypted data packet, the challenge, and the signed challenge can be in a data format compatible with ISO 15118; the service provider computer can decrypt the encrypted interaction data using a session key derived using an algorithm such as Elliptic Curve-Diffie Hellman with the private key of the service provider computer and the data supplied with the JWE created by the electric vehicle to obtain the credential or token, and the amount of electricity needed to fully charge the battery of the electric vehicle; the service provider computer can then process a transaction for supplying the electric vehicle with electricity using at least the credential or the token; if the amount of electrical charge is known, then the transaction amount for that charge is included in an authorization request message with the credential or token; the authorization request message generated by the service provider computer may also be converted to a different data format; the service provider computer may then process the authorization request message, which may include communicating with a processing network computer and an authorizing entity computer to authorize a payment; after the authorization request is processed, the service provider computer may receive an authorization response indicating whether or not the transaction is authorized from the processing network computer and the authorizing entity computer; the service provider computer can transmit the authorization request message to an authorizing entity computer operated by an issuer (e.g., via a transport computer operated by an acquirer and a processing network computer operated by a payment processing network) of an account associated with the credential or the token); monitoring for an authorization response received via the TCP/IP communication session (Paragraphs 0136 and 0141 teach the service provider computer may then process the authorization request message, which may include communicating with a payment processing network to authorize a payment; after the authorization request is processed, the service provider computer may transmit an authorization response to the energy supply terminal (e.g., which indicates if the interaction is authorized or is not authorized); the amount of the authorization request is then held in the user’s account; after receiving the authorization response message, the service provider computer and provide the authorization response message or may provide an authorization respond message in a different data format back to the energy supply terminal; the authorization response message may then be transmitted to the electric vehicle); and upon receiving a positive authorization response, permitting the CP to deliver charging power to the EV (Paragraph 0142-0143 teach after receiving the authorization response from the energy supply terminal, the electric vehicle may transmit a power delivery request to the energy supply terminal; the power delivery request may be a request to charge the electric vehicle; after receiving the power delivery request from the electric vehicle, the energy supply terminal may transmit a power delivery response to the electric vehicle; after receiving the power delivery response from the energy supply terminal, the electric vehicle may receive power from the energy supply terminal).
However, Aabye does not explicitly teach establishing a transport control protocol/internet protocol (TCP/IP) communication session with the CP upon connection of the EV to the CP, the TCP/IP communication session including a secure parallel communication session such that transaction information is communicated separately from a communication channel used to exchange EV charging information, the communication channel including an ISO 15118 communication session.
Bae from same or similar field of endeavor teaches establishing a transport control protocol/internet protocol (TCP/IP) communication session with the CP upon connection of the EV to the CP, the TCP/IP communication session including a secure parallel communication session such that transaction information is communicated separately from a communication channel used to exchange EV charging information, the communication channel including an ISO 15118 communication session (Paragraphs 0032-0038 teach referring to FIG. 2 the electric vehicle charging system of the present invention providing additional services is described in more details; the electric vehicle and the electric vehicle charger is connected to the TCP/IP (Translation Control Protocol/Internet Protocol) port through the charging cable for Power Line Communication (PLC), wherein, unlike the conventional method using a single TCP/IP port, another TCP/IP port is added in the present invention to use two TCP/IP ports; that is, by adding additional TCP/IP port for the PLC communication, an additional function for exchanging messages for providing additional services is further added in the electric vehicle charger; that is, as the driver or an electric vehicle charging station employee connects the charging cable or charging gun of the electric vehicle charger by inserting into the charging port of the electric vehicle, the PLC modem of the electric vehicle charger exchanges messages for charging through one TCP/IP port based on ISO 15118; the ISO 15118 is an international standard for defining the communication between the electric vehicle and the electric vehicle charger; in addition, the Plug & Charge (PnC) defines a technique for automatic authentication of the user for using the charging service; PnC is an automatic authentication technology that automatically processes all processes such as electric vehicle user authentication, charging, and billing).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Aabye to incorporate the teachings of Bae to establish a transport control protocol/internet protocol (TCP/IP) communication session with the CP upon connection of the EV to the CP, the TCP/IP communication session including a secure parallel communication session such that transaction information is communicated separately from a communication channel used to exchange EV charging information, the communication channel including an ISO 15118 communication session.
There is motivation to combine Bae into Aabye because by adding additional TCP/IP port for the PLC communication, an additional function for exchanging messages for providing additional services is further added in the electric vehicle charger (Bae Paragraph 0035).
However, the combination of Aabye and Bae does not explicitly teach receiving, via the TCP/IP communication session, transaction information from the CP, the transaction information including a CP identifier, a charge point operator identifier, and an acquirer identifier.
Dubey from same or similar field of endeavor teaches receiving, via the TCP/IP communication session, transaction information from the CP, the transaction information including a CP identifier, a charge point operator identifier, and an acquirer identifier (Paragraphs 0041 and 0047 teach various entities in the environment may connect to the network in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP); a customer makes a purchases and the POS terminal sends payment transaction details to the acquirer server; the acquirer server sends a payment transaction request to the server system or the payment server for routing the payment transaction to a card issuer associated with the customer; the payment transaction request includes a plurality of data elements such as a payment transaction identifier, a payment transaction amount, a payment transaction date/time, a payment transaction terminal identifier (i.e., CP identifier), merchant identification data such as, merchant name and location (i.e., charge point operator identifier), acquirer identifier etc.).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Aabye and Bae to incorporate the teachings of Dubey to receive, via the TCP/IP communication session, transaction information from the CP, the transaction information including a CP identifier, a charge point operator identifier, and an acquirer identifier.
There is motivation to combine Dubey into the combination of Aabye and Bae because the present disclosure allows improved matching of transactions associated with a particular merchant. In some embodiments, this improvement can result in enhanced tracking of transactions, particularly fraudulent transactions and fraud patterns. For example, fraud trends may not be as readily detectable without consistency in transaction data associated with a particular merchant (Dubey Paragraph 0038).
Regarding Claim 1, Aabye teaches a computer-implemented method performed by a user system associated with an electric vehicle (EV) for enabling a payment transaction for charging at a charge point (CP) (Paragraphs 0089 and 0112 teach the flowchart illustrated in FIG. 7 shows process steps that can be used in embodiments of the invention; in the method illustrated in FIG. 7, an electric vehicle can approach an electricity supply terminal to receive a charge; FIG. 10 shows a diagram and an overlaid process flow for perform a payment method where a credential or token is transmitted through a charging cable; the processes shown in FIG. 9 may be performed by the electric vehicle and an energy supply terminal (e.g., a charging station), and the processes shown in FIG. 10 can also include a service provider computer).
Regarding Claim 11, Aabye teaches a computing system for enabling a payment transaction for charging an electric vehicle (EV) at a charging point (CP), the system comprising: one or more processors; and a memory having computer-executable instructions stored thereon, that when executed by the one or more processors, cause the one or more processors to perform operations (Paragraphs 0165-0167 teach energy supply terminals need not be retrofit with specialized hardware or software for a user to conveniently obtain energy from energy supply terminals for the user’s vehicle; further, in the context of electric car charging, the user can simply “plug and go” when charging an electric vehicle; further, sensitive data such as payment credentials and payment tokens are protected as they are passed from the electric vehicle to a service provider computer; various services (e.g., for conducting payments) can be provided to the electric vehicle before the user charges their electric vehicle with electricity; these services can be matched with services compatible with those available to the electric vehicle, and only those services that are compatible with both the electric vehicle and the energy supply terminal will be presented to the user as options; software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like; the computer readable medium may be any combination of such storage or transmission devices; such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet; as such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs).
Regarding Claims 2 and 12, the combination of Aabye, Bae, and Dubey teaches all the limitations of claims 1 and 11 above; and Aabye further teaches binding the digital card ID to a public key associated with the EV via a binding API before initiating the transaction, the binding including: generating a public/private key pair (Paragraph 0078 teaches the certificate authority computer may issue a first sub-root key pair to the first sub-entity computer and can allow the first sub-entity operating the first sub-entity computer to issue electric vehicle digital certificates (or “contract certificates” pursuant to ISO 15118) to electric vehicles; for example, the first sub-entity computer may be operated by a mobility operator or a delegate of the mobility operator, and may issue a mobility operator electric vehicle digital certificate to the electric vehicle; the mobility operator electric vehicle digital certificate may comprise the electric vehicle public key, and the certificate or components thereof may be signed with a private key of the first sub-root key pair; the electric vehicle may also be provisioned with the root certificate from the certificate authority computer; the root certificate can be used by an external entity to validate the first sub-entity computer that issued the mobility operator electric vehicle digital certificate and that the mobility operator electric vehicle digital certificate is otherwise in good standing); transmitting the public key and the digital card ID to a secure remote commerce (SRC) system via the binding API (Paragraphs 0067-0070 teach a computer readable medium may comprise a credential / token management module may comprise code causes the processor to receive and store credentials and/or tokens in the data storage; the authentication module may comprise code that causes the processor to authenticate users, user devices, or vehicles used by users, before processing transactions; the cryptography module may comprise code that causes the processor to perform cryptographic operations including encryption, decryption, hashing, signing, signature verification, key generation, etc. ); and storing, by the SRC system, a binding relationship between the digital card ID and the public key in a database (Paragraph 0066 teaches the data storage can store any suitable data including but not limited to credentials and/or tokens, references to credentials and/or tokens, user data (e.g., usernames) or vehicle data (e.g., VINs) associated with the credentials or tokens, etc.).
Regarding Claims 3 and 13, the combination of Aabye, Bae, and Dubey teaches all the limitations of claims 1 and 11 above; and Aabye further teaches user system simultaneously managing the TCP/IP communication session for payment transaction communication, and the ISO 15118 communication session for energy transfer negotiation, wherein both sessions operate in parallel (Paragraph 0113 teaches the first processor in the electric vehicle and the second processor in the energy supply terminal can communicate using a protocol such as ISO 15118 (e.g., ISO 15118-20)).
Regarding Claims 4 and 14, the combination of Aabye, Bae, and Dubey teaches all the limitations of claims 1 and 11 above; and Aabye further teaches the operation of selecting the digital card ID including automatically selecting the digital card ID based on preconfigured user preferences and merchant compatibility criteria without requiring user input (Paragraphs 0083 and 0122 teaches the electric vehicle and the energy supply terminal can communicate with each other using a protocol such as ISO-15118 protocol and can automatically negotiate multiple charge session parameters, including how to pay for the charge session; this selection could be performed automatically by the electric vehicle based on pre-established consumer preferences).
Regarding Claims 5 and 15, the combination of Aabye, Bae, and Dubey teaches all the limitations of claims 1 and 11 above; and Aabye further teaches receiving, from the CP, a payment detail response message including a challenge for cryptographic validation (Paragraph 0127 teaches if the energy supply terminal determines that the mobility operator electric vehicle digital certificate is valid, then it can transmit an interaction details response comprising a challenge to the electric vehicle; the challenge may be a string of random numbers.); bundling the digital card ID and the challenge into an authorization request (Paragraphs 0127 and 0132 teach the electric vehicle may thereafter form a signed challenge by signing the challenge using a private key associated with a public key in the mobility operator electric vehicle digital certificate; the electric vehicle can generate an encrypted data packet by encrypting interaction data including at least the credential or token, and (optionally) the amount of electricity needed to fully charge the battery of the electric vehicle, with a session key derived using an algorithm such as Elliptic Curve-Diffie Hellman, with the service provider public key obtained from the mobility operator service provider digital certificate; prior to doing so, the electric vehicle can verify that the mobility operator service provider digital certificate is valid and authentic; the electric vehicle can generate the encrypted data packet, the challenge, and the signed challenge may be generated by the electric vehicle); signing the authorization request using the private key (Paragraph 0132 teaches then, an authorization request message comprising the encrypted data packet, the challenge, and the signed challenge may be generated by the electric vehicle and then transmitted to the energy supply terminal); and transmitting the signed authorization request to the CP (Paragraph 0132 teaches the message that is used to transmit the encrypted data packet, the challenge received, and the signed challenge can be in a data format compatible with ISO 15118).
Regarding Claims 6 and 16, the combination of Aabye, Bae, and Dubey teaches all the limitations of claims 1 and 11 above; and Aabye further teaches the digital card ID comprising a tokenized representation of a primary account number (PAN) (Paragraph 0061 and 0140 teach in-vehicle access application may store account credentials or tokens, or reference identifiers thereof for various accounts, allow a user to select a particular account, and transmit the account credentials or tokens (or references identifiers thereof) associated with the selected account to a user device and/or server upon approval by the user; if the authorization request message comprises a token, instead of a credential such as a PAN, the processing network computer can detokenize the token into a real PAN and can replace the token with the real PAN before transmitting the authorization request message to the authorizing entity computer).
Regarding Claims 7 and 17, the combination of Aabye, Bae, and Dubey teaches all the limitations of claims 1 and 11 above; and Aabye further teaches the operation of signing the transaction information comprises applying a digital signature using an asymmetric key pair (Paragraphs 0032 and 0132 teach a “digital signature” may include an electronic signature for a message; a digital signature may be a unique data value generated from a message (or data packet) and a private key using a cryptographic algorithm; a validation algorithm using a public key may be used to verify the signature; a digital signature may be used to demonstrate the veracity of the sender; an authorization request message comprising the encrypted data packet, the challenge, and the signed challenge may be generated by the electric vehicle and then transmitted to the energy supply terminal; the message that is used to transmit the encrypted data packet, the challenge received, and the signed challenge can be in a data format compatible with ISO 15118).
Regarding Claims 10 and 20, the combination of Aabye, Bae, and Dubey teaches all the limitations of claims 1 and 11 above; and Aabye further teaches transmitting an authorization request message to the CP specifying a selected authorization service supported by the CP (Paragraphs 0099 and 0134 teach the user may have chosen to perform payment via an ISO 15118 type charging and communication session, where a credential or token is transmitted from the electric vehicle to the electricity supply terminal; the service provider computer can decrypt the encrypted interaction data using a session key derived using an algorithm such as Elliptic Curve-Diffie Hellman with the private key of the service provider computer and the data supplied with the JWE created by the electric vehicle to obtain the credential or token, and the amount of electricity needed to fully charge the battery of the electric vehicle; the service provider computer 108 can then process a transaction for supplying the electric vehicle with electricity using at least the credential or the token).
Claims 8-9 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Aabye (WO 2024206244) in view of Bae (US 20230001810) in further view of Dubey (US 20230047717) in further view of NPL reference “Smart and secure EV Charging with NXP secure solutions.”
Regarding Claims 8 and 18, the combination of Aabye, Bae, and Dubey teaches all the limitations of claims 1 and 11 above; however, the Aabye does not explicitly teach the operation of establishing a TCP/IP communication session comprises establishing a mutually authenticated and encrypted communication session with the CP via a transport layer security (TLS) protocol.
NPL reference “Smart and secure EV Charging with NXP secure solutions” from same or similar field of endeavors teaches the operation of establishing a TCP/IP communication session comprises establishing a mutually authenticated and encrypted communication session with the CP via a transport layer security (TLS) protocol (Page 10 Sec. 3.1.1 the ISO 15118 Plug & Charge features teaches upon connection of the EV to the EVSE, a TLS handshake is initiated between the two entities; first, the EV sends to the EVSE a list of trusted CA certificates (e.g., including V2G Root CA 1 whose certificate must be pre-provisioned in the EV)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Aabye, Bae, and Dubey to incorporate the teachings of NPL reference “Smart and secure EV Charging with NXP secure solutions” for the operation of establishing a TCP/IP communication session to comprise establishing a mutually authenticated and encrypted communication session with the CP via a transport layer security (TLS) protocol.
There is motivation to combine NPL reference “Smart and secure EV Charging with NXP secure solutions” into the combination of Aabye, Bae, and Dubey because TLS protocol provides a way for authenticating and authorizing EVs for a charging session using only digital certificates and signatures (Page 10).
Regarding Claims 9 and 19, the combination of Aabye, Bae, and Dubey teaches all the limitations of claims 8 and 18 above; however, the Aabye does not explicitly teach the operation of establishing the mutually authenticated and encrypted communication session comprises using mutual TLS (mTLS) authentication, including transmitting a user system digital certificate to the CP and receiving a CP digital certificate.
NPL reference “Smart and secure EV Charging with NXP secure solutions” from same or similar field of endeavors teaches the operation of establishing the mutually authenticated and encrypted communication session comprises using mutual TLS (mTLS) authentication, including transmitting a user system digital certificate to the CP and receiving a CP digital certificate (Page 17 teaches mutual TLS: contrary to ISO 15118-2 where only the EVSE authenticates with the EV, in ISO 15118-20 a mutual TLS authentication must be performed, i.e. the EV must authenticate the EVSE and the EVSE must authenticate the EV; this is done using credentials and certificates that are securely injected and stored in both the EV and the EVSE).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Aabye, Bae, and Dubey to incorporate the teachings of NPL reference “Smart and secure EV Charging with NXP secure solutions” for the operation of establishing the mutually authenticated and encrypted communication session to comprise using mutual TLS (mTLS) authentication, including transmitting a user system digital certificate to the CP and receiving a CP digital certificate.
There is motivation to combine NPL reference “Smart and secure EV Charging with NXP secure solutions” into the combination of Aabye, Bae, and Dubey because data is properly encrypted before it is sent over the network, so only intended recipients can read the data (Page 8).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ibrahim (US 20190378220) teaches a system and method for automated remote payments between a vehicle and a refueling station is disclosed. The system may enable the vehicle to initiate an automated remote payment to the refueling station without needing the user to manually input transaction account information, or to manually prepay for the transaction. The refueling station may detect when the vehicle is in proximity, and the vehicle and the refueling station may open communications to transmit data. The vehicle may transmit vehicle identifying data to the refueling station, and the refueling station may communicate the vehicle identifying data to a payment network to authorize the transaction. In response to authorizing the transaction, the vehicle may proceed with refueling at the refueling station.
Diaz et al. (US 20180186245) teaches system for managing a charging points network comprising a management server, a database for storing information related to the charging points, of said network, providing energy to electric vehicles, a hardware and software architecture comprising set of modules for the management of users and the configuration of charging points or charging points park, a memory for storing data and a processor for executing a program stored in the memory to implement the functionalities of each module, said management system providing an interface for a charging point operator in order to manage and configure its own charging points network and a user interface, said user interface comprising communication tools allowing the user to choose a type of connector and a type of charging point protocol, corresponding to a given vehicle, from the charging point operator infrastructure.
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 COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of 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.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699