CTFR 17/906,162 CTFR 93006 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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 Claims 2 and 6 have been canceled. Claims 1, 3-5 and 7-18 are presented for examination. Claim Rejections – 35 USC § 112(b) The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. 07-34-01 AIA Claim 3 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. Claim 3 recites "wherein configuring the data collection logic may include rules for data transformation; or parameters of data transmission …" Due to the usage of the phrase "may include," it is unclear whether the features of claim 3 are optional or required. For the purpose of examination, Examiner interprets the above limitation as meaning that the features of the claim are optional. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 1, 3-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) and further in view of Lawson (US 2020/0314186) . 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 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; using automatically, by the loT device, the configuration information for configuring a data collection logic of the loT device, the data collection logic collecting data from the industrial devices in accordance with the configuration information, wherein the configuration information comprises a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations: read intervals: or timeouts. 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]. However, the combination of Mukkamala and Nair does not expressly disclose using automatically, by the loT device, the configuration information for configuring a data collection logic of the loT device, the data collection logic collecting data from the industrial devices in accordance with the configuration information, wherein the configuration information comprises a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations: read intervals: or timeouts. In the same field of endeavor, Lawson teaches using automatically, by the loT device, the configuration information for configuring a data collection logic of the loT device, the data collection logic collecting data from the industrial devices in accordance with the configuration information, wherein the configuration information comprises a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations: read intervals; or timeouts ([0049, 0050, 0060, 0088], it is known for a cloud platform to update a gateway e.g., by updating a configuration file; the configuration file, for example, can define a data collection interval i.e., a read interval, or an inactivity timeout duration; the gateway collects data from sensors in accordance with the configuration file). 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 using automatically, by the loT device, the configuration information for configuring a data collection logic of the loT device, the data collection logic collecting data from the industrial devices in accordance with the configuration information, wherein the configuration information comprises a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations: read intervals: or timeouts as suggested in Lawson into Mukkamala and Nair because Mukkamala/Nair and Lawson pertain to analogous fields of technology. Mukkamala/Nair pertains to a cloud platform that sends configuration data to a gateway upon it being discovered, where the gateway is configured to collect data from industrial devices/sensors and upload the data to the platform. Lawson also pertains to a cloud platform that collects data from industrial devices/sensors via a gateway, where the cloud platform configures the gateway. In Lawson, the cloud platform can configure a configuration file for the gateway, which can control how data is collected e.g., a data collection interval, a timeout etc. It would be desirable to incorporate this feature into Mukkamala so that the system of Mukkamala could configure the gateway to improve data collection e.g., see Lawson in a variety of known ways e.g., see Lawson [0049, 0050, 0060, 0088]. Regarding claim 3 , the combination of Mukkamala, Nair and Lawson teaches the invention as claimed in claim 1. The combination of Mukkamala, Nair and Lawson further teaches “ wherein configuring the data collection logic may include: rules for data transformation; or parameters of data transmission from the loT device to the loT platform . " (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; Lawson [0049, 0050, 0060, 0088, 0091], it is known for a cloud platform to update a gateway e.g., by updating a configuration file; the configuration file, for example, can define a data collection interval i.e., a read interval, or an inactivity timeout duration; for example, the cloud can command a gateway to adjust a configuration parameter e.g., uploading frequency relating to uploads from the gateway to the cloud platform; the gateway collects data from sensors in accordance with the configuration file). Regarding claim 4 , the combination of Mukkamala, Nair and Lawson teaches the invention as claimed in independent claim 1 and its dependent claim 2. The combination of Mukkamala, Nair and Lawson 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, Nair and Lawson teaches the invention as claimed in independent claim 1. The combination of Mukkamala, Nair and Lawson 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, Nair and Lawson teaches the invention as claimed in independent claim 1. The combination of Mukkamala, Nair and Lawson 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, Nair and Lawson teaches the invention as claimed in independent claim 1. The combination of Mukkamala, Nair and Lawson 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, Nair and Lawson teaches the invention as claimed in independent claim 1. The combination of Mukkamala, Nair and Lawson 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 configure a data collection logic of the IoT device 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; the configuration information having a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations; read intervals; or timeouts; the collecting the data from the industrial devices in accordance with the protocol configuration . In the same field of endeavor, Nair teaches a circuit adapted to automatically use the retrieved configuration information to configure a data collection logic of the IoT device 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 configure a data collection logic of the IoT device 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. However, the combination of Mukkamala and Nair does not expressly disclose the configuration information having a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations; read intervals; or timeouts; the collecting the data from the industrial devices in accordance with the protocol configuration . In the same field of endeavor, Lawson teaches the configuration information having a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations; read intervals; or timeouts; the collecting the data from the industrial devices in accordance with the protocol configuration ([0049, 0050, 0060, 0088], it is known for a cloud platform to update a gateway e.g., by updating a configuration file; the configuration file, for example, can define a data collection interval i.e., a read interval, or an inactivity timeout duration; the gateway collects data from sensors in accordance with the configuration file). 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 having a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations; read intervals; or timeouts; the collecting the data from the industrial devices in accordance with the protocol configuration as suggested in Lawson into Mukkamala and Nair because Mukkamala/Nair and Lawson pertain to analogous fields of technology. Mukkamala/Nair pertains to a cloud platform that sends configuration data to a gateway upon it being discovered, where the gateway is configured to collect data from industrial devices/sensors and upload the data to the platform. Lawson also pertains to a cloud platform that collects data from industrial devices/sensors via a gateway, where the cloud platform configures the gateway. In Lawson, the cloud platform can configure a configuration file for the gateway, which can control how data is collected e.g., a data collection interval, a timeout etc. It would be desirable to incorporate this feature into Mukkamala so that the system of Mukkamala could configure the gateway to improve data collection e.g., see Lawson in a variety of known ways e.g., see Lawson [0049, 0050, 0060, 0088]. Regarding claim 13 , the combination of Mukkamala, Nair and Lawson teaches the invention as claimed in claim 12. The combination of Mukkamala, Nair and Lawson 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 configure a data collection logic of the IoT device 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. However, the combination of Mukkamala and Nair does not expressly disclose the configuration information comprising a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations; read intervals; or timeouts; the collecting the data from the industrial devices in accordance with the protocol configuration. In the same field of endeavor, Lawson teaches the configuration information comprising a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations; read intervals; or timeouts; the collecting the data from the industrial devices in accordance with the protocol configuration ([0049, 0050, 0060, 0088], it is known for a cloud platform to update a gateway e.g., by updating a configuration file; the configuration file, for example, can define a data collection interval i.e., a read interval, or an inactivity timeout duration; the gateway collects data from sensors in accordance with the configuration file). 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 comprising a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations; read intervals; or timeouts; the collecting the data from the industrial devices in accordance with the protocol configuration as suggested in Lawson into Mukkamala and Nair because Mukkamala/Nair and Lawson pertain to analogous fields of technology. Mukkamala/Nair pertains to a cloud platform that sends configuration data to a gateway upon it being discovered, where the gateway is configured to collect data from industrial devices/sensors and upload the data to the platform. Lawson also pertains to a cloud platform that collects data from industrial devices/sensors via a gateway, where the cloud platform configures the gateway. In Lawson, the cloud platform can configure a configuration file for the gateway, which can control how data is collected e.g., a data collection interval, a timeout etc. It would be desirable to incorporate this feature into Mukkamala so that the system of Mukkamala could configure the gateway to improve data collection e.g., see Lawson in a variety of known ways e.g., see Lawson [0049, 0050, 0060, 0088]. Regarding claim 16 , the combination of Mukkamala, Nair and Lawson teaches the invention as claimed in independent claim 1. The combination of Mukkamala, Nair and Lawson 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, Nair and Lawson teaches the invention as claimed in claim 12. The the combination of Mukkamala, Nair and Lawson 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.) 07-21-aia AIA Claim s 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Mukkamala, Nair and Lawson, as applied in claim 1, and further in view of Dotchkoff (US 2019/0123967) . Regarding claim 8 , the combination of Mukkamala, Nair and Lawson teaches the invention as claimed in independent claim 1. The combination of Mukkamala, Nair and Lawson 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, Lawson and Dotchkoff teaches the invention as claimed in claim 8. The combination of Mukkamala, Nair, Lawson 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) . 07-21-aia AIA Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Mukkamala, Nair and Lawson, as applied in claim 10,and further in view of LeVine (US 2011/0295575) . Regarding claim 17 , the combination of Mukkamala, Nair and Lawson teaches the invention as claimed in independent claim 1 and claim 10. However, the combination of Mukkamala, Nair and Lawson 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, "using automatically, by the loT device, the configuration information for configuring a data collection logic of the loT device, the data collection logic collecting data from the industrial devices in accordance with the configuration information, wherein the configuration information comprises a protocol configuration including at least one of: a protocol address of datapoints for read, write, or execute operations: read intervals: or timeouts." Independent claims 12, 14 and 15 have been amended in a similar manner. Examiner has therefore rejected claims 1, 12, 14 and 15 under 35 U.S.C. 103 as being unpatentable over Mukkamala, Nair and Lawson. Applicant's remarks are moot in view of the new grounds of rejection. Applicant further alleges that dependent claims 3-5, 7-11, 13 and 16-18 are allowable in view of their dependency on claims 1 and 12. Claims 3-5, 7-11, 13 and 16-18 are rejected as being taught by Mukkamala, Nair, Lawson, Dotchkoff and/or Levine. Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Gray (US 2019/0226898) teaches a cloud platform that can adjust the data collection protocol of sensors e.g., by adjusting the periodic rate of transmission; see Gray [0057-0059] . 07-40 AIA Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL . See MPEP § 706.07(a). 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 date of this final action. 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 Application/Control Number: 17/906,162 Page 2 Art Unit: 2118 Application/Control Number: 17/906,162 Page 3 Art Unit: 2118 Application/Control Number: 17/906,162 Page 4 Art Unit: 2118 Application/Control Number: 17/906,162 Page 5 Art Unit: 2118 Application/Control Number: 17/906,162 Page 6 Art Unit: 2118 Application/Control Number: 17/906,162 Page 7 Art Unit: 2118 Application/Control Number: 17/906,162 Page 8 Art Unit: 2118 Application/Control Number: 17/906,162 Page 9 Art Unit: 2118 Application/Control Number: 17/906,162 Page 10 Art Unit: 2118 Application/Control Number: 17/906,162 Page 11 Art Unit: 2118 Application/Control Number: 17/906,162 Page 12 Art Unit: 2118 Application/Control Number: 17/906,162 Page 13 Art Unit: 2118 Application/Control Number: 17/906,162 Page 14 Art Unit: 2118 Application/Control Number: 17/906,162 Page 15 Art Unit: 2118 Application/Control Number: 17/906,162 Page 16 Art Unit: 2118 Application/Control Number: 17/906,162 Page 17 Art Unit: 2118 Application/Control Number: 17/906,162 Page 18 Art Unit: 2118 Application/Control Number: 17/906,162 Page 19 Art Unit: 2118 Application/Control Number: 17/906,162 Page 20 Art Unit: 2118 Application/Control Number: 17/906,162 Page 21 Art Unit: 2118 Application/Control Number: 17/906,162 Page 22 Art Unit: 2118 Application/Control Number: 17/906,162 Page 23 Art Unit: 2118 Application/Control Number: 17/906,162 Page 24 Art Unit: 2118 Application/Control Number: 17/906,162 Page 25 Art Unit: 2118 Application/Control Number: 17/906,162 Page 26 Art Unit: 2118 Application/Control Number: 17/906,162 Page 27 Art Unit: 2118
Prosecution Insights