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 office action is in response to amendment/reconsideration filed 7/16/2025, the amendment/reconsideration has been considered. Claims 1-9 are pending for examination, the rejection cited as stated below. Claims 10-20 are withdrawn from consideration.
Response to Arguments
Applicant's arguments have been fully considered but they are not persuasive. The applicant argues the following issues.
(A) Rejection under 35 U.S.C. 112
Issue: The applicant argues (on pages 8-9) with respect to claim 8 that the limitations are supported by the originally filed application and that the scope of the limitations is definite.
Examiner respectfully disagrees. See Examiner’s detailed explanation in the 112 rejections set forth in the prior office action. However, because the amended claim 8 as submitted has overcome the 112 rejections, Applicant’s arguments can be considered moot.
(B) Rejection under 35 U.S.C. 103(a)
Issue 1: The applicant argues (on pages 10-12) with respect to independent claims such as claim 1 that Paruchuri view of BARELET and RAVI fails to teach the claimed limitation “wherein the plurality of private-device edge nodes are mobile devices recruited on demand to facilitate communications between the edge computing device and the plurality of DERs.”
Examiner respectfully disagrees.
Specifically, Applicant argues that Bareket does not teach this limitation because “Bareket explicitly describes deploying fixed infrastructure components… describes deploying permanent network infrastructure gateways, not recruiting existing mobile devices as edge nodes” and because “Bareket's gateways are "deployed using existing gateways already deployed to support connectivity to one or more of the private virtual networks which are already created in the cloud based network”
Examiner respectfully disagrees. Without conceding, for the argued limitations, it is the combination of Paruchuri and Barlett that teaches the limitations, not Paruchuri or Barlett alone. As explained in the rejection section, Paruchuri already teaches the claimed limitations substantially, except that Paruchuri does not expressly disclose that the recruiting of the private-device edge nodes (i.e., gateways) are on demand. Barlett is merely brought in to teach a concept of recruiting gateways on demand. It is such a concept disclosed by Barlett that is relied upon to be combined with Paruchuri, not a mechanical combination of two systems. Piecemeal analysis is not permitted.
Similarly, Applicant’s arguments regarding “dynamically arranged to accommodate a current state of the peer-to-peer network” is not convincing either, because it is the combination of Paruchuri, Bareket and RAVI that teaches this limitation, not Paruchuri, Bareket or RAVI alone. Furthermore, it is the concept disclosed by RAVI regarding a connection between a plurality of private-device edge nodes and an edge computing device being dynamically arranged to accommodate a current state of a peer-to-peer network that is being combined with Paruchuri and Bareket, not a mechanical combination of three systems.
Claim Rejections - 35 USC § 103
3. 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 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.
4. 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 of this title, 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.
5. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
6. Claims 1-2 and 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over Paruchuri et al (US 2019/0109891) in view of BARELET et al (US 2022/0045985), and further in view of RAVI et al (US 2016/0094363).
As to claim 1, Paruchuri discloses a method for managing a plurality of distributed energy resources (DERs) at an edge computing device, comprising:
receiving, from a cloud node, a data collection protocol ([0042], “the configuration controller 120 is configured to obtain a first message with a payload in a first format; extract one or more parameters from the payload of the first message; convert the payload into a second format for consumption by one or more relay controllers based on the one or more parameters, and sends a second message with the converted payload to the relay controllers.… For example, the first message may be a REST message format (e.g., one or more HTTP messages), including commands, parameters, control signals, etc. … the second message may be an I2C protocol message (e.g., address frames and/or data frames) with commands, parameters, control signals, etc. in the I2C format”; [0050], “some or all of the aspects of the EMS 300 may be hosted by a cloud computing service, which interacts with individual equipment or one or more deployed EMS appliances or gateway”; [0051], “the main system controller 302 is configured to … control communication of application layer information between nodes 330, such as sending/receiving requests for data (e.g., measurement data) and sending instructions/commands for changing a mode of operation or state. In some embodiments, the application layer information may include information about the particular nodes that should be included in VEN analysis, such as a user selection of individual physical nodes to be analyzed for inclusion in the VEN 105…the nodes 330 are configured to generate node data, and transmit the node data to the EMS 300 upon request or on a periodic basis using the radio/wired communication circuitry. In embodiments, the node data includes values or data for one or more dynamic parameters, such as electrical measurements or other information discussed herein.”; [0054], “The nodes 330 may correspond to one or more physical sources or loads equipped with radio or wired communication circuitry, or physical sources/loads that share radio/wired communication circuitry. Some or all of the nodes 330 may include electricity sensing elements for measuring electricity being produced or consumed by that node 330, or is coupled to a suitable electricity sensor 321”. Here, the deployed EMS appliances or gateways, or relay controllers is equivalent to an edge computing device that receives commands and parameters from a cloud node that hosts the EMS 300/100, wherein the commands and parameters are equivalent to a data collection protocol, see [0074], “inter-node communication subsystem 312 is configured to facilitate communication with sensors 321, actuators 322, and nodes 330. In particular, inter-node communication subsystem 312 is configured to receive data from sensors 321, actuators 322, and nodes 330, and transmit commands to sensors 321, actuators 322, and nodes 330 for operation/control of the sensors 321, actuators 322, and nodes 330.Example of commands to sensors 321, actuators 322, and nodes 330 may include, but are not limited to, calibration commands, commands to collect certain sensor/actuator/node data that are collected on demand (as opposed to being collected continuously or on a periodic basis), and/or commands to change a position or orientation of a particular sensor 321, actuator 322, and/or node 330”. Here, the data collection protocol is the commands to collect certain sensor/actuator/node data that are collected on demand as opposed to being collected continuously or on a periodic basis. See also figure 12 and [0157], “In another example, the EMS 100 or 300 discussed previously may be, or may be incorporated in one or more of the IoT devices 1204 or GW 1220, 1226, and 1230”; [0181], “the IoT devices 1504 may be wired so as to allow any one of the IoT devices 1504 to control measurements, inputs, outputs, etc., for the other IoT devices 1504”); recruiting a plurality of private-device edge nodes in a peer-to-peer network ([0149], “IoT devices may include IoT gateways used to couple IoT devices to other IoT devices and to cloud application”; [0051], “the main system controller 302 is configured to … control communication of application layer information between nodes 330…. In some embodiments, the application layer information may include information about the particular nodes that should be included in VEN analysis, such as a user selection of individual physical nodes to be analyzed for inclusion in the VEN 105”; [0101], “the EMS appliance 900 is configured to re-evaluate the VEN 105/200 and generate a new instance of the VEN 105/200”’; see [0065], “At 604, the DER may identify available peer-to-peer nodes (e.g., edge nodes). The available edge nodes may be identified by the DER based on their proximity to the DER and their registration with a super edge node” and [0080], “remote communication subsystem 314 is configured to communicate with servers 340 wirelessly, via a wide area network, such as the Internet or an enterprise network. Wireless communication may be short-range (e.g., peer-to-peer (p2p)”);
transmitting the data collection protocol to each of the plurality of private-device edge nodes
(see citation in rejection to limitation 1 above, wherein the deployed EMS or gateways or an IoT device at an intermediary tier passes the commands to the each of the plurality of private-device edge nodes such as the final tier IoT device), wherein the data collection protocol is then transmitted from the plurality of private-device edge nodes to the plurality of DERs ([0074], “inter-node communication subsystem 312 is configured to facilitate communication with sensors 321, actuators 322, and nodes 330. In particular, inter-node communication subsystem 312 is configured to receive data from sensors 321, actuators 322, and nodes 330, and transmit commands to sensors 321, actuators 322, and nodes 330 for operation/control of the sensors 321, actuators 322, and nodes 330.Example of commands to sensors 321, actuators 322, and nodes 330 may include, but are not limited to, calibration commands, commands to collect certain sensor/actuator/node data that are collected on demand (as opposed to being collected continuously or on a periodic basis”; [0051], “the main system controller 302 is configured to … control communication of application layer information between nodes 330, such as sending/receiving requests for data (e.g., measurement data) and sending instructions/commands for changing a mode of operation or state”; [0054], “The nodes 330 may correspond to one or more physical sources or loads equipped with radio or wired communication circuitry, or physical sources/loads that share radio/wired communication circuitry. Some or all of the nodes 330…is coupled to a suitable electricity sensor 321”. Here, passing the command/instructions by the gateways/nodes to final nodes such as sensors is implied in order to collect measurements according to the commands/instructions);
receiving, based on the data collection protocol, data relating to the plurality of DERs from
the plurality of private-device edge nodes through the peer-to-peer network (see citation above. The deployed EMS or gateway or the last tier IoT receives measurement data from DERs. Also see [0054], “the nodes 330 are configured to generate node data, and transmit the node data to the EMS 300 upon request or on a periodic basis using the radio/wired communication circuitry. In embodiments, the node data includes values or data for one or more dynamic parameters, such as electrical measurements or other information discussed herein”); and
transmitting the received data to a cloud-based node (see citations above, wherein the final tier IoT or node 330 transmits data to higher tier IoT/EMS which is cloud based. See also [0169], “the IoT group 1406 may communicate with the servers 1404 via GW 1410, server(s) 1430, and cloud 1401 to provide captured data, which may be used to provide performance monitoring and analytics to the manufacturer or factory operator. Additionally, where the GW 1410 or one or more of the server(s) 1430 is or includes an EMS 100/300 (or is an EMS appliance 900 of FIG. 9), the IoT group 1406 may communicate with the GW 1410 and/or one or more of the server(s) 1430 for energy and electricity consumption optimizations according to the various embodiments discussed herein. Furthermore, the IoT devices in the IoT group 1406 may communicate among each other, and/or with other IoT devices of other IoT groups, to make decisions on their own and to perform their tasks as autonomously as possible”. Also see [0173]; [0176]),
wherein the plurality of private-device edge nodes facilitates communications between the edge computing device and the plurality of DERs without requiring establishment of a direct communication infrastructure for communicating between the edge computing device and the plurality of DER (see citation in rejection to the preceding limitations, and also [0054], “the nodes 330 are configured to generate node data, and transmit the node data to the EMS 300 upon request”; [0149], “IoT devices may include IoT gateways, used to couple IoT devices to other IoT devices and to cloud applications, for data storage, process control, and the like”, wherein the nodes/gateways pass collected data without requiring direct communications between the EMS and each sensor. It is to be noted that the claimed limitation merely requires “without requiring” without requiring without direct communication); and
wherein the plurality of private-device edge nodes are mobile devices ([0054], “radio communication circuitry”; [0154], “a wireless local area network (WLAN) can be used to communicate with IoT devices”; [0149], “an IoT device may be a smart phone, laptop, tablet, or PC, or other larger device… IoT devices may include IoT gateways used to couple IoT devices to other IoT devices and to cloud application”) recruited to facilitate communications between the edge computing device and the plurality of DERs (see citation in preceding limitations, e.g., [0054], “the nodes 330 are configured to generate node data, and transmit the node data to the EMS 300 upon request”; [0149], “IoT devices may include IoT gateways, used to couple IoT devices to other IoT devices and to cloud applications, for data storage, process control, and the like”).
However, Paruchuri does not expressly disclose that the recruiting of the private-device edge nodes (i.e., gateways) are on demand, or that wherein connection between the plurality of private-device edge nodes and the edge computing device is dynamically arranged to accommodate a current state of the peer-to-peer network. BARELET discloses a concept of recruiting gateways on demand ([0047], “For example, assuming the network controller(s) identifies an increase in the demand, for example, a large number of access requests are received from a plurality of additional client devices. In such the network controller(s) may deploy automatically one or more additional gateways to serve the increase in the connectivity demand. Each such additional gateway deployed to serve the increasing demand may be configured to route network packets according to the IP address range(s) of one or more of the private virtual networks which are the target of the additional client devices.” Here, the gateways are recruited on demand from the controller in response to increased access requests/demand).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Paruchuri and BARELET. The suggestion/motivation of the combination would have been to accommodate increased demand (BARELET, [0047]).
RAVI discloses a concept that connection between a plurality of private-device edge nodes and an edge computing device is dynamically arranged to accommodate a current state of a peer-to-peer network (Figures 1-2; [0043], “The processor circuit 42 executing the monitor 96 in the exchange edge device 12 also can detect in operation 68 if there is a detected failure in the responder edge device of the responder network responding to the service request of operation 66. In response to the detected failure, the processor circuit 42 can determine if the responder network has an alternate responder edge device in the same responder network (e.g., in a multi-homed network), and in response send recovery instructions to the requestor edge device 20/22 (and the corresponding exchange edge device 12 serving the alternate responder edge device 20/22) to establish a new secure peer-to-peer network link 30 and secure service channel 28 to resume the provider-consumer delivery of the network-based service 38. The processor circuit 42 of the exchange edge device(s) 12 also can send the instructions regarding the alternate responder edge device 20/22 as part of the instructions sent in operation 64, enabling the requestor edge device to initiate the failover operation with the alternate responder edge device 20/22 in response to the requestor edge device detecting the failure and without further instructions required from the exchange edge device 12”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Paruchuri and RAVI. The suggestion/motivation of the combination would have been to provide failover capability (RAVI, [0043]).
As to claim 2, Paruchuri-BARELET-RAVI discloses the method of claim 1, further comprising:
transmitting routing information to each of the plurality of private-device edge nodes, the
routing information transmitted to each particular private-device edge node comprising a route configured based on one or more of bandwidth, latency, or connection reliability for transmitting, from the private-device edge node to the edge computing device, data relating to at least one DER in the plurality of DERs (Paruchuri, see citation in rejection to claim 1 above, wherein transmitting the source identifier/address is implied, which is routing information for replies. See [0173], “resources in the edge cloud may be in one to two-hop proximity to the IoT devices 1504, which may result in reducing overhead related to processing data and may reduce network delay”, wherein the source identifier/address indicates a route in a one-hop situation configured based on latency).
As to claim 5, Paruchuri-BARELET-RAVI discloses the method of claim 1, further comprising:
transmitting a control message to at least one DER in the plurality of DERs via at least one private-device edge node of the plurality of private-device edge nodes, wherein the control message indicates at least one of at least one operating mode for the DER in a set of operating modes (Paruchuri, see citation in rejection to claim 1 and [0051], “The main system controller 302 is also configured to control communication of application layer information between nodes 330, such as sending/receiving requests for data (e.g., measurement data) and sending instructions/commands for changing a mode of operation or state.”), the set of operating modes comprising one of a constant voltage operating mode and a constant power operating mode, the set of operating modes further associated with one of an energy production or energy storage function of the DER ([0057], “the sensors 321 include one or more power sensors, which are designed for specific power requirements and thresholds based on a maximum power to be drawn by a portion of the electrical network 101. The power sensors may include, for example, voltage, current, and power quality sensors.”), and a reference value related to a characteristic of the at least one DER, wherein the reference value related to the characteristic comprises one of a voltage magnitude, a power factor, and a reactive power operating point, the reference value further associated with one of an energy production or energy storage function of the DER ([0219]).
As to claim 6, Paruchuri-BARELET-RAVI discloses the method of claim 1, further comprising:
diagnosing a state of the plurality of DERs based on the received data relating to the plurality of DERs; and transmitting, to the cloud-based node, data regarding the state of the plurality of DERs (Paruchuri, see citation in rejection to claim 1 and [0053], “and the actuator data may include data about a state or mode of operation of the actuators 321”).
As to claim 7, Paruchuri-BARELET-RAVI discloses the method of claim 1, wherein the data collection protocol indicates a set of data types to collect (Paruchuri, see citation in rejection to claim 1, “commands to collect certain sensor/actuator/node data”), and a sampling value indicating an amount of data associated with the set of data types to transmit (see citation in rejection to claim 1, “commands to collect certain sensor/actuator/node data”; also see [0055], [0061], “sampled signal”), wherein the data collection protocol indicates for the plurality of DERs to collect a set of time-series data that comprises less than all data available at the plurality of DERs ([0053], “events” which is limited to events collected comprising less than all data available at the plurality of DERs).
7. Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Paruchuri-BARELET-RAVI, as applied to claim 1 above, and further in view of Siebel et al (US 2022/0405775).
As to claim 3, Paruchuri-BARELET-RAVI discloses the method of claim 1, wherein each of the plurality of DERs is associated with at least one of a private-device edge node or the edge computing device (Paruchuri, figure 3, the Sensors 321, Actuator 322 are coupled to Nodes 330 and EMS 300. See citation in rejection to claim 1, wherein EMS 300 can be implemented in various entities such as cloud service, deployed EMS, gateway, IoTs), and at least one DER in the plurality of DERs is associated with two or more private-device edge nodes (Paruchuri, see citation in rejection to claim 1, Nodes 330 indicates multiple nodes, also Deployed EMS or gateways or IoTs), the method further comprising: aggregating the received data before transmitting the received data (Paruchuri, [0173]; [0176]), but does not expressly disclose removing duplicate data relating to a same DER received from more than one private-device edge node. Siebel discloses a concept of removing duplicate data prior to aggregation ([0223]), wherein the data sources can be distributed energy resource data ([0440]),
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Paruchuri-BARELET-RAVI with Siebel. The suggestion/motivation of the combination would have been to avoid using duplicate data during an aggregation process (Siebel, [0223]).
8. Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Paruchuri-BARELET-RAVI, as applied to claim 1 above, and further in view of Carpenter et al (US 2010/0312653).
As to claim 4, Paruchuri-BARELET-RAVI discloses the method of claim 1, further comprising: registering private-device edge nodes for inclusion in the peer-to-peer network, by associating the private-device edge node with an account (Paruchuri, see citation in rejection to claim 1, wherein a registration is implied, such as a first connection message in the peer-to-peer network which is equivalent to a registration, wherein the source address is equivalent to an account), the method further comprising: validating that the data has been received from the private-device edge node (Paruchuri, see citation in rejection to claim 1, the receiving step for receiving data from the private-device edge nodes), but does not expressly disclose crediting the account associated with the private-device edge node based on the validation of the data being received. Carpenter discloses a concept of crediting an account associated with a node based on validation of data being received (claim 15).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Paruchuri-BARELET-RAVI with Carpenter. The suggestion/motivation of the combination would have been to only crediting account based on validations (Carpenter, claim 15).
9. Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Paruchuri-BARELET-RAVI, as applied to claim 1 above, and further in view of Viengkham et al (US 2022/0192454).
As to claim 8, Paruchuri-BARELET-RAVI discloses the claimed invention substantially as discussed in claim 1, but does not expressly disclose detecting a failure state of a connection to the cloud-based node; storing in a local storage data relating to the plurality of DERs received after the failure state is detected; and detecting a reestablished connection to the cloud-based node, wherein transmitting the received data to the cloud-based node comprises transmitting the stored data via a reestablished secure link to the cloud-based node. Viengkham discloses a concept of detecting a failure state of a connection to a cloud-based node ([0036], “Data may be sent from the edge gateways 162a-162n to the IoT platform 125 via direct streaming and/or via batch delivery. Further, after any network or system outage, data transfer will resume once communication is re-established and any data missed during the outage will be backfilled from the source system or from a cache of the IoT platform 125. The IoT layer 205 may also include components for accessing time series, alarms and events, and transactional data via a variety of protocols”; [0018], “The IoT platform is an extensible platform that is portable for deployment in any cloud or data center environment for providing an enterprise-wide, top to bottom view”); storing in a local storage data relating to data source node(s) after the failure state is detected (see citation above); and detecting a reestablished connection to the cloud-based node (see citation above), wherein transmitting the received data to the cloud-based node comprises transmitting the stored data to the cloud-based node via a reestablished secure link (see citation above).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Paruchuri-BARELET-RAVI with Viengkham. The suggestion/motivation of the combination would have been to resume data communication (Viengkham, [0036]).
16. Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Paruchuri-BARELET-RAVI, as applied to claim 1 above, and further in view of Akkaya et al (US 11329806).
As to claim 9, Paruchuri-BARELET-RAVI discloses the method of claim 1, the method further comprising:
transmitting the data collection protocol to each of a set of DERs in the peer-to-peer network (Paruchui, see citation in rejection to claim 1, the managed DERs such as sensor, actuator, nodes330., and managing entities such as deployed EMS, gateways, and IoTs constitute a peer-to-peer network); and
receiving, based on the data collection protocol, unencrypted data relating to the set of DERs from the set of DERs through the peer-to-peer network (Paruchuri, see citation in rejection to claim 1, wherein the data is not disclosed to be encrypted), wherein transmitting the received data to the cloud-based node comprises transmitting the data received from the plurality of private device edge nodes and the set of DERs (Paruchui, see citation in rejection to claim 1, last limitation and [0169], “the IoT group 1406 may communicate with the servers 1404 via GW 1410, server(s) 1430, and cloud 1401 to provide captured data, which may be used to provide performance monitoring and analytics to the manufacturer or factory operator. Additionally, where the GW 1410 or one or more of the server(s) 1430 is or includes an EMS 100/300 (or is an EMS appliance 900 of FIG. 9), the IoT group 1406 may communicate with the GW 1410 and/or one or more of the server(s) 1430 for energy and electricity consumption optimizations according to the various embodiments discussed herein. Furthermore, the IoT devices in the IoT group 1406 may communicate among each other, and/or with other IoT devices of other IoT groups, to make decisions on their own and to perform their tasks as autonomously as possible), but does not expressly disclose wherein the data relating to the plurality of DERs from the plurality of private-device edge nodes comprises encrypted data transmitted by the plurality of DERs to the plurality of private-device edge nodes. Akkaya discloses a concept for a DER transmitted data to be encrypted (claim 1, “each field device of the plurality of field devices being further configured such that when it sends data to the control center after performing the setup, the field device first computes a shared key and uses the shared key to encrypt and authenticate the data to be sent to the control center, and sends the current secret key to the control center along with the encrypted data”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Paruchuri-BARELET-RAVI with Akkaya. The suggestion/motivation of the combination would have been to improve security (Akkaya, claim 1).
Conclusion
10. THIS ACTION IS MADE FINAL. 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 extension fee 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 HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
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, Umar Cheema can be reached at 571-270-3037. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HUA FAN/Primary Examiner, Art Unit 2458