DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. Claims 1-20 are pending on this application. Claims 1, 12, and 19 are in independent forms.
Priority
3. Foreign priority has been claimed to KR application # 10-2023-0180265 filed on 12/13/2023.
Information Disclosure Statement
4. The information disclosure statements (IDS's) submitted on 11/14/2024 is in compliance with provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
5. The drawings are objected to because they fail to show necessary textual labels of features or symbols in drawing Figure 1 as described in the Patent Application Publication (2025/0202871 A1). For example, placing a label, " symmetric key generation unit", with element 110 of Fig. 1 “a symmetric key processing unit”, with element 120 of Fig. 1,“symmetric key”, with element 112 of Fig. 1 “ transmission unit ”, with element 201 of Fig. 1 “ reception unit”, with element 202 of drawing Figures 1, “The key derivation function (KDF)”, with element 111 of Fig. 1 “ “input secret key”, with element 114 of Fig. 2 “an application layer” with element 210 of Fig. 3 “a plurality of ECUs” with elements 200-1, 200-2, 200-3 of Fig. 4, etc., would give the viewer necessary detail to fully understand this element at a glance. A descriptive textual label for each numbered element in these drawing Figures would be needed to better understand these figures without substantial analysis of the detailed specification. Any structural detail that is of sufficient importance to be described should be labeled in the drawing.
Claim Rejections - 35 USC § 103
6. 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.
7. Claims 1-5, 12, 14-16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Herzerg et al. US Patent Application Publication No. 2020/0007319 (hereinafter Herzerg) in view of Schaap US Patent Application Publication No. 2020/0153625 (hereinafter Schaap).
Regarding claim 1, Herzerg discloses a vehicle network security system using symmetric keys derived based on time synchronization (FIG. 1A is a diagram of an example system 100 for providing robust end-to-end communication security that is able to establish and maintain synchronization of shared secrets 110a-b between example controllers 106a-b that communicate over an example network 102.), the vehicle network security system comprising:
a symmetric key generation unit (Fig. 2, key generator 230, par. 0042, the security middleware layer 228 includes a key generator 230 that is programmed to generate symmetric keys) configured to:
“generate a symmetric key shared by a transmission unit configured to transmit data and a reception unit configured to receive data” (see Herzerg Fig. 4, pars. 0056-0058, FIG. 4 illustrates an example system 400 for sending a message from a sending controller 401 to a receiving controller 402. The controllers 401-402 can be any of a variety of controllers, such as the controllers 106a-b described above with regard to FIG. 1A, the ECUs 156a-n described above with regard to FIG. 1B, the controller 202 described above with regard to FIG. 2, and/or the ECUs described above with regard to FIG. 3. FIG. 4 depicts an example encoding and authentication process that uses synchronized shared secrets among the sender controller 401 and the receiver controller 402, which in this example includes synchronized counters 410 and 432, synchronized keys 414 and 436, and other synchronized keys 412 and 434. Both the sender 401 and the recipient 402 can also both maintain keys 412 and 434, and keys 414 and 436 that are synchronized. The synchronization of these (and/or other) shared secrets can be used by the sender 401 and the receiver 402 to effectively encode/decode and authenticate messages. ); and
“store the symmetric key in a specific slot” (see Herzerg par. 0036, The shared secrets 110a-b and 160a-n, for example, can be generated based on other values that are persistently stored by the controllers 106a-b and ECUs 156a-n, such as being generated from public keys of the other controllers/ECUs that are be stored locally in communication tables that are created in secure environments and stored by the controllers/ECUs); and
Herzerg does not explicitly discloses a symmetric key processing unit configured to call the symmetric key in the specific slot to transmit and receive data when an application software program creates an encryption or decryption session, wherein the symmetric key is generated using a factor synchronized with time data transferred from a hardware clock (HC) included in electronic control units (ECUs) in a vehicle network.
However, in analogues art, Schaap discloses a symmetric key processing unit configured to call the symmetric key in the specific slot to transmit and receive data when an application software program creates an encryption or decryption session, wherein the symmetric key is generated using a factor synchronized with time data transferred from a hardware clock (HC) included in electronic control units (ECUs) in a vehicle network (see Schaap Figs. 5A-5C, pars 0047-0056, in step 565 with a first circuit (e.g., HSM 130A) storing a first key (e.g., a provisioned key 152) usable to encrypt data. In step 570, the first circuit receives, from a second circuit (e.g., HSM 130B), an encrypted portion (e.g., MAC 450) of a first packet and a first timestamp (e.g., Packet ID 420) included in the first packet. In various embodiments, a first network node (e.g., node 120A) coupled to the first circuit receives the first packet and requests that the first circuit decrypt the encrypted portion of the first packet. In some embodiments, the first network node is an electronic control unit (ECU) configured to receive the first packet over a vehicle network. In step 575, the first circuit generates a second key (e.g., HSM key 136) based on the first key and a portion of the first timestamp (e.g., after application of mask 320). In some embodiments, the first circuit includes a first local clock, and synchronizes the first local clock with a reference clock. In such an embodiment, the second circuit has a second local clock, and synchronizes the second local clock with the reference clock. The second circuit then generates the first timestamp based on the synchronized second clock. In step 580, the first circuit decrypts the encrypted portion using the second key).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Schaap in to the system of Herzerg in order to include a synchronized time value based on the local time value, the synchronized time value being an expected time value of a reference clock. The first circuit generates a first encryption key by calculating a key derivation function based on the synchronized time value and encrypts a portion of a packet using the first encryption key (see Schaap par. 0003).
Regarding claims 2 and 14, Herzerg in view of Schaap discloses the vehicle network security system of claim 1, the vehicle network security communication method of claim 13,
Schaap further discloses wherein the symmetric key is generated through a key derivation function (KDF) (see Schaap par. 0026, a given HSM 130 is configured to generate keys 134 and 136 by calculating a key derivation function based on a synchronized time value determined from a sync communication 144).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Schaap in to the system of Herzerg in order to include a synchronized time value based on the local time value, the synchronized time value being an expected time value of a reference clock. The first circuit generates a first encryption key by calculating a key derivation function based on the synchronized time value and encrypts a portion of a packet using the first encryption key (see Schaap par. 0003).
Regarding claims 3 and 15, Herzerg in view of Schaap discloses the vehicle network security system of claim 2, the vehicle network security communication method of claim 14,
Schaap further discloses wherein the KDF is operated on parameters including an input secret key, a salt parameter, a difficulty level parameter, and a key size (see Schaap par. 0030, a network session may rely on the same salt for the entire session. Thus, if any rollover occurs during the session, the new keys can be derived using the previously established salt and the value of synchronized time when the rollover is to occur).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Schaap in to the system of Herzerg in order to include a synchronized time value based on the local time value, the synchronized time value being an expected time value of a reference clock. The first circuit generates a first encryption key by calculating a key derivation function based on the synchronized time value and encrypts a portion of a packet using the first encryption key (see Schaap par. 0003).
Regarding claims 4 and 16, Herzerg in view of Schaap discloses the vehicle network security system of claim 3, the vehicle network security communication method of claim 15,
Schaap further discloses wherein the salt parameter is obtained through the factor synchronized with the time data (see Schaap par. 0029, in some embodiments, this provided information may include a key identifier, which may correspond to a salt used to derive the keys 134 and 136. This information may also include the synchronized time value used to derive the keys 134 and 136. Accordingly, when a recipient node 120 receives an encrypted packet, the node 120 may provide this information to its HSM 130, which, in some embodiments, uses this information along with a provisioned key 152 to derive the keys 134 and 136 used to decrypt the packet).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Schaap in to the system of Herzerg in order to include a synchronized time value based on the local time value, the synchronized time value being an expected time value of a reference clock. The first circuit generates a first encryption key by calculating a key derivation function based on the synchronized time value and encrypts a portion of a packet using the first encryption key (see Schaap par. 0003).
Regarding claim 5, Herzerg in view of Schaap discloses the vehicle network security system of claim 1,
Herzerg further discloses wherein an ECU, among the ECUs in the vehicle network, includes an application layer including an application software program, a hardware layer including a hardware configuration, and an adaptive platform layer for interaction between the application layer and the hardware layer (see Herzerg pars. 0040-0041, The controller 202 includes an application layer 224 at which one or more applications operate on the controller 202 through use of an operating system 226 for the controller 200. The operating system 204 includes a kernel 238 and a security middleware layer 228, which can implement end-to-end communication security for communication requests transmitted from the application layer 224 to the kernel 238, such as communication requests to the other controllers 264a-n. The kernel 238 includes processes and functions that provide an interface for the operating system 226 to perform operations on the controller 202 using hardware, which includes one or more processors 204 (e.g., CPUs), memory 206 (e.g., volatile memory, non-volatile memory, RAM), and input/output (I/O) network components 222 (e.g., wired and wireless network cards/chip sets, network interface cards (MC))).
Regarding claim 12, Herzerg discloses a vehicle network security communication method using symmetric keys derived based on time synchronization, the vehicle network security communication method comprising:
“generating a symmetric key shared by a transmission unit configured to transmit data and a reception unit configured to receive data” (see Herzerg Fig. 4, pars. 0056-0058, FIG. 4 illustrates an example system 400 for sending a message from a sending controller 401 to a receiving controller 402. The controllers 401-402 can be any of a variety of controllers, such as the controllers 106a-b described above with regard to FIG. 1A, the ECUs 156a-n described above with regard to FIG. 1B, the controller 202 described above with regard to FIG. 2, and/or the ECUs described above with regard to FIG. 3. FIG. 4 depicts an example encoding and authentication process that uses synchronized shared secrets among the sender controller 401 and the receiver controller 402, which in this example includes synchronized counters 410 and 432, synchronized keys 414 and 436, and other synchronized keys 412 and 434. Both the sender 401 and the recipient 402 can also both maintain keys 412 and 434, and keys 414 and 436 that are synchronized. The synchronization of these (and/or other) shared secrets can be used by the sender 401 and the receiver 402 to effectively encode/decode and authenticate messages);
“storing the symmetric key in a specific slot” (see Herzerg par. 0036, The shared secrets 110a-b and 160a-n, for example, can be generated based on other values that are persistently stored by the controllers 106a-b and ECUs 156a-n, such as being generated from public keys of the other controllers/ECUs that are be stored locally in communication tables that are created in secure environments and stored by the controllers/ECUs); and
Herzerg does not explicitly discloses calling the symmetric key in the specific slot to transmit and receive data when an application software program creates an encryption or decryption session, wherein the symmetric key is generated using a factor synchronized with time data transferred from a hardware clock (HC) included in a hardware layer of electronic control units (ECUs) in a vehicle network.
However, in analogues art, Schaap discloses calling the symmetric key in the specific slot to transmit and receive data when an application software program creates an encryption or decryption session, wherein the symmetric key is generated using a factor synchronized with time data transferred from a hardware clock (HC) included in a hardware layer of electronic control units (ECUs) in a vehicle network (see Schaap Figs. 5A-5C, pars 0047-0056, in step 565 with a first circuit (e.g., HSM 130A) storing a first key (e.g., a provisioned key 152) usable to encrypt data. In step 570, the first circuit receives, from a second circuit (e.g., HSM 130B), an encrypted portion (e.g., MAC 450) of a first packet and a first timestamp (e.g., Packet ID 420) included in the first packet. In various embodiments, a first network node (e.g., node 120A) coupled to the first circuit receives the first packet and requests that the first circuit decrypt the encrypted portion of the first packet. In some embodiments, the first network node is an electronic control unit (ECU) configured to receive the first packet over a vehicle network. In step 575, the first circuit generates a second key (e.g., HSM key 136) based on the first key and a portion of the first timestamp (e.g., after application of mask 320). In some embodiments, the first circuit includes a first local clock, and synchronizes the first local clock with a reference clock. In such an embodiment, the second circuit has a second local clock, and synchronizes the second local clock with the reference clock. The second circuit then generates the first timestamp based on the synchronized second clock. In step 580, the first circuit decrypts the encrypted portion using the second key).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Schaap in to the system of Herzerg in order to include a synchronized time value based on the local time value, the synchronized time value being an expected time value of a reference clock. The first circuit generates a first encryption key by calculating a key derivation function based on the synchronized time value and encrypts a portion of a packet using the first encryption key (see Schaap par. 0003).
Regarding claim 19, Herzerg discloses a vehicle network security device using symmetric keys derived based on time synchronization, the vehicle network security device comprising:
a symmetric key generation unit (Fig. 2, key generator 230, par. 0042, the security middleware layer 228 includes a key generator 230 that is programmed to generate symmetric keys) configured to:
“generate a symmetric key shared by a transmission unit configured to transmit data and a reception unit configured to receive data” (see Herzerg Fig. 4, pars. 0056-0058, FIG. 4 illustrates an example system 400 for sending a message from a sending controller 401 to a receiving controller 402. The controllers 401-402 can be any of a variety of controllers, such as the controllers 106a-b described above with regard to FIG. 1A, the ECUs 156a-n described above with regard to FIG. 1B, the controller 202 described above with regard to FIG. 2, and/or the ECUs described above with regard to FIG. 3. FIG. 4 depicts an example encoding and authentication process that uses synchronized shared secrets among the sender controller 401 and the receiver controller 402, which in this example includes synchronized counters 410 and 432, synchronized keys 414 and 436, and other synchronized keys 412 and 434. Both the sender 401 and the recipient 402 can also both maintain keys 412 and 434, and keys 414 and 436 that are synchronized. The synchronization of these (and/or other) shared secrets can be used by the sender 401 and the receiver 402 to effectively encode/decode and authenticate messages); and
“store the symmetric key in a specific slot” (see Herzerg par. 0036, The shared secrets 110a-b and 160a-n, for example, can be generated based on other values that are persistently stored by the controllers 106a-b and ECUs 156a-n, such as being generated from public keys of the other controllers/ECUs that are be stored locally in communication tables that are created in secure environments and stored by the controllers/ECUs); and
Herzerg does not explicitly discloses a symmetric key processing unit configured to call the symmetric key in the specific slot to transmit and receive data when an application software program creates an encryption or decryption session” wherein: the symmetric key is generated using a factor synchronized with time data transferred from a hardware clock (HC) included in electronic control units (ECUs) in a vehicle network.
However, in analogues art, Schaap discloses a symmetric key processing unit configured to call the symmetric key in the specific slot to transmit and receive data when an application software program creates an encryption or decryption session” wherein: the symmetric key is generated using a factor synchronized with time data transferred from a hardware clock (HC) included in electronic control units (ECUs) in a vehicle network (see Schaap Figs. 5A-5C, pars 0047-0056, in step 565 with a first circuit (e.g., HSM 130A) storing a first key (e.g., a provisioned key 152) usable to encrypt data. In step 570, the first circuit receives, from a second circuit (e.g., HSM 130B), an encrypted portion (e.g., MAC 450) of a first packet and a first timestamp (e.g., Packet ID 420) included in the first packet. In various embodiments, a first network node (e.g., node 120A) coupled to the first circuit receives the first packet and requests that the first circuit decrypt the encrypted portion of the first packet. In some embodiments, the first network node is an electronic control unit (ECU) configured to receive the first packet over a vehicle network. In step 575, the first circuit generates a second key (e.g., HSM key 136) based on the first key and a portion of the first timestamp (e.g., after application of mask 320). In some embodiments, the first circuit includes a first local clock, and synchronizes the first local clock with a reference clock. In such an embodiment, the second circuit has a second local clock, and synchronizes the second local clock with the reference clock. The second circuit then generates the first timestamp based on the synchronized second clock. In step 580, the first circuit decrypts the encrypted portion using the second key).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Schaap in to the system of Herzerg in order to include a synchronized time value based on the local time value, the synchronized time value being an expected time value of a reference clock. The first circuit generates a first encryption key by calculating a key derivation function based on the synchronized time value and encrypts a portion of a packet using the first encryption key (see Schaap par. 0003).
Herzerg in view of Schaap does not explicitly discloses a hardware clock of the transmission unit and a hardware clock of the reception unit have a time error value of 100 nanoseconds (ns) or less by using the factor synchronized with the time data.
However, in analogues art, Manevich discloses a hardware clock of the transmission unit and a hardware clock of the reception unit have a time error value of 100 nanoseconds (ns) or less by using the factor synchronized with the time data (see Manevich par. 0047, The monitoring device may be used to build physical layer clock syntonization test equipment, e.g., SyncE test equipment, by using commodity hardware of a network device to monitor clock synchronization over time. The test equipment of the monitoring device may be used to generate test equipment data, such as plotting a graph of the time error between the systems over time. The data can further be analyzed and used for validation of the different clock synchronization standards. For example, a standard may dictate that the time error accumulated in every 1000 second window should not be greater than 10 nanoseconds).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Manevich in to the system of Herzerg and Schaap in order to provide a monitoring device to monitor the accumulated time error of the monitored device at any given moment (see Manevich par. 0043).
8. Claims 6-7, 10-11, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Herzerg et al. US Patent Application Publication No. 2020/0007319 (hereinafter Herzerg) in view of Schaap US Patent Application Publication No. 2020/0153625 (hereinafter Schaap) in further view of Manevich et al. US Patent Application Publication No. 2025/0105938 (hereinafter Manevich).
Regarding claim 6, Herzerg in view of Schaap discloses the vehicle network security system of claim 5,
Schaap in view of Schaap does not explicitly discloses the hardware clock is included in the hardware layer; and the hardware clock includes a hardware clock for an Ethernet-based precision time protocol (PTP).
However, in analogues art, Manevich discloses the hardware clock (Fig. 1, Hardware Clock 28) is included in the hardware layer (see Manevich par. 0050, The monitoring device 12 includes an interface 22, one or more counters 24, synchronization circuitry 26, a hardware clock 28, and processing circuitry 30); and the hardware clock includes a hardware clock for an Ethernet-based precision time protocol (PTP) (see Manevich par. 0004, Precision Time Protocol (PTP), which is a packet-based protocol that may be used with SyncE to align offset (e.g., in Coordinated Universal Time (UTC) format) and phase between two clocks. It should be noted that PTP may be used alone over Ethernet (without SyncE), but this is typically used for lower accuracy use cases. PTP is used to synchronize clocks throughout a computer network, and is considered to be the de facto standard for this purpose).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Manevich in to the system of Herzerg and Schaap in order to include a clock(s) of the monitored device(s) may be synchronized to the clock of the monitoring device using a given clock synchronization method, such as SyncE and/or PTP or Precision Time Measurement (PTM) (see Manevich par. 0036).
Regarding claim 7, Herzerg in view of Schaap in further view of Manevich discloses the vehicle network security system of claim 5,
Manevich further discloses wherein the factor synchronized with the time data is acquired by using a pulse per second (PPS) signal (see Manevich par. 0051, The synchronization circuitry 26 may be configured to discipline the hardware clock 28 from a pulse per second signal received from a Global navigation satellite system (GNSS) receiver 32 or from any suitable device, such as a device 33 (for example, a networking device or another device connected to monitoring device 12 via one of the communication links 18) including a hardware clock 35).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Manevich in to the system of Herzerg and Schaap in order to include a clock(s) of the monitored device(s) may be synchronized to the clock of the monitoring device using a given clock synchronization method, such as SyncE and/or PTP or Precision Time Measurement (PTM) (see Manevich par. 0036).
Regarding claim 10, Herzerg in view of Schaap discloses the vehicle network security system of claim 1,
Herzerg in view of Schaap does not explicitly discloses wherein a hardware clock of the transmission unit and a hardware clock of the reception unit have a time error value of 100 nanoseconds (ns) or less by using the factor synchronized with the time data.
However, in analogues art, Manevich discloses wherein a hardware clock of the transmission unit and a hardware clock of the reception unit have a time error value of 100 nanoseconds (ns) or less by using the factor synchronized with the time data (see Manevich par. 0047, The monitoring device may be used to build physical layer clock syntonization test equipment, e.g., SyncE test equipment, by using commodity hardware of a network device to monitor clock synchronization over time. The test equipment of the monitoring device may be used to generate test equipment data, such as plotting a graph of the time error between the systems over time. The data can further be analyzed and used for validation of the different clock synchronization standards. For example, a standard may dictate that the time error accumulated in every 1000 second window should not be greater than 10 nanoseconds).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Manevich in to the system of Herzerg and Schaap in order to provide a monitoring device to monitor the accumulated time error of the monitored device at any given moment (see Manevich par. 0043).
Regarding claims 11 and 20, Herzerg in view of Schaap in further view of Manevich discloses the vehicle network security system of claim 1, the vehicle network security device of claim 19,
Manevich further discloses wherein the symmetric key is generated using time data in a microsecond (μs) or more (see Manevich par. 0044, In some embodiments, the software may poll the hardware via the software interface for the average error in a certain measurement window. In some embodiments, the software may request that the hardware via the software interface enter a periodic polling mode, in which the hardware sends an event (e.g., current clock error) to the software at a given time interval, for example, every 10 milliseconds. In some embodiments, the software may set an error threshold via the software interface, so that the hardware notifies the software whenever the error passes the threshold. For example, whenever the clock of the monitored device drifts from the clock of the monitoring device by more than 10 nano seconds (microseconds), in either direction).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Manevich in to the system of Herzerg and Schaap in order to provide a monitoring device to monitor the accumulated time error of the monitored device at any given moment (see Manevich par. 0043).
Allowable Subject Matter
9. Claims 8-9, 13, and 17-18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
10. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chien (US 2021/0377008 A1): discloses Techniques for computer security, and more specifically timestamp-based key generation techniques, are described. Some implementations provide a table of key generation processes that is shared as a secret between a first computing system and a second computing system, both of which have two clocks. The first clock is a real-time clock and the second clock is a variable-time clock. The variable time clocks are synchronized and run at the same rate, faster or slower than real time. Both computing systems use the same technique for selecting a key generation process from the table, such as based on a random number generator seeded with a timestamp obtained from their variable time clocks. Since the computing systems have synchronized variable-time clocks, they both select and use the same key generation process, thereby generating the same encryption key without the need to communicate the key from one system to another.
Jung (US 2021/0119800 A1): discloses A security communication method of a client ECU included in a vehicle Ethernet network includes transmitting a first message generated based on a first random number generated by the client ECU, first security version information of the client ECU, and a symmetric key pre-shared with a server ECU, to the server ECU, receiving a second message generated based on a second random number generated by the server ECU, second security version information of the server ECU, and the symmetric key in response to the first message, from the server ECU, when successfully verifying the second message, storing the second random number in a memory of the client ECU, transmitting a third message to the server ECU and generating a session key based on the first random number, the second random number, and the symmetric key, and transmitting a fourth message encrypted using the session key to the server ECU.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL AMBAYE whose telephone number is (571)270-7635. The examiner can normally be reached M-F 9:00 AM - 6:00 PM.
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, Jeffrey Pwu can be reached at (571) 272-6798. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAMUEL AMBAYE/Examiner, Art Unit 2433
/JEFFREY C PWU/Supervisory Patent Examiner, Art Unit 2433