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 .
Response to Amendment
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 08/13/2025 has been entered.
Claim 6 has been canceled. Claims 1-5 and 7-18 are presented for examination.
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.
Claims 1-5, 7, 10-16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mukkamala (US 2017/0192414) in view of Nair (US 2019/0342154).
Regarding claim 1, Mukkamala teaches a method of configuring an Internet of Things, IoT, device for collecting data from industrial devices, wherein the IoT device is coupled to an IoT platform via a communication channel (Figs. 1 and 2, [0040, 0072, 0094], an IIoT machine e.g., a gateway, uses a network/channel to connect a IIoT cloud platform with an asset; for example, the IIoT machine can gather sensor data from industrial assets and send them to the cloud),
wherein the IoT platform stores device twin data of the industrial devices, the device twin data including configuration information ([0062-0063], the IIoT cloud maintains a model of each industrial asset, which is updated based on information relating to the corresponding asset; the asset model is a digital representation/twin of the corresponding asset and its structure; the cloud also stores a variety of configuration data that it can provide to the IIoT machine e.g., tokens to facilitate communication with the IIoT machine; updates for the industrial assets, including new ones; periodic, automatic updates to the IIoT machine etc.; see [0047-0049, 0098-0100, 0086-0088, 0119-0120]),
the method comprising:
retrieving, by the IoT device and via the communication channel, the configuration information from the device twin data stored in the IoT platform ([0098-0100], the cloud can send configuration data e.g., tokens, to the IIoT machine which help the IIoT machine establish data communication paths between the IIoT machine and the cloud e.g., to facilitate collection of data and transmission of sensor data from the industrial assets to the IIoT machine and cloud, as described in [0072]; as noted in [0088], the IIoT machine can be remotely configured e.g., by the cloud);
retrieving, by the IoT device, additional configuration information from the IoT platform (the cloud also stores a variety of configuration data that it can provide to the IIoT machine e.g., tokens to facilitate communication with the IIoT machine; updates for the industrial assets, including new ones; periodic, automatic updates to the IIoT machine etc.; see [0047-0049, 0098-0100, 0086-0088, 0119-0120]; as noted in [0088], the IIoT machine can be remotely configured e.g., by the cloud, as described in [0120]); and
using automatically, by the IoT device, the configuration information for collecting
data from the industrial devices ([0098-0100], the cloud can send configuration data e.g., tokens, to the IIoT machine which help the IIoT machine establish data communication paths between the IIoT machine and the cloud e.g., to facilitate collection of data and transmission of sensor data from the industrial assets to the IIoT machine and cloud, as described in [0072]; the usage of the tokens by the IIoT machine to establish communication paths is at least partially automatic i.e., driven by computer instructions, as described in Mukkamala Fig. 16, [0222]; as noted in [0088], the IIoT machine can be remotely configured e.g., by the cloud, as described in [0120]).
However, Mukkamala does not expressly disclose the retrieving the additional configuration information in response to establishment of a communicative coupling between the IoT device and an additional industrial device.
In the same field of endeavor, Nair teaches the retrieving the additional configuration information in response to establishment of a communicative coupling between the IoT device and an additional industrial device (Figs. 3, 5-8, Abstract, [0059, 0063-0065, 0057, 0003-0004], as described in Fig. 6, [0063-0065], when a gateway discovers a new IoT device i.e., whether is some kind of initial detection/communication coupling between the gateway and the new IoT device, the IoT device requests configuration data from the cloud (a configuration service), and receives the configuration data; see also Mukkamala [0086], where a gateway similarly identifies/discovers/initially connects with a new device).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to have incorporated the retrieving the additional configuration information in response to establishment of a communicative coupling between the IoT device and an additional industrial device as suggested in Nair into Mukkamala because Mukkamala and Nair pertain to analogous fields of technology. Mukkamala pertains to a system with a gateway (IIoT machine), which connects an industrial asset to a cloud platform. When a new asset is detected, the gateway communicates with the cloud to obtain configuration information e.g., to register the asset or obtain configuration data for the asset, see Mukkamala [0086-0087]. Nair also pertains to a gateway that detects a new device and obtains configuration information for the device. In Nair, upon the gateway discovering the new device, the gateway requests and retrieves the configuration information. It would be desirable to incorporate this feature into Mukkamala to enable the Mukkamala invention to use a known method for obtaining configuration information for a newly detected device e.g., see Nair Figs. 3, 5-8, Abstract, [0059, 0063-0065, 0057, 0003-0004], as described in Fig. 6, [0063-0065].
Regarding claim 2, the combination of Mukkamala and Nair teaches the invention as claimed in claim 1. The combination of Mukkamala and Nair further teaches “wherein using the configuration information comprises configuring a data collection logic of the IoT device (Mukkamala, at ¶ [0072], IIoT machine can be configured to provide various functions to gather sensor data, process such data locally, and then push it to the IIoT cloud; Mukkamala [0098-0100], the cloud can send configuration data e.g., tokens, to the IIoT machine which help the IIoT machine establish data communication paths between the IIoT machine and the cloud e.g., to facilitate collection of data and transmission of sensor data from the industrial assets to the IIoT machine and cloud, as described in [0072]; as noted in [0088], the IIoT machine can be remotely configured e.g., by the cloud, as described in [0120]; see also Nair Abstract, [0003-0004, 0058-0061, 0065], the processing of the configuration data performed by the gateway relates to data collection logic i.e., the gateway uses the configuration data to parse the data received from the IoT devices and convert/transform them into a suitable form before it is collected by the configuration service/cloud; as noted in [0063], the received configuration data also enables the gateway to connect to the IoT device, thereby enabling data collection).
Regarding claim 3, the combination of Mukkamala and Nair teaches the invention as claimed in claim 2. The combination of Mukkamala and Nair further teaches “wherein configuring the data collection logic comprises setting one or several of: protocol address of datapoints for read, write, or execute operations; read intervals; timeouts; rules for data transformation; parameters of data transmission from the IoT device to the IoT platform (Mukkamala, at ¶ [0076], various industrial machines can be coupled with the IIoT machine via one or more wired or wireless communication protocols, such as over the M2M gateway, many assets or machines can support connectivity through industrial protocols such as Open Platform Communication (OPC)-UA or ModBus, A machine gateway component in the IIoT machine provide an extensible plug-in framework that enables connectivity to assets via the M2M gateway based on these common industrial protocols or using other protocols; Mukkamala [0098-0100], the IIoT machine can receive tokens from the IIoT cloud, which are used to establish data transmission paths from the IIoT machine to the IIoT cloud; see also Nair Abstract, [0003-0004, 0058-0061, 0065], the processing of the configuration data performed by the gateway relates to data collection logic i.e., the gateway uses the configuration data to parse the data received from the IoT devices and convert/transform them into a suitable form before it is collected by the configuration service/cloud; as noted in [0063], the received configuration data also enables the gateway to connect to the IoT device, thereby enabling data collection; see also Nair [0060-0061], which describes various data transmission parameters incorporated in the configuration data).
Regarding claim 4, the combination of Mukkamala and Nair teaches the invention as claimed in independent claim 1 and its dependent claim 2. The combination of Mukkamala and Nair further teaches “further comprising collecting, by the IoT device, data from the industrial devices and generating, by the IoT device, data for transmission to the IoT platform, based on the data collected from the industrial devices (Mukkamala, ¶ [0072], the applications reside in the IIoT cloud rely on a local IIoT machine to provide various capabilities, such as to gather sensor data, to process data locally, or to push data to the IIoT cloud; see also Nair ).”
Regarding claim 5, the combination of Mukkamala and Nair teaches the invention as claimed in independent claim 1. The combination of Mukkamala and Nair further teaches “wherein the configuration information comprises a protocol configuration and the method further storing the protocol configuration in the IoT device for use by a data collection logic of the IoT device (Mukkamala, at ¶ [0077], IIoT machine 104 can be coupled with various interface devices via one or more wired or wireless communication protocols, such as over the M2H gateway, so that sensor data from one or more of the industrial machines is received at an application provided at the IIoT machine; see also Nair Abstract, [0003-0004, 0058-0061, 0065], the processing of the configuration data performed by the gateway relates to data collection logic i.e., the gateway uses the configuration data to parse the data received from the IoT devices and convert/transform them into a suitable form/protocol before it is collected by the configuration service/cloud; as noted in [0063], the received configuration data also enables the gateway to connect to the IoT device i.e., a connection protocol, thereby enabling data collection; see also Nair [0060-0061], which describes various data transmission parameters incorporated in the configuration data).
Regarding claim 7, the combination of Mukkamala and Nair teaches the invention as claimed in independent claim 1. The combination of Mukkamala and Nair further teaches “wherein the device twin data, uses a strongly typed definition to model data associated with an industrial device and the configuration information associated with the industrial device (Mukkamala [0141-0142], the asset services module can include API layer/REST APIs used to create and store asset models; for example, the REST AI layer provides a JSON interface to describe objects, and involve translating data from JSON to Resource Description Framework (RDF) triples for storage and query i.e., the above involve strongly typed data/definitions, or data that is structured and defined).
Regarding claim 10, the combination of Mukkamala and Nair teaches the invention as claimed in independent claim 1. The combination of Mukkamala and Nair further teaches “wherein the industrial devices comprise devices of an industrial automation control system (Mukkamala [0075], the industrial machines include manufacturing or automation assets (e.g., robots, etc.).).”
Regarding claim 11, the combination of Mukkamala and Nair teaches the invention as claimed in independent claim 1. The combination of Mukkamala and Nair further teaches “wherein the IoT device is an loT Edge device or Gateway device (Mukkamala [0041], one responsibility of the IIoT machine can be to provide secure, bi-directional cloud connectivity to, and management of, industrial assets, while also enabling applications (e.g., analytical or operational services applications) at the edge of the IIoT.).”
Regarding claim 12, Mukkamala teaches an Internet of Things, IoT, device for collecting data from industrial devices, comprising:
at least one first interface adapted to communicatively couple the IoT device with the industrial devices ([0040], the industrial asset is a member of an asset community, and the IIoT machine can be coupled to one or more members of an asset community; see also Fig. 1, [0040, 0044], the IIoT device is connected via a network to an industrial asset and the cloud; see also [0238], which describes interfaces/communication components);
a second interface adapted to communicatively couple the IoT device to a IoT platform ([0041], a IIoT cloud, to which the IIoT machine connects, includes various modules and application services, and the IIoT machine can support gateway solutions that connect multiple edge components via various industry standard protocols, such as to meet various requirements for industrial connectivity as described at [0042]; see also Fig. 1, [0040, 0044], the IIoT device is connected via a network to an industrial asset and the cloud; see also [0238], which describes interfaces/communication components);
a memory or storage device adapted to store configuration information which is retrieved via the second interface from device twin data of the industrial devices stored in the IoT platform ([0086-88, 0098, 0100], the IIoT machine has memory that can receive and store configuration information from the cloud; "device twin data" can be interpreted as any data related to a device twin; the cloud also stores a variety of configuration data that it can provide to the IIoT machine e.g., tokens to facilitate communication with the IIoT machine; updates for the industrial assets, which are passed to assets via the IIoT machine in response to the IIoT machine identifying new or changed assets, and informing the cloud to receive configuration information from the cloud; periodic, automatic updates to the IIoT machine etc.; see [0047-0049, 0098-0100, 0086-0088, 0119-0120]; as noted in [0088], the IIoT machine can be remotely configured e.g., by the cloud, as described in [0120]; [0047, 0049, 0062, 0063, 0065], an asset model i.e., device twin data, can be used to generate configuration data for the corresponding asset).
However, Mukkamala does not expressly disclose a circuit adapted to automatically use the retrieved configuration information to collect, via the at least one first interface, data from the industrial devices; the retrieval in response to establishment of a communicative coupling between the IoT device and the industrial devices.
In the same field of endeavor, Nair teaches a circuit adapted to automatically use the retrieved configuration information to collect, via the at least one first interface, data from the industrial devices (Figs. 3, 5-8, Abstract, [0059, 0063-0065, 0057, 0003-0004], claim 1, a gateway device can obtain configuration data from a configuration service server; the configuration service server can store distinct configuration data for various types of devices; the gateway device can be connected to various client devices and receive data collected by them; the gateway device can then use the configuration data to convert the received data into a standardized data model; the gateway device has a circuit to perform these functions e.g., see [0010, 0040-0042], which describes a processor and other circuit elements);
the retrieval in response to establishment of a communicative coupling between the IoT device and the industrial devices (Figs. 3, 5-8, Abstract, [0059, 0063-0065, 0057, 0003-0004], as described in Fig. 6, [0063-0065], when a gateway discovers a new IoT device i.e., when there is some kind of initial detection/communication coupling between the gateway and the new IoT device, the IoT device requests configuration data from the cloud (a configuration service), and receives the configuration data; see also Mukkamala [0086], where a gateway similarly identifies/discovers/initially connects with a new device).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to have incorporated a circuit adapted to automatically use the retrieved configuration information to collect, via the at least one first interface, data from the industrial devices; the retrieval in response to establishment of a communicative coupling between the IoT device and the industrial devices as suggested in Nair into Mukkamala because Mukkamala and Nair pertain to analogous fields of technology. Mukkamala pertains to a system in which a IIoT device (gateway device) is connected to a cloud server and one or more industrial devices, which collect data. The cloud server provides configuration data to the IIoT device to help manage and handle the connected industrial devices, and the industrial devices collect data, which is passed to the cloud server via the IIoT device. (For example, as noted in Mukkamala [0086-0087], the IIoT may obtain configuration data from the cloud upon discovery of a new industrial device, to help manage the device). Nair also pertains to a system in which a gateway device is connected to a server and one or more data collection devices, which collect data that is passed on to the gateway device. In Nair, the server provides configuration data to the gateway devices in response to the gateway informing the server that new devices have been discovered, and the configuration data is used to improve the collection of data from the data collection devices i.e., the configuration data is used to process the collected data and convert it into a more suitable format. It would be desirable to incorporate the above features into Mukkamala, to provide a known method for retrieving configuration data when a new device is discovered, and also to configure a gateway to better process data from devices e.g., see Nair Abstract, [0059, 0063-0065, 0057, 0003-0004], claim 1.
Regarding claim 13, the combination of Mukkamala and Nair teaches the invention as claimed in claim 12. The combination of Mukkamala and Nair also teaches
retrieve, via a communication channel, the configuration information from the device twin data stored in the IoT platform (Mukkamala [0088], configuration management module of the IIoT machine can be configured to allow remote configuration of the IIoT machine or one or more of the industrial machines from the IIoT cloud; Mukkamala [0086-88, 0098, 0100], the IIoT machine has memory that can receive and store configuration information from the cloud; "device twin data" can be interpreted as any data related to a device twin; the cloud also stores a variety of configuration data that it can provide to the IIoT machine e.g., tokens to facilitate communication with the IIoT machine; updates for the industrial assets, which are passed to assets via the IIoT machine in response to the IIoT machine identifying new or changed assets, and informing the cloud to receive configuration information from the cloud; periodic, automatic updates to the IIoT machine etc.; see Mukkamala [0047-0049, 0098-0100, 0086-0088, 0119-0120]; as noted in [0088], the IIoT machine can be remotely configured e.g., by the cloud, as described in [0120]; Mukkamala [0047, 0049, 0062, 0063, 0065], an asset model/device twin data can be used to generate configuration data for the corresponding asset); and
use the configuration information for collecting data from the industrial devices (Mukkamala [0094], the sensors nodes can be configured to receive or collect industrial machine data and then provide the data to the IIoT cloud through an IIoT gateway; see also Nair Figs. 3, 5-8, Abstract, [0059, 0063-0065, 0057, 0003-0004], claim 1, a gateway device can obtain configuration data from a configuration service server; the configuration service server can store distinct configuration data for various types of devices; the gateway device can be connected to various client devices and receive data collected by them; at the gateway device, the configuration data from the server can be used to convert the received data into a standardized data model; see also Nair [0063, 0060-0061], the configuration data also enables the gateway to connect to the device for data retrieval).
Claim 14 corresponds to claim 15 and is rejected for the same reasons.
Regarding claim 15, Mukkamala teaches a system, comprising:
a plurality of industrial devices (Fig. 1, [0075, 0040], IIoT machine is coupled with one or more industrial machines);
an IoT device for collecting data from the industrial devices (Fig. 1, [0040-0044] describes an IIoT machine that can receive data collected by sensors on the industrial assets); and
an IoT platform computer system communicatively coupled to the IoT device (Fig. 1, [0072, 0040], the IoT machine can be configured to provide various functions to gather sensor data, process such data locally, and then push it to the IIoT cloud; see Fig. 1, [0040], the cloud 106 is connected to industrial asset 102 via IIoT machine 104), the IoT platform computer system having:
a memory or storage device adapted to store device twin data of the industrial devices ([0086-0088], configuration management module of the IIoT machine can be configured to allow remote configuration of the IoT machine or one or more of the industrial machines from the IIoT cloud; see claim language below, which defines device twin data as also including any configuration information; see also [0045-0046, 0050-0053, 0062, 0138-0140, 0146, 0152], which describes asset models, which can model and simulate an industrial asset; such asset models can be used to optimize parameters; see also Figs. 16-17, [0222, 0232], which describe memory)
wherein the device twin data for the industrial devices includes configuration information ([0086-0088], the IIoT cloud can also store configuration information, which can be sent to the IIoT machine; see also [0098, 0100] for other examples of configuration information sent from the cloud to the IIoT machine); and
an interface adapted to output the configuration information to the IoT device ([0086-88, 0098, 0100], the IIoT cloud can also store configuration information, which can be sent to the IIoT machine; see also [0238], which describes interfaces/communication components)
the IoT device having:
at least one first interface adapted to communicatively couple the IoT device with the industrial devices ([0040], the industrial asset is a member of an asset community, and the IIoT machine can be coupled to one or more members of an asset community; see also Fig. 1, [0040, 0044], the IIoT device is connected via a network to an industrial asset and the cloud; see also [0238], which describes interfaces/communication components);
a second interface adapted to communicatively couple the IoT device to the IoT platform computer system ([0041], a IIoT cloud, to which the IIoT machine connects, includes various modules and application services, and the IIoT machine can support gateway solutions that connect multiple edge components via various industry standard protocols, such as to meet various requirements for industrial connectivity as described at [0042]; see also Fig. 1, [0040, 0044], the IIoT device is connected via a network to an industrial asset and the cloud; see also [0238], which describes interfaces/communication components);
a memory or storage device adapted to store the configuration information which is retrieved via the second interface from the IoT platform computer system ([0086-88, 0098, 0100], the IIoT machine has memory that can receive and store configuration information from the cloud; as noted above, "device twin data" has been defined in the claim as including any configuration information; the cloud also stores a variety of configuration data that it can provide to the IIoT machine e.g., tokens to facilitate communication with the IIoT machine; updates for the industrial assets, which are passed to assets via the IIoT machine in response to the IIoT machine identifying new or changed assets; periodic, automatic updates to the IIoT machine etc.; see [0047-0049, 0098-0100, 0086-0088, 0119-0120]; as noted in [0088], the IIoT machine can be remotely configured e.g., by the cloud, as described in [0120]).
However, Mukkamala does not expressly disclose the configuration information used by the IoT device when collecting data from the respective industrial device; a circuit adapted to automatically use the retrieved configuration information to collect, via the at least one first interface, data from the industrial devices; the retrieving the configuration information in response to establishment of a communicative coupling between the IoT device and the industrial devices.
In the same field of endeavor, Nair teaches
the configuration information used by the IoT device when collecting data from the respective industrial device (Figs. 3, 5-8, Abstract, [0059, 0063-0065, 0057, 0003-0004], claim 1, a gateway device can obtain configuration data from a configuration service server; the configuration service server can store distinct configuration data for various types of devices; the gateway device can be connected to various client devices and receive data collected by them; at the gateway device, the configuration data from the server can be used to convert the received data into a standardized data model)
a circuit adapted to automatically use the retrieved configuration information to collect, via the at least one first interface, data from the industrial devices (Figs. 3, 5-8, Abstract, [0059, 0063-0065, 0057, 0003-0004], claim 1, a gateway device can obtain configuration data from a configuration service server; the configuration service server can store distinct configuration data for various types of devices; the gateway device can be connected to various client devices and receive data collected by them; the gateway device can then use the configuration data to convert the received data into a standardized data model; the gateway device has a circuit to perform these functions e.g., see [0010, 0040-0042], which describes a processor and other circuit elements);
the retrieving the configuration information in response to establishment of a communicative coupling between the IoT device and the industrial devices (Figs. 3, 5-8, Abstract, [0059, 0063-0065, 0057, 0003-0004], as described in Fig. 6, [0063-0065], when a gateway discovers a new IoT device i.e., when there is some kind of initial detection/communication coupling between the gateway and the new IoT device, the IoT device requests configuration data from the cloud (a configuration service), and receives the configuration data; see also Mukkamala [0086], where a gateway similarly identifies/discovers/initially connects with a new device).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to have incorporated the configuration information used by the IoT device when collecting data from the respective industrial device; a circuit adapted to automatically use the retrieved configuration information to collect, via the at least one first interface, data from the industrial devices; the retrieving the configuration information in response to establishment of a communicative coupling between the IoT device and the industrial devices as suggested in Nair into Mukkamala because Mukkamala and Nair pertain to analogous fields of technology. Mukkamala pertains to a system in which a IIoT device (gateway device) is connected to a cloud server and one or more industrial devices, which collect data. The cloud server provides configuration data to the IIoT device to help manage and handle the connected industrial devices, and the industrial devices collect data, which is passed to the cloud server via the IIoT device. (For example, as noted in Mukkamala [0086-0087], the IIoT may obtain configuration data from the cloud upon discovery of a new industrial device, to help manage the device). Nair also pertains to a system in which a gateway device is connected to a server and one or more data collection devices, which collect data that is passed on to the gateway device. In Nair, the server provides configuration data to the gateway devices in response to the gateway informing the server that new devices have been discovered, and the configuration data is used to improve the collection of data from the data collection devices i.e., the configuration data is used to process the collected data and convert it into a more suitable format. It would be desirable to incorporate the above features into Mukkamala, to provide a known method for retrieving configuration data when a new device is discovered, and also to configure a gateway to better process data from devices e.g., see Nair Abstract, [0059, 0063-0065, 0057, 0003-0004], claim 1.
Regarding claim 16, the combination of Mukkamala and Nair teaches the invention as claimed in independent claim 1. The combination of Mukkamala and Nair further teaches “wherein the industrial devices are power system devices (Mukkamala, at ¶ [0075], the industrial machines include energy assets (e.g., power generation systems, etc.)
Regarding claim 18, the combination of Mukkamala and Nair teaches the invention as claimed in claim 12. The the combination of Mukkamala and Nair also teaches “wherein the industrial devices are power system devices (Mukkamala, at ¶ [0075], the industrial machines include energy assets (e.g., power generation systems, etc.)
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Mukkamala in view of Nair and further in view of Dotchkoff (US 2019/0123967).
Regarding claim 8, the combination of Mukkamala and Nair teaches the invention as claimed in independent claim 1. The combination of Mukkamala and Nair further teaches the mobile device can send a request to the IIoT cloud via the API gateway to synchronize (sync) data between the local database of the mobile device and the cache and data domain (Mukkamala [0209]). However, Mukkamala does not explicitly teach “further comprising performing a data synchronization of the device twin data between the IoT device and the IoT platform.”
Dotchkoff is in the same field of a mapping is established between IoT devices that are tenants of an IoT support service (Dotchkoff, at Abstract) that synchronizing device twin properties, and executing of operations between the IoT support service and IoT devices (id. at ¶ [0047]).
Accordingly, it would have been obvious to one of ordinary skill in the art at the filing date of this application to modify Mukkamala’s method with performing a data synchronization of the device twin data between the IoT device and the IoT service platform as taught by Dotchkoff because it enables an application in the application backend query the device twin for a list of available operations, as well as possible values for the parameters, present this information to an end user to select the intended operation and possible parameter values, and enable the user to trigger the execution of the operation through the IoT support service (Dotchkoff, at ¶ [0050]).
Regarding claim 9, the combination of Mukkamala, Nair and Dotchkoff teaches the invention as claimed in claim 8. The combination of Mukkamala, Nair and Dotchkoff also teaches “wherein the data synchronization is performed via the communication channel used by the IoT device to retrieve the configuration information, wherein the data synchronization is a bidirectional data synchronization between the IoT device and the IoT platform (Dotchkoff is in the same field of a mapping is established between IoT devices that are tenants of an IoT support service (Dotchkoff, at Abstract) that gateway devices which corresponds to the IoT device, may be edge devices that serve as network intermediaries between one or more IoT devices and an IoT support service (id. at ¶ [0040]), IoT support service stores a corresponding device twin (e.g., DT1, DT2) for each IoT device provisioned with IoT support service, each device twin is a set of securely isolated primitives comprising communication and state synchronization primitives (id. at ¶ [0048], which indicates both direction), in the case of a smart lock, the device twin may include a property indicating whether the corresponding smart lock is locked or unlocked (id. at ¶ [0049], which indicates property of the device is delivered to the IoT support service.) and present this information to an end user to select the intended operation and possible parameter values, and enable the user to trigger the execution of the operation through the IoT support service (id. at ¶ [0050], which indicates user operation from the IoT support service is delivered to the device; see also Mukkamala Figs. 1, 2, [0046-0049, 0062-0063, 0146-0152, 0183-0185], which teaches a bidirectional network channel through which the IIoT machine and cloud exchange any data, including data relating to an asset and asset model i.e., including the data involved in synchronization).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Mukkamala in view of Nair and further in view of LeVine (US 2011/0295575).
Regarding claim 17, the combination of Mukkamala and Nair teaches the invention as claimed in independent claim 1 and claim 10. However, the combination of Mukkamala and Nair does not explicitly teach “wherein the industrial devices comprise devices of a substation automation system.”
LeVine is in the same field of a system and method for modeling resource availability includes a data collection system (LeVine, at Abstract) that collected information may be transferred to and stored in data storage system, the data storage system transfer this stored information to geomatic library and geomatic processing system, geomatic processing system 114 may access, process and analyze the raw remote sensing data to create new data sets that may better describe features and attributes include transmission lines and substations (LeVine, at ¶¶ [0013]-[0014]).
Accordingly, it would have been obvious to one of ordinary skill in the art at the filing date of this application to combine Mukkamala method with the industrial devices comprise devices of a substation system as taught by LeVine because it could optimize the production and transmission of renewable energy (LeVine, at ¶ [0002]).
Response to Arguments
The Examiner acknowledges the Applicant's amendments to claims 12, 14 and 15.
Regarding independent claim 1, Applicant alleges that the cited prior art does not teach the amended limitation, "retrieving, by the IoT device, additional configuration information from the IoT platform in response to establishment of a communicative coupling between the IoT device and an additional industrial device; and using automatically, by the IoT device, the configuration information for collecting data from the industrial devices." Examiner has therefore rejected claim 1 under 35 U.S.C. 103 as being unpatentable over Mukkamala and Nair. Independent claims 12, 14 and 15 were amended in a somewhat similar manner, and likewise were rejected as being taught by Mukkamala and Nair. Some of Applicant's remarks are moot in view of the new grounds of rejection.
Applicant further appears to allege the following: (1) Mukkamala fails to teach the limitation, "using automatically … the configuration information for collecting data" (see page 12 of the reply); (2) Nair also does not teach this feature (see page 13 of the reply); and (3) Nair does not teach "retrieving … additional configuration information from the IoT platform in response to establishment of a communicative coupling between the IoT devices and an additional industrial device" (page 13 of the reply).
Regarding point (1), Applicant alleges that Mukkamala does not teach the "using automatically" operation of claim 1. In the reply, Applicant refers to [0098] of Mukkamala, which discusses an embodiment in which a cloud platform sends configuration data e.g., tokens, to the IIot machine e.g., a gateway, to help the machine establish data communication paths between the IIoT machine and the cloud platform. Since the Mukkamala invention contemplates industrial assets sending data to the IIoT machine, which in turn communicates the data to the cloud platform, this configuration data facilitates "collecting data from the industrial devices." A person of ordinary skill in the art would understand that when the IIoT machine uses the tokens, this process is at least in part automatic. (See for example Mukkamala Fig. 16, [0222], which notes how computer instructions, executed by a processor, are used to implement operations in the Mukkamala invention). Put another way, the claim language, "using automatically … the configuration information for collecting data from the industrial devices" does not require that there be no human involvement in any aspect of a process related to the above limitation. Rather, the above language can be reasonably interpreted to merely require any usage of the configuration information that is automated. In the view of the Examiner, the use of tokens to enable communication paths between the IIoT machine and the cloud platform, as discussed in [0098], is at least partially automated e.g., by executing corresponding computer instructions.
Regarding point (2), Applicant alleges that Nair also does not teach the "using automatically" operation of claim 1. Nair Figs. 3, 5-8, Abstract, [0058-0059, 0063-0065, 0057, 0003-0004], claim 1 describe an embodiment in which a gateway requests configuration data from a cloud service when a new IoT device is discovered, and uses the configuration data to parse and transform data collected from the IoT device, which improves the overall collection of data by the system and the cloud platform. In the view of the Examiner, this usage of the configuration data is "for collecting data from industrial devices." Using the same logic as discussed above in connection with Mukkamala, this usage of the configuration data is also at least partially automatic. That is, computer instructions are being automatically executed to enable the gateway to use the configuration data as described in Nair. Thus, in the view of the Examiner, the above satisfies the requirements of the claim limitation, "using automatically … the configuration information for collecting data."
Regarding point (3), Applicant alleges that Nair fails to teach retrieving configuration information in response to establishment of a communication coupling, because in Nair, configuration information is used for establishing a connection with an IoT device. However, Nair [0062-0063] notes that prior to the above retrieving, the gateway discovers the IoT device. It is this discovery that prompts the gateway to contact the configuration service and retrieve configuration data. Such a discovery naturally involves some form of communication coupling between the newly discovered IoT device and the gateway i.e., some kind of communication or connection must exist between the gateway and IoT device for discovery to occur. For at least the above reasons, Examiner believes that Nair teaches the limitation, "retrieving … additional configuration information … in response to establishment of a communicative coupling between the IoT device and an additional industrial device." See also Mukkamala [0086], which similarly teaches a IIoT machine/gateway initially connecting with/discovering a new device, and then communicating information about the discovered device to a cloud platform.
It should be further noted that the specification of the present application seems to contemplate a similar approach as the one seen in Mukkamala and Nair. The specification does not appear to define what constitutes a "communicative coupling" -- thus, in the view of the Examiner, this term can be reasonably understood as any communication connection. [0160] of the present application implies that this "communicative coupling" can be mere detection i.e., the retrieval of configuration information is triggered by detection of an additional device. As noted above, this is analogous to what is done in Nair and Mukkamala i.e., the gateway detects/discovers a new device, and in response, requests and retrieves configuration data.
Applicant alleges that independent claims 12, 14 and 15 are allowable in view of their similarity to claim 1. Claims 12, 14 and 15 are also rejected as being taught by Mukkamala and Nair.
Applicant further alleges that claims 2-11, 13 and 16-18 are allowable in view of their dependency on claims 1 and 12. Claims 2-11, 13 and 16-18 are rejected as being taught by Mukkamala, Nair, Dotchkoff and/or Levine.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Sarwar (US 2019/0149361) teaches autonomously configuring a gateway to change the frequency and communication methods used for reporting data to a cloud platform e.g., see Sarwar Abstract, [0023-0024, 0039-0041].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC YOON whose telephone number is (408)918-7581. The examiner can normally be reached on 9 am to 5 pm ET Monday through Friday.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Scott Baderman, can be reached at telephone number 571-272-3644. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/ERIC J YOON/Primary Examiner, Art Unit 2118