DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Request for Continued Examination filed on May 8, 2026.
Claims 1-11 are pending.
Claims 1-10 have been amended.
Response to Amendment
Claim Objections
Claims 1-11 are objected to because of the following informalities:
Claims 1 and 6 recite “a foundation software layer” in line 3 and 2 respectively. In the interest of consistency, it is recommended that every instance of “the foundation layer” in claims 1 and 6 be changed to “the foundation software layer”.
Claims 2-5 and 7-11 depend on the rejected claims and do not resolve the deficiencies and thus, are rejected for at least the same reasons.
Appropriate correction is required.
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-2, 5-7 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Briant et al. (US 2021/0149376) in view of Barker et al. (US 11,016,468) and in further view of Stelting et al. (US 2003/0182461).
With respect to Claim 1, Briant et al. disclose:
establishing a foundation software layer in an Operational Technology (OT) device, the foundation layer comprising an OT domain low-code development tool, (computing device (OT device) provides a user interface (OT domain low-code development tool), Paragraph 29; in an industrial automation system that employs operational technology (OT) systems and information technology (IT) systems, a computing device (OT device) may collect and preserve the context of the data acquired from various devices, Paragraph 26) runtime, (see Figure 1; computing device connected to one or multiple control systems, Paragraph 42) and a public information model, (data model(s) can be defined by user(s) and not restricted (public), Paragraph 29) and an OT domain workflow generated by the OT domain low-code development tool deployed on the runtime by using the public information model; (the computing device may provide a user interface (OT domain low-code development tool deployed on the runtime) to define a workflow (OT domain workflow) for transferring datasets using the context and/or data model associated with one or more datasets (public information model), Paragraph 29; the computing device 24 may present the available data destination components 118 in which the data, data model 108, or both may be sent, (deployed on the runtime) in response to the applications tab 198 is selected. For example, FIG. 11 may include a visualization 240 that may depict the application tab 198 of the configuration tab 192. The application tab 198 may include multiple data destination components 118. The application tab 198 may enable the user to select one or multiple data destination components 118. The data destination components 118 may include a local data center 110, the cloud-based data center 112, and various other applications or programs that may be used to store, organize, or analyze the data. (deploy on the runtime) The user may associate the new data model 108 or specific components of the new data model 108 to one or multiple data destination components, Paragraph 89)
establishing a domain layer that depends on the foundation layer, (see Figure 1; example industrial automation system that consists of a computing device connected to one or multiple control systems (domain layer) that utilizes the data model to provide context to received data from various control systems (depends on the foundation layer), Paragraph 42) the domain layer comprising a field bus, (control system (domain layer) may be coupled to one or more sensors which may monitor various aspects of the machine components or conveyor sections of a packaging factory (field bus), Paragraph 55; the industrial automation components may include programming terminals, automation controllers, input/output (I/O) modules, communication networks, human-machine interface (HMI) terminals, and the like, to receive statuses and/or information in the form of data (field bus), Paragraph 4) a domain protocol, (transaction data 122 may define the communication protocol (domain protocol) for each component or each type of component (domain layer) that may be associated with the factories, areas, cells, and the like (domain layer), Paragraph 72) and a device tree of an application domain, and the device tree comprising a connection relationship between devices; (The control systems 102, 104, and/or 106 may each identify a relationship (connection relationship/device tree) of the one or more components 20 to a respective cell 18 or area 16 (application domain) based on the data model 108. Subsequently, the control systems 102, 104, and/or 106 may provide the identified relationships to the computing device, Paragraph 63; the scopes of the packaging factory 50 may be categorized based on functions of the components 20 and/or the cells 18 of the packaging factory 50. For instance, referring to FIG. 3, the loading station 52 may be categorized as cell 1, the washing station 56 may be categorized as cell 2, the sealing station 60 may be categorized as cell 3, the sterilization station 64 may be categorized as cell 4, the labeling station may be categorized as cell 5, and the packaging station 68 may be categorized as cell 6 (devices), Paragraph 59)
and establishing a user case layer depending on the domain layer, (computing device provides a user interface (user case layer) that allows a user to input transition conditions or transaction conditions such as to control the transition of data between a data generating component of the industrial automation system and a data destination component (depending on the domain layer), Paragraph 29; the computing device may provide a user interface (user case layer) that enables a user to provide the context or information model associated with a particular dataset. In this way, the user may add a data model or context to datasets, such that the retrieved data may continue to be transmitted to other devices with the appropriate context (depending on the domain layer), Paragraph 27) the user case layer comprising user-defined function modules, (the user interface allows a user to define a workflow that includes transaction conditions and conditional transactions between components (user-defined function modules), Paragraph 29) and the user-defined function modules capable of conversion into the field bus, the domain protocol, and the device tree in the domain layer; (for example, a transaction condition (user-defined function module) that defines a triggering event (e.g., when data value exceeds 300) for data retrieved from a first data source (e.g., a temperature sensor) to initiate capturing data from a second data source (e.g., pressure sensor) (relationship/device tree in the domain layer). In addition, the transaction conditions may define how data will be collected from a data source. That is, the transaction conditions may detail that data is accessed from a data source using a particular driver and collection path, Paragraph 29; the transaction condition (user-defined function module) is “converted” when one or more multiple conditions are satisfied and certain actions (e.g. data transfer, control equipment) using the specified communication protocol (field bus) (FactoryTalk Live Data, EtherNet/IP, OPC Direct Access or any suitable communication protocol) (domain protocol) with respect to the retrieved data or other components in the industrial automation system (device tree in the domain layer), Paragraphs 72 and 86)
obtaining data from a data platform, (receiving raw data associated with a selected control system (data platform), Paragraph 77; providing a different data model by a third party provider in a local data center or a cloud-based data center, Paragraph 67) the data platform spanning over the domain layer and the user case layer (see Figure 1; control system(s) (data platform) are interfaced/communicating with a computing system (domain layer) to transmit raw data which is utilized by a user to define a data model using a user interface (user case layer) of a computing system, Paragraphs 66-70) as well as communicating with third-party software through a third-party interface; (the user may define a transaction to retrieve datasets from data components of a data model associated with a data source, and transferring the retrieved datasets (data communication) to data components of a different data model that may be part of the data destination component. (third-party software/third-party interface) The different data model may be data model provided by a third party provider in the local data center 110 or the cloud-based data center 112 to facilitate the transfer (third-party software/third-party interface, Paragraph 67)
transmitting the obtained data between the user case layer and the domain layer (using the data model (public information model) to define transaction conditions that detail a custom workflow for data communication through an industrial automation system, Paragraph 29; the data model may provide structure to the received raw data 114, such that the received raw data 114 may be provided (transferred) to the user in the form of structured data 116. (transferring data between the user case layer and the domain layer) The structured data 116 may include datasets and/or one or more hierarchal representations of the datasets., Paragraph 67) and between the domain layer and the foundation layer, using the public information model; (The data model 108 (public information model) may also be incorporated into a workflow that may include transaction conditions and conditional transactions between components of the data model 108 while providing the structured data 116 with the transferred datasets. In some embodiments, the user may define such transactions by determining one or more aspects of the datasets based on the data model 108 via the computing device 24. In different embodiments, the user may define the transactions by specifying how the datasets are to be retrieved and transferred based on one or more relationships between the datasets of the data model 108. (transferring data between domain layer and the foundation layer) For example, the user may define a transaction to retrieve datasets from data components of a data model associated with a data source, and transferring the retrieved datasets to data components of a different data model that may be part of the data destination component. The different data model may be data model provided by a third party provider in the local data center 110 or the cloud-based data center 112 to facilitate the transfer. (transferring data between domain layer and the foundation layer), Paragraph 67)
Briant et al. do not disclose:
wherein the foundation layer does not include service logic;
using the transmitted data to control OT domain processes with a manufacturing operation management system.
However, Barker et al. disclose:
using the transmitted data to control OT domain processes with a manufacturing operation management system. (collecting real-time operational data (transmitted data) to compare with operational baseline and reference thresholds in order to warn a user that operating parameters exceed reference thresholds and then the user can transmit operating commands to shut off or reduce the operation of independent machine(s) (OT domain processes with a manufacturing operation management system), Column 19, lines 21-30; machine or machines can also include a series of machines operating together, such as in a production, manufacturing or assembly working together or working independently at a location. Further, a machine or machines may include moving and non-moving components, rotating components, reciprocating components and/or electrical components working together or independently. As used herein the term “industrial operation” includes manufacturing operations, assembly operations, transporting operations, and production operations having a plurality of machines, such as an assembly line, a production line, a transportation line (conveyor line), a manufacturing line, a packaging line, and the like (manufacturing operation management system), Column 5, lines 55-67)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Barker et al. into the teaching of Briant et al. to include using the transmitted data to control OT domain processes with a manufacturing operation management system in order to help monitor an industrial operation that consists of a plurality of different apparatus and machines and utilizing different types of information and data to optimize maintenance scheduling to minimize disruptions of the industrial operation. (Barker et al., Column 2, lines 18-23)
Briant et al. and Barker et al. do not disclose:
wherein the foundation layer does not include service logic;
However, Stelting et al. disclose:
wherein the foundation layer does not include service logic; (see Figure 2; business services layer (service logic) is separate from/does not include protocol services (foundation layer), Paragraph 10)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Stelting et al. into the teaching of Briant et al. and Barker et al. to include wherein the foundation layer does not include service logic in order to help improve system design and development in complex, multi-tiered, object-oriented service environments. (Stelting et al., Paragraph 9)
With respect to Claim 2, all the limitations of Claim 1 have been addressed above; and Briant et al. further disclose:
further comprising:
performing data communication with third-party software through the third-party interface. (the user may define a transaction to retrieve datasets from data components of a data model associated with a data source, and transferring the retrieved datasets (data communication) to data components of a different data model that may be part of the data destination component. (third-party interface) The different data model may be data model provided by a third party provider in the local data center 110 or the cloud-based data center 112 to facilitate the transfer., Paragraph 67)
With respect to Claim 5, all the limitations of Claim 1 have been addressed above; and Briant et al. further disclose:
wherein the data platform obtains data from the manufacturing operation management system. (transmitting raw data from the control systems and/or to the computing system, Paragraph 70; control systems can include various machine components in a packaging factory (manufacturing operation management system), Paragraphs 56-57)
With respect to Claim 6, Briant et al. disclose:
establishing a foundation software layer in an Operational Technology (OT) device including an OT domain low-code development tool, (computing device provides a user interface (OT domain low-code development tool), Paragraph 29; in an industrial automation system that employs operational technology (OT) systems and information technology (IT) systems, a computing device (OT device) may collect and preserve the context of the data acquired from various devices, Paragraph 26) runtime, (see Figure 1; computing device connected to one or multiple control systems, Paragraph 42) and a public information model, (data model(s) can be defined by user(s) and not restricted (public), Paragraph 29) and an OT domain workflow generated by the OT domain low-code development tool deployed on the runtime by using the public information model; (the computing device may provide a user interface (OT domain low-code development tool deployed on the runtime) to define a workflow (OT domain workflow) for transferring datasets using the context and/or data model associated with one or more datasets (public information model), Paragraph 29; the computing device 24 may present the available data destination components 118 in which the data, data model 108, or both may be sent, (deployed on the runtime) in response to the applications tab 198 is selected. For example, FIG. 11 may include a visualization 240 that may depict the application tab 198 of the configuration tab 192. The application tab 198 may include multiple data destination components 118. The application tab 198 may enable the user to select one or multiple data destination components 118. The data destination components 118 may include a local data center 110, the cloud-based data center 112, and various other applications or programs that may be used to store, organize, or analyze the data. (deploy on the runtime) The user may associate the new data model 108 or specific components of the new data model 108 to one or multiple data destination components, Paragraph 89)
establishing a domain layer that depends on the foundation layer, (see Figure 1; example industrial automation system that consists of a computing device connected to one or multiple control systems (domain layer) that utilizes the data model to provide context to received data from various control systems (depends on the foundation layer), Paragraph 42) the domain layer comprising a field bus, (control system (domain layer) may be coupled to one or more sensors which may monitor various aspects of the machine components or conveyor sections of a packaging factory (field bus), Paragraph 55; the industrial automation components may include programming terminals, automation controllers, input/output (I/O) modules, communication networks, human-machine interface (HMI) terminals, and the like, to receive statuses and/or information in the form of data (field bus), Paragraph 4) a domain protocol, (transaction data 122 may define the communication protocol (domain protocol) for each component or each type of component (domain layer) that may be associated with the factories, areas, cells, and the like (domain layer), Paragraph 72) and a device tree of an application domain, and the device tree comprising a connection relationship between devices; (The control systems 102, 104, and/or 106 may each identify a relationship (connection relationship/device tree) of the one or more components 20 to a respective cell 18 or area 16 (application domain) based on the data model 108. Subsequently, the control systems 102, 104, and/or 106 may provide the identified relationships to the computing device, Paragraph 63; the scopes of the packaging factory 50 may be categorized based on functions of the components 20 and/or the cells 18 of the packaging factory 50. For instance, referring to FIG. 3, the loading station 52 may be categorized as cell 1, the washing station 56 may be categorized as cell 2, the sealing station 60 may be categorized as cell 3, the sterilization station 64 may be categorized as cell 4, the labeling station may be categorized as cell 5, and the packaging station 68 may be categorized as cell 6 (devices), Paragraph 59)
and establishing a user case layer depending on the domain layer, (computing device provides a user interface (user case layer) that allows a user to input transition conditions or transaction conditions such as to control the transition of data between a data generating component of the industrial automation system and a data destination component (depending on the domain layer), Paragraph 29; the computing device may provide a user interface (user case layer) that enables a user to provide the context or information model associated with a particular dataset. In this way, the user may add a data model or context to datasets, such that the retrieved data may continue to be transmitted to other devices with the appropriate context (depending on the domain layer), Paragraph 27) the user case layer comprising user-defined function modules, (the user interface allows a user to define a workflow that includes transaction conditions and conditional transactions between components (user-defined function modules), Paragraph 29) and the user-defined function modules capable of conversion into the field bus, the domain protocol, and the device tree in the domain layer; (for example, a transaction condition (user-defined function module) that defines a triggering event (e.g., when data value exceeds 300) for data retrieved from a first data source (e.g., a temperature sensor) to initiate capturing data from a second data source (e.g., pressure sensor) (relationship/device tree in the domain layer). In addition, the transaction conditions may define how data will be collected from a data source. That is, the transaction conditions may detail that data is accessed from a data source using a particular driver and collection path, Paragraph 29; the transaction condition (user-defined function module) is “converted” when one or more multiple conditions are satisfied and certain actions (e.g. data transfer, control equipment) using the specified communication protocol (field bus) (FactoryTalk Live Data, EtherNet/IP, OPC Direct Access or any suitable communication protocol) (domain protocol) with respect to the retrieved data or other components in the industrial automation system (device tree in the domain layer), Paragraphs 72 and 86)
a first communication connection between the user case layer and the domain layer transmitting data obtained from a data platform, (receiving raw data associated with a selected control system (data platform), Paragraph 77; the data model may provide structure to the received raw data 114, such that the received raw data 114 may be provided (transmitted) to the user in the form of structured data 116. (transmitting data between the user case layer and the domain layer) The structured data 116 may include datasets and/or one or more hierarchal representations of the datasets., Paragraph 67; providing a different data model by a third party provider in a local data center or a cloud-based data center, Paragraph 67)) the data platform spanning over the domain layer and the user case layer (see Figure 1; control system(s) (data platform) are interfaced/communicating with a computing system (domain layer) to transmit raw data which is utilized by a user to define a data model using a user interface (user case layer) of a computing system, Paragraphs 66-70) as well as communicating with third-party software through a third-party interface; (the user may define a transaction to retrieve datasets from data components of a data model associated with a data source, and transferring the retrieved datasets (data communication) to data components of a different data model that may be part of the data destination component. (third-party software/third-party interface) The different data model may be data model provided by a third party provider in the local data center 110 or the cloud-based data center 112 to facilitate the transfer (third-party software/third-party interface, Paragraph 67)as well as communicating with third-party software through a third-party interface; (the user may define a transaction to retrieve datasets from data components of a data model associated with a data source, and transferring the retrieved datasets (data communication) to data components of a different data model that may be part of the data destination component. (third-party software/third-party interface) The different data model may be data model provided by a third party provider in the local data center 110 or the cloud-based data center 112 to facilitate the transfer (third-party software/third-party interface, Paragraph 67)
a second communication connection between the domain layer and the foundation layer transmitting data received from the domain layer; (The data model 108 (public information model) may also be incorporated into a workflow that may include transaction conditions and conditional transactions between components of the data model 108 while providing the structured data 116 with the transferred datasets. In some embodiments, the user may define such transactions by determining one or more aspects of the datasets based on the data model 108 via the computing device 24. In different embodiments, the user may define the transactions by specifying how the datasets are to be retrieved and transferred based on one or more relationships between the datasets of the data model 108. (transmitting data between domain layer and the foundation layer) For example, the user may define a transaction to retrieve datasets from data components of a data model associated with a data source, and transferring the retrieved datasets to data components of a different data model that may be part of the data destination component. The different data model may be data model provided by a third party provider in the local data center 110 or the cloud-based data center 112 to facilitate the transfer. (transmitting data between domain layer and the foundation layer), Paragraph 67)
Briant et al. do not disclose:
wherein the foundation layer does not include service logic;
a manufacturing operation management system using the transmitted data to control OT domain processes.
However, Barker et al. disclose:
a manufacturing operation management system using the transmitted data to control OT domain processes. (collecting real-time operational data (transmitted data) to compare with operational baseline and reference thresholds in order to warn a user that operating parameters exceed reference thresholds and then the user can transmit operating commands to shut off or reduce the operation of independent machine(s) (OT domain processes with a manufacturing operation management system), Column 19, lines 21-30; machine or machines can also include a series of machines operating together, such as in a production, manufacturing or assembly working together or working independently at a location. Further, a machine or machines may include moving and non-moving components, rotating components, reciprocating components and/or electrical components working together or independently. As used herein the term “industrial operation” includes manufacturing operations, assembly operations, transporting operations, and production operations having a plurality of machines, such as an assembly line, a production line, a transportation line (conveyor line), a manufacturing line, a packaging line, and the like (manufacturing operation management system), Column 5, lines 55-67)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Barker et al. into the teaching of Briant et al. to include a manufacturing operation management system using the transmitted data to control OT domain processes in order to help monitor an industrial operation that consists of a plurality of different apparatus and machines and utilizing different types of information and data to optimize maintenance scheduling to minimize disruptions of the industrial operation. (Barker et al., Column 2, lines 18-23)
Briant et al. and Barker et al. do not disclose:
wherein the foundation layer does not include service logic;
However, Stelting et al. disclose:
wherein the foundation layer does not include service logic; (see Figure 2; business services layer (service logic) is separate from/does not include protocol services (foundation layer), Paragraph 10)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Stelting et al. into the teaching of Briant et al. and Barker et al. to include wherein the foundation layer does not include service logic in order to help improve system design and development in complex, multi-tiered, object-oriented service environments. (Stelting et al., Paragraph 9)
With respect to Claim 7, all the limitations of Claim 6 have been addressed above; and Briant et al. further disclose:
wherein:
the user case layer further comprises a third-party interface; (the application tab 198 (user case layer) may include multiple data destination components 118. The application tab 198 may enable the user to select one or multiple data destination components 118. The data destination components 118 may include a local data center 110, (third-party interface) the cloud-based data center 112, and various other applications or programs that may be used to store, organize, or analyze the data. The user may associate the new data model 108 or specific components of the new data model 108 to one or multiple data destination components, Paragraph 90; third party provider in a local data center, Paragraph 67)
and data communication with third-party software is performed through the third-party interface. (the user may define a transaction to retrieve datasets from data components of a data model associated with a data source, and transferring the retrieved datasets (data communication) to data components of a different data model that may be part of the data destination component. (third-party interface) The different data model may be data model provided by a third party provider in the local data center 110 or the cloud-based data center 112 to facilitate the transfer., Paragraph 67)
Claim 11 is an electronic device claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 1.
Claims 3 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Briant et al. (US 2021/0149376) in view of Barker et al. (US 11,016,468) in view of Stelting et al. (US 2003/0182461) in view of Duggal et al. (US 2021/0360083) and in further view of R.E. Mackiewicz (“Overview of IEC61850 and Benefits”, 2006).
With respect to Claim 3, all the limitations of Claim 1 have been addressed above; and Briant et al., Barker et al. and Stelting et al. further disclose:
wherein:
the domain layer comprises a meta function block and a domain function block; (Briant et al., see Figure 1; example industrial automation system that consists of a computing device connected to one or multiple control systems (domain function block) that utilizes the data model (meta function block) to provide context to received data from various control systems, Paragraph 42)
the meta function block comprises a system node, (Briant et al., computing device (system node) that collects and preserves the context of the data acquired from various devices, Paragraph 26) a data block, (Briant et al., raw data 114 may be unstructured and may include all the data provided by the control systems 102, 104, and 106, Paragraph 70), a behavior tree logic (Briant et al., a transaction condition defining a triggering event (e.g., when data value exceeds 300) for data retrieved from a first data source (e.g., a temperature sensor) to initiate capturing data from a second data source (e.g., pressure sensor) (behavior tree logic). In addition, the transaction conditions may define how data will be collected from a data source (behavior tree logic), Paragraph 29)
and the domain function block comprises a resource (Briant et al., different types of automation components such as jelly bean making area, a packaging area, a water filtration area and the like (resource), Paragraph 31; packaging factory may include machine components (resource) configured to conduct a particular function with respect to the beverage packaging process. For example, the beverage packaging process begins at a loading station 52, where pallets of empty cans or bottles to be filled are fed into packaging factory 50 via a conveyor section 54. The conveyor section 54 transports the empty cans from the loading station 52 to a washing station 56, where the empty cans and bottles are washed and prepared for filling. As the washed cans and bottles exit the washing station 56, the conveyor section 54 may gradually transition into an aligning conveyor section 58, such that the washed cans and bottles enter a filling and sealing station 60 in a single-file line, Paragraph 52) and a logic node, (Briant et al., control system may be a controller, such as a programmable logic controller (PLC) a programmable automation controller (PAC) or any other controller that may monitor, control and operate an industrial automation component (logic node), Paragraph 37) a Standard domain protocol, (Briant et al., a user may select a driver that represents the manner (e.g., format) in which the requested datasets are to be retrieved from a data source. By way of example, the driver may be defined as FactoryTalk Live Data, EtherNet/IP (Common Industrial Protocol (CIP)), OPC Direct Access (e.g., machine to machine communication protocol for industrial automation developed by the OPC Foundation), or any suitable communication protocol, (standard domain protocol) Paragraph 72)
Briant et al., Barker et al. and Stelting et al. do not disclose:
the meta function block comprises a language database;
and the domain function block comprises a specific domain protocol that correspond to the resource.
However, Duggal et al. disclose:
the meta function block comprises a language database; (Graph Knowledge base (language database) supports an umbrella abstraction that enables the modeling of complex business and infrastructure domains. The Graph Knowledge base provides the domain semantics and metadata (language database)for declarative composition of event-driven, data-centric, distributed applications and end-to-end automated dataflow processes., Paragraph 537)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Duggal et al. into the teaching of Briant et al., Barker et al. and Stelting et al. to include the meta function block comprises a language database in order to enable the modeling of complex business and infrastructure domains. (Duggal et al., Paragraph 537)
Briant et al., Barker et al., Stelting et al. and Duggal et al. do not disclose:
and the domain function block comprises a specific domain protocol that correspond to the resource.
However, R.E. Mackiewicz discloses:
and the domain function block comprises a specific domain protocol that correspond to the resource. (using IEC61850 (a specific domain protocol) to exchange data between devices (resource), Page 8, B. Major Benefits, Paragraph 3)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of R.E. Mackiewicz into the teaching of Briant et al., Barker et al., Stelting et al. and Duggal et al. to include the domain function block comprises a specific domain protocol that correspond to the resource in order to take advantage of the benefits of using the IEC61850 Standard such as lowering costs related to installation, transducer, commissioning, equipment migration and extension. (R.E. Mackiewicz, Pages 7-8, B. Major Benefits)
Claim 8 is a device claim corresponding to the method claim above (Claim 3) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 3.
Claims 4 and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Briant et al. (US 2021/0149376) in view of Barker et al. (US 11,016,468) in view of Stelting et al. (US 2003/0182461) and in further view of Chatterji et al. (US 2022/0121965).
With respect to Claim 4, all the limitations of Claim 1 have been addressed above; and Briant et al., Barker et al. and Stelting et al. do not disclose:
the data platform obtains semantic knowledge from a knowledge graph.
However, Chatterji et al. disclose:
the data platform obtains semantic knowledge from a knowledge graph. (communicating knowledge graphs which define large network entities, semantic types of the entities, properties of the entities and relationships between the entities, Paragraph 35)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Chatterji et al. into the teaching of Briant et al., Barker et al. and Stelting et al. to include the data platform obtains semantic knowledge from a knowledge graph in order to learn about real-world entities and their interrelations organized in a graphical interface as well as possible classes and relationships of entities in a schema. (Chatterii et al., Paragraph 35)
Claim 9 is a device claim corresponding to the method claim above (Claim 4) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 4.
With respect to Claim 10, all the limitations of Claim 9 have been addressed above; and Briant et al. further disclose:
wherein the data platform obtains data from the manufacturing operation management system or a manufacturing execution system. (transmitting raw data from the control systems and/or to the computing system, Paragraph 70; control systems can include various machine components in a packaging factory (manufacturing operation management system or a manufacturing execution system), Paragraphs 56-57)
Response to Arguments
Applicant’s arguments, see Page6-9, filed April 10, 2026, with respect to the §101 rejection of claims 1-11 and the claim objections of claims 2-5 and 7-10 have been fully considered and are persuasive. The §101 rejection of claims 1-11 and the claim objections of claims 2-5 and 7-10 have been withdrawn.
Applicant's arguments with respect to the §103 rejection filed April 10, 20206 have been fully considered but they are not persuasive.
In the Remarks, Applicant argues:
Applicant respectfully traverses the rejection of claim 1 under 35 U.S.C. § 103 over Briant in view of Barker. As amended, claim 1 now requires both (i) establishing the foundation software layer in an OT device and (ii) that the foundation layer does not include service logic. Neither Briant nor Barker (alone or in combination) teaches or suggests these requirements.
Examiner’s Response:
The Examiner respectfully disagrees. As can be seen in the updated §103 rejection above, it is the Examiner’s position that Briant discloses “establishing the foundation software layer in an OT device”. Specifically, Briant discloses that in an industrial automation system that employs operational technology (OT) systems and information technology (IT) systems, a computing device may collect and preserve the context of the data acquired from various devices such that the computing device may transmit the acquired data along with the context of the data. (see Paragraphs 25-26 and Abstract) The computing device can be reasonably interpreted as the Applicant’s “OT device” and the collect/preserving of the context of the data using a user interface can be reasonably considered “establishing the foundation software layer” in an OT device.
Further, Applicant argues that neither Briant nor Barker disclose “that the foundation layer does not include service logic”. This argument has been considered but is moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In the Remarks, Applicant argues:
Briant's cited disclosures concern a computing device, user interface, data model, transaction conditions, and data transfer among industrial components. That is not the claimed architecture. In Applicant's disclosure, the foundation layer is a distinct architectural core established on the OT device and limited to a non-service-logic kernel, while higher-level domain and user-case functionality is separated into different layers. See Specification, Step 110, FIG. 2, FIG. 3. The specification expressly states that the foundation layer "only includes a non-service logic part" and further explains that an OT engineer establishes the workflow on the OT device. See Specification, summary of the architecture; Step 110 / FIG. 2. Briant does not disclose that separation, and nothing in Briant's workflow and transaction-condition disclosures suggests excluding service logic from the foundational layer. To the contrary, Briant places application- level workflow/transaction behavior directly in its computing-device implementation. See Briant 29.
Nor does Barker cure the defect. Barker is relied on only for process control using transmitted data, not for the newly claimed layered architecture or the non-service-logic foundation layer. Accordingly, even if Barker were combined with Briant as proposed (and Applicant does not concede this combination is proper), the combination still would not teach or suggest amended claim 1 as a whole. The rejection should therefore be withdrawn.
Examiner’s Response:
Applicant’s arguments above have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LANNY N UNG whose telephone number is (571)270-7708. The examiner can normally be reached Mon-Thurs 6am-4pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at 571-272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/LANNY N UNG/Primary Examiner, Art Unit 2197
Prosecution Insights