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 .
DETAILED ACTION
This initial office action is based on the application filed on 03/01/2024, which claims 1-16 have been presented for examination.
Status of Claim
Claims 1-16 are pending in the application and have been examined below, of which, claims 1, 5 and 13 are presented in independent form.
Priority
This application claims priority to GERMANY 102023202071.8 filed on 03/08/2023. Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. GERMANY 102023202071.8, filed on 03/08/2023.
Information Disclosure Statement
No information disclosure statement (IDS) has been filed in this application.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Abstract Objections
Abstract recites the numbers/texts inside parentheses and “means” in lines 2, 6 and 7 should be removed.
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
Claim Objections
Claims 1-16 are objected to because of the following informalities:
Line 3 of claim 1 and lines 3-4 of claim 5, “the current version” lacks proper antecedent basis.
In lines 2 and 7 of claim 5, replace “configured to store” with --storing--.
Claims 2-4 and 6-16 depend on the objected claims and inherit the same issue.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
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.
Claim(s) 1-2 and 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hunt et al. (US Pub. No. 2018/0275982 A1 – herein after Hunt) in view of Case et al. (US Patent No. 11,895,493 B1 – herein after Case).
Regarding claim 1.
Hunt discloses
A method for updating a software stored in a first memory of a sensor (the system 100 includes a publisher server 140 which may provide a software update to one of the mesh nodes 110 for distribution through the network 130 to one or more target mesh nodes 110 – See paragraph [0013]. A type of the mesh node 110 (e.g., a motion detection mesh node, a door lock mesh node, etc.), and/or the sensors included in the mesh node 110 (e.g., a motion sensor, a temperature sensor, etc.) – See paragraph [0013]), comprising:
receiving a first data frame requesting an update of the current version of the software stored in the first memory (The publisher server 140 may receive the data from a developer of the software update – See paragraph [0045]. Software update data 302 which may be embodied as any data indicative of one or more software updates (e.g., source code, object code, patches, etc.), and characteristics of the software updates (e.g., a software version, a node type to which the software update pertains, a sensor type to which the software update pertains, a criticality of the software update, such as high criticality for a security update, a medium criticality for an efficiency improvement, or a low criticality for a user interface enhancement, etc.) – See paragraph [0024] and Fig. 3, a software version stored memory 302), the first data frame comprising a header and data for updating the current version of the software (software update and/or may analyze a header or other portion of the software update for flags, symbols, or other indicia of the characteristics – See paragraph [0045]), the [[header]] comprising a first identifier and a second identifier (publisher server 140 may generate data indicative of the version of the software update, a type of mesh node to which the update pertains, and/or one or more types of sensors to which the software update pertains – See paragraph [0045]),
comparing the first identifier with a predetermined sensor identifier stored in a second memory of the sensor (compare the characteristics of the software update to the characteristics of the mesh nodes 110, as indicated in the fingerprint data, to determine which of the mesh nodes 110 the software update applies to (e.g., which mesh nodes 110 are of a type that the software update applies to and which of the mesh nodes 110 are executing a software version that is older than the version of the software update) – See paragraphs [0028]. Mesh node data or identifier/sensor data or identifier stored in memory 304 – See Fig. 3), and
updating the current version of the software from the data of the first data frame when the first identifier includes the predetermined sensor identifier (in analyzing the software update, the present mesh node 110 may determine a version, a node type, a sensor type, a criticality (e.g., high criticality, medium criticality, low criticality, etc.) and/or a publication Bloom value associated with the software update, as indicated in block 564 – See paragraph [0039]. Compare characteristics of the software update (e.g., from block 562) to the determined characteristics of the mesh nodes 110 (e.g., from block 542). In the illustrative embodiment, the present mesh node 110 may match the software update version to the software version of one or more of the mesh nodes 110, as indicated in block 574. Additionally or alternatively, the present mesh node 110 may match a node type or sensor type associated with the software update to one or more of the mesh nodes 110, as indicated in block 576. As indicated in block 578, the present mesh node 110 may additionally or alternatively match the publication Bloom value of the software update to a Bloom filter of one or more of the mesh nodes 110 to determine whether the software update is applicable to one or more of the mesh nodes 110. The present mesh node 110 may patch itself with the software update (e.g., if the present mesh node 110 is of a type that the software update pertains to – See paragraphs [0040-0041).
Hunt discloses generate data indicative of the version of the software update, a type of mesh node to which the update pertains, and/or one or more types of sensors to which the software update pertains – See paragraph [0045].
Hunt does not disclose
the header comprising a first identifier and a second identifier.
Case discloses
the header comprising a first identifier and a second identifier (Upon the validation of the secret, the controlled device 310 determines an identifier of the controlling device 320 from this management frame (e.g. the MAC address of controlling device 320 from a source MAC address field in the header of the first management frame). Because the secret is valid, the controlled device 310 can assume that frames associated with the identifier are to be trusted. Accordingly, the controlled device 310 receives a second management frame, where this frame includes the command 302 but not the secret. Next, the controlling device 320 determines the identifier from the second management frame (e.g., the source MAC address) and that this identifier corresponds to a trusted device – See col. 9, lines 45-57. The controlled device 110 can be of a different type, such as a smartphone, tablet, e-reader, smart watch, wearable device, smart speaker, smart appliance, IoT device, sensor, and the like – See col. 3, lines 55-65).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Case’s teaching into Hunt’s invention because incorporating Case’s teaching would enhance Hunt to enable to send a frame to the controlled device/sensor where the frame corresponds to request for association between the devices as suggested by Case (col. 6, lines 35-52).
Regarding claim 2, the method according to claim 1,
Case discloses
wherein updating the current version of the software comprises:
replacing the current version of the software by the data in the first memory (before connecting it to the home network, a software update may need to be pushed to the IoT device. This software update may be downloaded to the controlling device 120 via a secure channel first. Thereafter, the controlling device 120 can send the secret followed by the software update. In this way, the IoT device can validate the secret and download the software update from the controlling device 120 – See col. 6, lines 3-10),
resetting the sensor when the current version of the software is replaced by the data in the first memory (a reboot of the controlled device 110 (e.g., upon power cycling or following a software update) – See col. 5, lines 4-15), and
transmitting a second data frame comprising the second identifier when the sensor is reset (a reboot of the controlled device 110 (e.g., upon power cycling or following a software update), a dissociation of the controlled device 110 from the access point 130 (e.g., due to a change to the SSID and/or the credential), or a connection attempt of the controlled device 110 to the home network (e.g., due to a change to the access point 130, the installation of a new access point, or some other network change) – See col. 5, lines 4-15).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Case’s teaching into Hunt’s invention because incorporating Case’s teaching would enhance Hunt to enable to reboot, dissociate and reconnect to network as suggested by Case (col. 2, lines 62-67 and col. 3, lines 1-5).
Regarding claim 5.
Hunt discloses
A sensor (mesh node (motion detection mesh node, motion sensor, a temperature sensor – See paragraph [0013]) comprising:
a first memory configured to store a software (Fig. 3, block 302, software update data 302, software version – See paragraph [0013]),
communication means configure to receive a first data frame requesting an update of the current version of the software stored in the first memory (The publisher server 140 may receive the data from a developer of the software update – See paragraph [0045]. Software update data 302 which may be embodied as any data indicative of one or more software updates (e.g., source code, object code, patches, etc.), and characteristics of the software updates (e.g., a software version, a node type to which the software update pertains, a sensor type to which the software update pertains, a criticality of the software update, such as high criticality for a security update, a medium criticality for an efficiency improvement, or a low criticality for a user interface enhancement, etc.) – See paragraph [0024]), the first data frame comprising a header and data for updating the current version of the software (software update and/or may analyze a header or other portion of the software update for flags, symbols, or other indicia of the characteristics – See paragraph [0045]), the [[header]] comprising a first identifier and a second identifier (publisher server 140 may generate data indicative of the version of the software update, a type of mesh node to which the update pertains, and/or one or more types of sensors to which the software update pertains – See paragraph [0045]),
a second memory configured to store a predetermined sensor identifier (mesh node data – See Fig. 3, 304. Mesh node data 304 which may be embodied as any data indicative of identifiers of the mesh nodes 110 in the network 130 and fingerprint data indicative of characteristics of each mesh node 110 (e.g., the energy status of each mesh node 110, a software version executed by each mesh node 110, a type of each mesh node 110, identifications of types of sensors 214 included in each mesh node 110) – See paragraph [0025]),
comparing means configured to compare the first identifier with the predetermined sensor identifier (compare the characteristics of the software update to the characteristics of the mesh nodes 110, as indicated in the fingerprint data, to determine which of the mesh nodes 110 the software update applies to (e.g., which mesh nodes 110 are of a type that the software update applies to and which of the mesh nodes 110 are executing a software version that is older than the version of the software update) – See paragraphs [0028]. Mesh node data or identifier/sensor data or identifier stored in memory 304 – See Fig. 3), and
processing means configured to update the current version of the software from the data of the first data frame when the first identifier includes the predetermined sensor identifier (in analyzing the software update, the present mesh node 110 may determine a version, a node type, a sensor type, a criticality (e.g., high criticality, medium criticality, low criticality, etc.) and/or a publication Bloom value associated with the software update, as indicated in block 564 – See paragraph [0039]. Compare characteristics of the software update (e.g., from block 562) to the determined characteristics of the mesh nodes 110 (e.g., from block 542). In the illustrative embodiment, the present mesh node 110 may match the software update version to the software version of one or more of the mesh nodes 110, as indicated in block 574. Additionally or alternatively, the present mesh node 110 may match a node type or sensor type associated with the software update to one or more of the mesh nodes 110, as indicated in block 576. As indicated in block 578, the present mesh node 110 may additionally or alternatively match the publication Bloom value of the software update to a Bloom filter of one or more of the mesh nodes 110 to determine whether the software update is applicable to one or more of the mesh nodes 110. The present mesh node 110 may patch itself with the software update (e.g., if the present mesh node 110 is of a type that the software update pertains to – See paragraphs [0040-0041).
Hunt discloses generate data indicative of the version of the software update, a type of mesh node to which the update pertains, and/or one or more types of sensors to which the software update pertains – See paragraph [0045].
Hunt does not disclose
the header comprising a first identifier and a second identifier.
Case discloses
the header comprising a first identifier and a second identifier (Upon the validation of the secret, the controlled device 310 determines an identifier of the controlling device 320 from this management frame (e.g. the MAC address of controlling device 320 from a source MAC address field in the header of the first management frame). Because the secret is valid, the controlled device 310 can assume that frames associated with the identifier are to be trusted. Accordingly, the controlled device 310 receives a second management frame, where this frame includes the command 302 but not the secret. Next, the controlling device 320 determines the identifier from the second management frame (e.g., the source MAC address) and that this identifier corresponds to a trusted device – See col. 9, lines 45-57. The controlled device 110 can be of a different type, such as a smartphone, tablet, e-reader, smart watch, wearable device, smart speaker, smart appliance, IoT device, sensor, and the like – See col. 3, lines 55-65).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Case’s teaching into Hunt’s invention because incorporating Case’s teaching would enhance Hunt to enable to send a frame to the controlled device/sensor where the frame corresponds to request for association between the devices as suggested by Case (col. 6, lines 35-52).
Regarding claim 6, recites the same limitations as rejected claim 2 above.
Claim(s) 3-4 and 7-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hunt and Case as applied to claims 1 and 5 respectively above, and further in view of JP (JP 2023017782 A – herein after JP).
Regarding claim 3, the method according to claim 1,
JP discloses
wherein when the first identifier does not include the predetermined sensor identifier, the method comprises transmitting a third data frame representative of the non-update of the software (view handle field 1338 contains a value that matches the respective view handle field from view request message 1290 to which view response message 1334 is responding View Cancel Request When a viewing node 1286 wishes to cancel an in-progress view (e.g., a periodic update or a monitor view), the viewing node 1286 sends a view request message 1290 to a view cancel request as shown in FIG. It may be transmitted in the form of frame 1332. View Cancel Request When a viewing node 1286 wishes to cancel an in-progress view (e.g., a periodic update or a monitor view), the viewing node 1286 sends a view request message 1290 to a view cancel request as shown in FIG. It may be transmitted in the form of frame 1332 . A view cancel request frame 1332 is essentially a previous request that the viewed node 1288 can recognize as a previous request to cancel the current periodic update or monitor view using the view handle value in the refresh request frame 1330 . Retransmit the view handle field from the previous periodic update from the request or monitor view (e.g., view handle fields 1310 or 1322) – See pages 31-32).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use JP’s teaching into Hunt’s and Case’s inventions because incorporating JP’s teaching would enhance Hunt and Case to enable to cancel periodic update as suggested by JP (page 31).
Regarding claim 4, the method according to claim 2,
JP discloses
wherein when the first identifier does not include the predetermined sensor identifier, the method comprises transmitting a third data frame representative of the non-update of the software (view handle field 1338 contains a value that matches the respective view handle field from view request message 1290 to which view response message 1334 is responding View Cancel Request When a viewing node 1286 wishes to cancel an in-progress view (e.g., a periodic update or a monitor view), the viewing node 1286 sends a view request message 1290 to a view cancel request as shown in FIG. It may be transmitted in the form of frame 1332 . A view cancel request frame 1332 is essentially a previous request that the viewed node 1288 can recognize as a previous request to cancel the current periodic update or monitor view using the view handle value in the refresh request frame 1330 . Retransmit the view handle field from the previous periodic update from the request or monitor view (e.g., view handle fields 1310 or 1322) – See pages 31 -32).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use JP’s teaching into Hunt’s and Case’s inventions because incorporating JP’s teaching would enhance Hunt and Case to enable to cancel periodic update as suggested by JP (page 31).
Regarding claim 7, recites the same limitations as rejected claim 3 above.
Regarding claim 8, recites the same limitations as rejected claim 4 above.
Regarding claim 9.
JP discloses
A network (network – See Abstract) comprising:
a gateway (central router – See page 5), at least one sensor according to claim 5, the communication means being configured to communicate wirelessly with the gateway, the gateway being configured to send the first data frame (send updates when changes are made to the data of interest at the viewed node 1288 so that the viewing node1286 maintains a synchronized list of that data – See page 31).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use JP’s teaching into Case’s and Hunt’s inventions because incorporating JP’s teaching would enhance Case and Hunt to enable to provide wireless router that communicates with device as suggested by JP (page 11).
Regarding claim 10.
JP discloses
A network comprising:
a gateway, at least one sensor according to claim 6, the communication means being configured to communicate wirelessly with the gateway (central router – See page 11),
the gateway being configured to send the first data frame (send updates when changes are made to the data of interest at the viewed node 1288 so that the viewing node1286 maintains a synchronized list of that data – See page 31),
wherein the gateway is further configured to receive at least the second data frame transmitted by the processing means of the sensor (the software update profile frame may include a message type field 1172 indicating additional information, which may be selected according to Table 9 below and the type of message being sent – See page 26).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use JP’s teaching into Case’s and Hunt’s inventions because incorporating JP’s teaching would enhance Case and Hunt to enable to send the type of message used in connection with software updates as suggested by JP (page 26).
Regarding claim 11, the network according to claim 9,
Case discloses
further comprising a network supervisor configured to monitor the update of the software from data frame transmitted by the processing means of the sensor (remotely controlling a computing device that operates in a monitor mode. In an example, the computing device can support multiple operational modes including, for instance, the monitor mode and one or more other modes. In the monitor mode, the computing device is capable of wireless data reception but no wireless data transmission – See col. 2, lines 3-9).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Case’s teaching into Hunt’s inventions because incorporating Case’s teaching would enhance Hunt to enable to operate in the monitor mode as suggested by Case (col. 5, lines 16-21).
Regarding claim 12, the network according to claim 9,
Hunt discloses
wherein the network is a mesh network (the network is a mesh network – See Abstract).
Regarding claim 13.
JP discloses
A network (network – See Abstract) comprising:
a gateway (central router – See page 11),
at least one sensor according to claim 8, the communication means being configured to communicate wirelessly with the gateway, the gateway being configured to send the first data frame (send updates when changes are made to the data of interest at the viewed node 1288 so that the viewing node1286 maintains a synchronized list of that data – See page 31).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use JP’s teaching into Case’s and Hunt’s inventions because incorporating JP’s teaching would enhance Case and Hunt to enable to provide wireless router that communicates with device as suggested by JP (page 11).
Regarding claim 14, the network according to claim 13,
JP discloses
wherein the gateway is further configured to receive at least the second data frame transmitted by the processing means of the sensor (the software update profile frame may include a message type field 1172 indicating additional information, which may be selected according to Table 9 below and the type of message being sent – See page 26).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use JP’s teaching into Case’s and Hunt’s inventions because incorporating JP’s teaching would enhance Case and Hunt to enable to send the type of message used in connection with software updates as suggested by JP (page 26).
Regarding claim 15, the network according to claim 13,
Case discloses
further comprising a network supervisor configured to monitor the update of the software from data frame transmitted by the processing means of the sensor (remotely controlling a computing device that operates in a monitor mode. In an example, the computing device can support multiple operational modes including, for instance, the monitor mode and one or more other modes. In the monitor mode, the computing device is capable of wireless data reception but no wireless data transmission – See col. 2, lines 3-9).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Case’s teaching into Hunt’s inventions because incorporating Case’s teaching would enhance Hunt to enable to operate in the monitor mode as suggested by Case (col. 5, lines 16-21).
Regarding claim 16, the network according to claim 15,
Hunt discloses
wherein the network is a mesh network (the network is mesh network – See Abstract).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Koval et al. (US Pub. No. 2024/0126538 A1) discloses tracking and upgrading firmware in intelligent electronic devices (IEDs). The present disclosure provides for tracking firmware versions of at least one or a fleet of IEDs, e.g., electronic power or revenue meters, notifying a user that an update to an existing firmware is available and providing the ability to automatically upload the current or latest version of the firmware to all IEDs – See Abstract and specification for more details.
Kolanjery et al. (US Pub. No. 2024/0089144 A1) discloses parsing the first data transmission into a first plurality of data frames based on the first size of the first data transmission and the maximum data frame size; sending a first header frame to a second automotive audio bus manager associated with the second automotive audio bus client, wherein the first header frame includes a first indication of a first incoming long message transmission and the first size of the first data transmission; and sending the first plurality of data frames to the second automotive audio bus manager – See Abstract and specification for more details.
Bures et al. (US Pub. No. 2020/0322703 A) discloses monitoring data analysis system includes receiving a plurality of measurement data from the gateway device, each indicating a measurement generated by one of a plurality of multi-sensor units. A set of measurement entries are generated based on the plurality of measurement data, and the set of measurement entries are added to a measurement database – See Abstract and specification for more details.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONGBAO NGUYEN whose telephone number is (571)270-7180. The examiner can normally be reached Monday-Friday 8am-5pm.
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, Hyung S. Sough can be reached at 571-272-6799. 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.
/MONGBAO NGUYEN/ Examiner, Art Unit 2192