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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted was filed after the mailing date. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-2, 9-12, 19-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Knight et al. (“Knight”) (US 20210006622 A1).
Regarding claim 1, Knight teaches:
A method comprising: receiving, by an edge device of an industrial facility [¶0027, IoT gateway performing edge based control], a plurality of first packets associated with a first communication protocol from an industrial device of the industrial facility [¶0031, Figure 1 102a is an industrial building ¶0031 connected to external network via IoT gateway 125, receive data from IoT devices on BACnet (BACnet being first protocol)];
extracting, by the edge device, device data associated with the industrial device from the plurality of first packets associated with the first communication protocol [¶0033 IoT gateway evaluates and filters the data corresponding to extracting, the data being sensor data ¶0031 considered device data];
creating, by the edge device, a second packet associated with a second communication protocol, the second packet including the device data associated with the industrial device in the plurality of first packets [¶0033, translation between BACnet and Internet communication protocol corresponding to creating a second packet];
and transmitting, by the edge device, the second packet associated with the second communication protocol to a cloud platform to manage an industrial digital twin on the cloud platform based on the second packet [¶0033, “The IoT Gateway 125 may connect the devices 110 and the controllers 113 to the Intelligent Building Cloud Platform 165 over a network 160” ¶0036 building cloud platform creates and manipulates digital twin 180 Figure 1].
Regarding claim 2, Knight teaches:
The method of claim 1, wherein: the industrial digital twin is one of a virtual model of the industrial device or a virtual model of an industrial system that includes the industrial device [¶0034-36 digital twin of building 102 in edge and cloud 165, comprising industrial devices 110a-g].
Regarding claim 9, Knight teaches:
The method of claim 1, further comprising: receiving, by the edge device, a third packet associated with the second communication protocol from a twin model management system implemented on the cloud platform [¶0056, twin management model sends notification via gateway see Figure 1 to IoT devices in industrial area corresponding to third packet of second communication protocol, wherein ¶0032-33 IoT gateway connects twin to the devices in 102a thus gateway receives these packets, [0051 wherein figure 5 may be performed by other systems including systems in the cloud]; determining, by the edge device, an operation to be performed by the industrial device that is indicated in the third packet associated with the second communication protocol [step 545, ¶0054-56 gateway provides control to devices by e.g. determining an action related to temperature control for cooling devices, determine an action e.g. cooling via temperature controller, among plurality of actions]; determining, by the edge device and based on the operation, a plurality of device commands to be executed by the industrial device to perform the operation [¶0056-57, commands include modifying air temperature e.g. at cooling system to decrease temperature or modifying an air damper, among plurality of actions i.e. commands]; creating, by the edge device, a plurality of fourth packets associated with the first communication protocol, wherein each fourth packet among the plurality of fourth packets specifies one or more device commands among the plurality of device commands to be executed by the industrial device [¶0056 step 545 of Figure 5 notifying relevant assets in industrial setting (via fourth packets) 102a of solution to modify the air temperature and adjust the power]; and transmitting, by the edge device, the plurality of fourth packets associated with the first communication protocol to the industrial device [¶0056 end devices for e.g. modifying air temperature notified with command thus translated to BACnet].
Regarding claim 10, Knight teaches:
The method of claim 1, further comprising: receiving, by the edge device, a third packet from a computing device in the industrial facility [¶0033 IoT gateway receives sensor data from Iot devices in industrial facility 102a, Figure 5 ¶0056 receiving sensor data to be compared to a rule]; determining, by the edge device, an operation to be performed by the industrial device that is indicated in the third packet [¶0056 determine operation e.g. reduce temperature or modify air damper]; determining, by the edge device and based on the operation, a plurality of device commands to be executed by the industrial device to perform the operation [¶0056-57, commands include modifying air temperature e.g. at cooling system to decrease temperature or modifying an air damper, among plurality of actions i.e. commands]; creating, by the edge device, a plurality of fourth packets associated with the first communication protocol, wherein each fourth packet among the plurality of fourth packets specifies one or more device commands among the plurality of device commands to be executed by the industrial device [¶0056 step 545 of Figure 5 notifying relevant assets in industrial setting (via fourth packets) 102a of solution to modify the air temperature and adjust the power]]; and transmitting, by the edge device, the plurality of fourth packets associated with the first communication protocol to the industrial device [¶0056 end devices for e.g. modifying air temperature notified with command thus translated to BACnet]..
Regarding claim 11, Knight teaches:
An edge device of an industrial facility, the edge device comprising: a memory storing instructions; and a processor communicatively coupled to the memory and configured to execute the instructions to: [¶0027, IoT gateway 125 Figure 1 performing edge based control], receive a plurality of first packets associated with a first communication protocol from an industrial device of the industrial facility [¶0031, Figure 1 102a is an industrial building ¶0031 connected to external network via IoT gateway 125, receive data from IoT devices on BACnet (BACnet being first protocol)];
Extract device data associated with the industrial device from the plurality of first packets associated with the first communication protocol [¶0033 IoT gateway evaluates and filters the data corresponding to extracting, the data being sensor data ¶0031 considered device data];
create a second packet associated with a second communication protocol, the second packet including the device data associated with the industrial device in the plurality of first packets [¶0033, translation between BACnet and Internet communication protocol corresponding to creating a second packet];
and transmit the second packet associated with the second communication protocol to a cloud platform to manage an industrial digital twin on the cloud platform based on the second packet [¶0033, “The IoT Gateway 125 may connect the devices 110 and the controllers 113 to the Intelligent Building Cloud Platform 165 over a network 160” ¶0036 building cloud platform creates and manipulates digital twin 180].
Regarding claim 12, Knight teaches:
The edge device of claim 11, wherein: the industrial digital twin is one of a virtual model of the industrial device or a virtual model of an industrial system that includes the industrial device [¶0034-36 digital twin of building 102 in edge and cloud 165, comprising industrial devices 110a-g].
Regarding claim 19, Knight teaches:
The edge device of claim 11, wherein the processor is further configured to execute the instructions to:
receive a third packet associated with the second communication protocol from a twin model management system implemented on the cloud platform [¶0056, twin management model sends notification via gateway see Figure 1 to IoT devices in industrial area corresponding to third packet of second communication protocol, wherein ¶0032-33 IoT gateway connects twin to the devices in 102a thus gateway receives these packets]; determine an operation to be performed by the industrial device that is indicated in the third packet associated with the second communication protocol [step 545, ¶0054-56 gateway provides control to devices by e.g. determining an action related to temperature control for cooling devices, determine an action e.g. cooling via temperature controller]; determine, based on the operations, a plurality of device commands to be executed by the industrial device to perform the operation [¶0056, commands include modifying air temperature e.g. at cooling system to decrease temperature]; create a plurality of fourth packets associated with the first communication protocol, wherein each fourth packet among the plurality of fourth packets specifies one or more device commands among the plurality of device commands to be executed by the industrial device [¶0056 notifying relevant assets of solution to modify the air temperature and adjust the power]; and transmit the plurality of fourth packets associated with the first communication protocol to the industrial device [¶0056 end devices for e.g. modifying air temperature notified with command thus translated to BACnet].
Regarding claim 20, Knight teaches:
A non-transitory computer-readable medium storing instructions that, when executed, direct a processor of a computing device to: [¶0027, IoT gateway 125 Figure 1 performing edge based control corresponding to non-transitory computer readable medium as gateway devices known to include these components], receive a plurality of first packets associated with a first communication protocol from an industrial device of the industrial facility [¶0031, Figure 1 102a is an industrial building ¶0031 connected to external network via IoT gateway 125, receive data from IoT devices on BACnet (BACnet being first protocol)];
Extract device data associated with the industrial device from the plurality of first packets associated with the first communication protocol [¶0033 IoT gateway evaluates and filters the data corresponding to extracting, the data being sensor data ¶0031 considered device data];
create a second packet associated with a second communication protocol, the second packet including the device data associated with the industrial device in the plurality of first packets [¶0033, translation between BACnet and Internet communication protocol corresponding to creating a second packet];
and transmit the second packet associated with the second communication protocol to a cloud platform to manage an industrial digital twin on the cloud platform based on the second packet [¶0033, “The IoT Gateway 125 may connect the devices 110 and the controllers 113 to the Intelligent Building Cloud Platform 165 over a network 160” ¶0036 building cloud platform creates and manipulates digital twin 180].
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 3, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Knight et al. (“Knight”) (US 20210006622 A1) in view of Fedorov et al. (“Fedorov”) (US 20200351380 A1) and Hammons et al. (“Hammons”) (US 20180234489 A1).
Regarding claim 3, Knight teaches:
The method of claim 1.
Knight teaches BACnet with IoT devices and a cloud network but does not mention latency.
Fedorov teaches wherein: the first communication protocol is a low-latency communication protocol [¶0064, IoT network with software ensuring low-latency]; and the second communication protocol is a high-latency communication protocol [¶0049, devices in cloud will have high latency when data processing occurs at the cloud].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify low-latency and high-latency aspects of the first and second protocols. Knight teaches a first protocol corresponding to IoT and it would have been obvious to specify this is low-latency compared to the cloud network as in Fedorov teaches ¶0020 IoT devices require low latency.
Knight-Fedorov teaches data of different latency but not sizes.
Hammons teaches wherein a maximum packet size associated with the first communication protocol is lower than a maximum packet size associated with the second communication protocol [¶0124, gateway bridging IoT networks to cloud will aggregate data packets from IoT devices into larger packets for further transmission, thus data packets from the IoT devices or first protocol are smaller than the aggregated packets forwarded].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify the packet size of the first protocol is lower than the size of the second protocol as in Hammons who teaches that the difference in packet size as a result of aggregation allows for automatically adjusting workloads and load balancing ¶0122-123.
Regarding claim 13, Knight teaches:
The edge device of claim 11.
Knight teaches BACnet with IoT devices and a cloud network but does not mention latency.
Fedorov teaches wherein: the first communication protocol is a low-latency communication protocol [¶0064, IoT network with software ensuring low-latency]; and the second communication protocol is a high-latency communication protocol [¶0049, devices in cloud will have high latency when data processing occurs at the cloud].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify low-latency and high-latency aspects of the first and second protocols. Knight teaches a first protocol corresponding to IoT and it would have been obvious to specify this is low-latency compared to the cloud network as in Fedorov teaches ¶0020 IoT devices require low latency.
Knight-Fedorov teaches data of different latency but not sizes.
Hammons teaches wherein a maximum packet size associated with the first communication protocol is lower than a maximum packet size associated with the second communication protocol [¶0124, gateway bridging IoT networks to cloud will aggregate data packets from IoT devices into larger packets for further transmission, thus data packets from the IoT devices or first protocol are smaller than the aggregated packets forwarded].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify the packet size of the first protocol is lower than the size of the second protocol as in Hammons who teaches that the difference in packet size as a result of aggregation allows for automatically adjusting workloads and load balancing ¶0122-123.
Claim(s) 4, 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Knight et al. (“Knight”) (US 20210006622 A1) in view of Hammons et al. (“Hammons”) (US 20180234489 A1) and Ozen et al. (“Ozen”) (US 20180262432 A1).
Regarding claim 4, The method of claim 1.
Knight teaches translating but not aggregating.
Hammons teaches wherein creating the second packet associated with the second communication protocol includes: aggregating the device data associated with the industrial device in the plurality of first packets to form data of the second packet [¶0124, aggregate data packets].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify the packet size of the first protocol is lower than the size of the second protocol as in Hammons who teaches that the difference in packet size as a result of aggregation allows for automatically adjusting workloads and load balancing ¶0122-123.
Knight-Hammons teaches aggregating but not metadata.
Ozen teaches and generating metadata for the second packet, wherein for each first packet among the plurality of first packets, the metadata indicates a portion within the data of the second packet that corresponds to the first packet [¶0058].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify generating metadata in the aggregated packets as in Ozen who teaches ¶0011 to associate each payload copy with one of the plurality of clients.
Regarding claim 14, the edge device of claim 11.
Knight teaches translating but not aggregating.
Hammons teaches wherein creating the second packet associated with the second communication protocol includes: aggregating the device data associated with the industrial device in the plurality of first packets to form data of the second packet [¶0124, aggregate data packets].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify the packet size of the first protocol is lower than the size of the second protocol as in Hammons who teaches that the difference in packet size as a result of aggregation allows for automatically adjusting workloads and load balancing ¶0122-123.
Knight-Hammons teaches aggregating but not metadata.
Ozen teaches and generating metadata for the second packet, wherein for each first packet among the plurality of first packets, the metadata indicates a portion within the data of the second packet that corresponds to the first packet [¶0058].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify generating metadata in the aggregated packets as in Ozen who teaches ¶0011 to associate each payload copy with one of the plurality of clients.
Claim(s) 5-6, 15-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Knight et al. (“Knight”) (US 20210006622 A1) in view of Marzorati et al. (“Marzorati”) (US 20220165438 A1).
Regarding claim 5, Knight teaches:
The method of claim 1, wherein the cloud platform includes a twin model management system, the twin model management system [¶0051, Figure 5, performed by system of claim 1, considered cloud platform with twin management system] is configured to:
receive the second packet associated with the second communication protocol from the edge device [¶0052, sensor data, corresponding to second packet, obtained from devices in 102a]; extract the device data associated with the industrial device from the second packet based on metadata of the second packet [¶0052-53, evaluate sensor data thus extracted, based on identification information corresponding to the second packet obtained as in ¶0044 from received information]; and compare the device data associated with the industrial device to simulation data associated with the industrial device [¶0054-56 comparing actual measurements (device data) to rules indicating thresholds (simulation data)].
Knight teaches comparing to rules but not expressly a simulation generated at the digital twin.
Marzorati teaches simulation data generated by the industrial digital twin [¶0059, simulations compared to IoT devices in the physical world]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify that the simulation is generated by the digital twin as in Marzorati. Knight teaches comparing to rules associated with the twins and it would have been obvious to specify the digital twin in the cloud generated the simulation as in Marzorati to prevent exceeding a duty cycle or overheating ¶0059.
Regarding claim 6, Knight-Marzorati teaches:
The method of claim 5, wherein the twin model management system is further configured to: determine, based on the comparing, that an actual value of a particular parameter in the device data associated with the industrial device is different from a simulated value of the particular parameter in the simulation data associated with the industrial device generated by the industrial digital twin [Knight ¶0056 determine temperature different from rule associated with digital twin, where rule may be simulation corresponding to the digital twin in the cloud, as in Marzorati ¶0059].
Knight teaches altering a parameter of an end device but not necessarily providing a notification.
Marzorati teaches and provide, in response to the determining, a notification to a user indicating that the actual value of the particular parameter is different from the simulated value of the particular parameter generated by the industrial digital twin [Marzorati ¶0059 comparison to simulation results in a warning sent to user of device].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify the notification as in Marzorati to prevent exceeding a duty cycle or overheating ¶0059.
Regarding claim 15, Knight-Marzorati teaches:
A system comprising the edge device of claim 11 and a twin model management system implemented on the cloud platform [¶0051, Figure 5, performed by system of claim 1, considered cloud platform with twin management system], wherein the twin model management system is configured to: receive the second packet associated with the second communication protocol from the edge device [¶0052, sensor data, corresponding to second packet, obtained from devices in 102a]; extract the device data associated with the industrial device from the second packet based on metadata of the second packet [¶0052-53, evaluate sensor data thus extracted]; and compare the device data associated with the industrial device to simulation data associated with the industrial device [¶0054-56 comparing actual measurements (device data) to rules indicating thresholds (simulation data)].
Knight teaches comparing to rules but not expressly a simulation generated at the digital twin.
Marzorati teaches simulation data generated by the industrial digital twin [¶0059, simulations compared to IoT devices in the physical world]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify that the simulation is generated by the digital twin as in Marzorati. Knight teaches comparing to rules associated with the twins and it would have been obvious to specify the digital twin in the cloud generated the simulation as in Marzorati to prevent exceeding a duty cycle or overheating ¶0059.
Regarding claim 16, Knight-Marzorati teaches:
The system of claim 15, wherein the twin model management system is further configured to:
determine, based on the comparing, that an actual value of a particular parameter in the device data associated with the industrial device is different from a simulated value of the particular parameter in the simulation data associated with the industrial device generated by the industrial digital twin [Knight ¶0056 determine temperature different from rule associated with digital twin, where rule may be simulation corresponding to the digital twin in the cloud, as in Marzorati ¶0059].
Knight teaches altering a parameter of an end device but not necessarily providing a notification.
Marzorati teaches and provide, in response to the determining, a notification to a user indicating that the actual value of the particular parameter is different from the simulated value of the particular parameter generated by the industrial digital twin [Marzorati ¶0059 comparison to simulation results in a warning sent to user of device].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify the notification as in Marzorati to prevent exceeding a duty cycle or overheating ¶0059.
Claim(s) 7, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Knight et al. (“Knight”) (US 20210006622 A1) in view of Marzorati et al. (“Marzorati”) (US 20220165438 A1) and Hunt et al. (“Hunt”) (US 20220067232 A1).
Regarding claim 7, Knight-Marzorati teaches:
The method of claim 6.
Knight- Marzorati teaches a notification but does not teach synchronizing the twin.
Hunt teaches wherein the twin model management system is further configured to: receive, in response to the notification, a user request to synchronize the industrial digital twin with the industrial device; and update, in response to the user request, the simulated value of the particular parameter in the industrial digital twin to be equal to the actual value of the particular parameter in the device data associated with the industrial device [¶0027, receive user request to update twin, and update the digital twin considered synchronizing to reflect the change in the existing network devices of the environment].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify updating the twin to reflect the environment i.e. synchronizing as in Hunt. It would have been obvious to teach updating the values of the twin to reflect the changes in the replicated system as in Hunt for determining placement of devices ¶0030-31.
Regarding claim 17, Knight-Marzorati teaches:
The system of claim 16.
Knight- Marzorati teaches a notification but does not teach synchronizing the twin.
Hunt teaches wherein the twin model management system is further configured to: receive, in response to the notification, a user request to synchronize the industrial digital twin with the industrial device; and update, in response to the user request, the simulated value of the particular parameter in the industrial digital twin to be equal to the actual value of the particular parameter in the device data associated with the industrial device [¶0027, receive user request to update twin, and update the digital twin considered synchronizing to reflect the change in the existing network devices of the environment].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify updating the twin to reflect the environment i.e. synchronizing as in Hunt. It would have been obvious to teach updating the values of the twin to reflect the changes in the replicated system as in Hunt for determining placement of devices ¶0030-31.
Claim(s) 8, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Knight et al. (“Knight”) (US 20210006622 A1) in view of Marzorati et al. (“Marzorati”) (US 20220165438 A1) and Hoelgaard et al. (“Hoelgaard”) (US 20220373995 A1).
Regarding claim 8, Knight-Marzorati teaches:
The method of claim 6, a notification [Marzorati ¶0059 comparison to simulation results in a warning sent to user of device see rationale for combination as in claim 6], creating a third packet indicating the operation to be performed by the industrial device, the third packet being associated with the second communication protocol; and transmit the third packet associated with the second communication protocol to the edge device [¶0054-56 of Knight, packets to control devices in industrial area 102a e.g. reducing temperature of a system, generated in network and sent to end devices via IoT gateway ¶0033 according to internet protocol to be translated to BACnet protocol].
Knight teaches sending commands but not based on user request.
Hoelgaard teaches a twin wherein the twin model management system is further configured to: receive, in response to the notification, a user request specifying an operation to be performed by the industrial device; create, in response to the user request, a third packet indicating the operation to be performed by the industrial device; and transmit the third packet associated with the second communication protocol [¶0011-16, digital twin system receives request from user, transmits control to pump system to modify a parameter, Figure 6 shows message from digital twin sent to end device via connectivity module ¶0096].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify taking a user request and modifying an industrial equipment as in Hoelgaard who teaches this allows for improved monitoring and control system with user friendly interface ¶0009.
Regarding claim 18, Knight-Marzorati teaches:
The system of claim 16, a notification [Marzorati ¶0059 comparison to simulation results in a warning sent to user of device see rationale for combination as in claim 16]; create a third packet indicating the operation to be performed by the industrial device, the third packet being associated with the second communication protocol; and transmit the third packet associated with the second communication protocol to the edge device [¶0054-56 of Knight, packets to control devices in industrial area 102a e.g. reducing temperature of a system, generated in network and sent to end devices via IoT gateway ¶0033 according to internet protocol to be translated to BACnet protocol].
Knight teaches sending commands but not based on user request.
Hoelgaard teaches a twin wherein the twin model management system is further configured to: receive, in response to the notification, a user request specifying an operation to be performed by the industrial device; create, in response to the user request, a third packet indicating the operation to be performed by the industrial device; and transmit the third packet associated with the second communication protocol [¶0011-16, digital twin system receives request from user, transmits control to pump system to modify a parameter, Figure 6 shows message from digital twin sent to end device via connectivity module ¶0096].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify taking a user request and modifying an industrial equipment as in Hoelgaard who teaches this allows for improved monitoring and control system with user friendly interface ¶0009.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAY L. VOGEL whose telephone number is (303)297-4322. The examiner can normally be reached Monday-Friday 8AM-4:30 PM MT.
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, Joseph Avellino can be reached at 571-272-3905. 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.
/JAY L VOGEL/Primary Examiner, Art Unit 2478