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 .
This Office Action is in response to amendments filed on September 2, 2026.
Claims 1-11 are pending.
Claims 1 and 6 have been amended.
Response to Amendment
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 software 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 software 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 software 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 software 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 software 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 software layer), Paragraph 67)
Briant et al. do not disclose:
wherein the foundation software 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 software layer does not include service logic;
However, Stelting et al. disclose:
wherein the foundation software layer does not include service logic; (see Figure 2; business services layer (service logic) is separate from/does not include protocol services (foundation software 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 software 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 software 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 software 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 software 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 software 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 software layer), Paragraph 67)
Briant et al. do not disclose:
wherein the foundation software 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 software layer does not include service logic;
However, Stelting et al. disclose:
wherein the foundation software layer does not include service logic; (see Figure 2; business services layer (service logic) is separate from/does not include protocol services (foundation software 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 software 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, filed September 2, 2026, with respect to the claim objections of claims 1-11 have been fully considered and are persuasive. The claim objections of claims 1-11 have been withdrawn.
Applicant's arguments with respect to the §103 rejection filed September 2, 2026 have been fully considered but they are not persuasive.
In the Remarks, Applicant argues:
Independent Claim 1 recites, among other things, establishing a "foundation software layer" in an OT device, the foundation software layer comprising an OT domain low-code development tool, runtime, a public information model, and an OT domain workflow deployed on the runtime by using the public information model, "wherein the foundation software layer does not include service logic." Independent Claim 1 further recites a domain layer that depends on the foundation software layer and a user case layer that depends on the domain layer. Independent Claim 6 recites corresponding device limitations. Consistent with this claim language, the Specification describes the foundation software layer as "a core of the entire software architecture" and "a lightweight system kernel that only includes a non-service logic part." Specification, Detailed Description, Step 110. The Specification further describes the domain layer as depending on and being managed by the foundation layer, and the user case layer as depending on the domain layer. Specification, Detailed Description, Step 120; Specification, Detailed Description, Step 130. FIG. 3 likewise shows the ordered architecture including foundation layer 21, domain layer 22 depending on foundation layer 21, and user case layer 23 depending on domain layer 22.
Briant does not teach or suggest this claimed OT-domain layer architecture. As characterized in the Office Action, Briant 29 describes a computing device providing a user interface for transaction conditions or workflows for transferring datasets using context or a data model. As further characterized in the Office Action, Briant 42 describes computing device 24 receiving data from one or more control systems and providing structure to the received data according to a data model. The Office Action also relies on Briant 26 for an industrial automation system employing OT and IT systems, and on Briant 67 for transfer of retrieved datasets to data components of a different data model that may be part of a destination component. Those disclosures describe contextualized industrial-data transfer by a computing device or gateway. They do not disclose a foundation software layer in an OT device that excludes service logic, a domain layer depending on that foundation software layer, or a user case layer depending on the domain layer. Instead, the rejection maps the claim's distinct software layers and dependency relationships onto generalized data-context, data-model, and dataset-transfer functions of a computing device. The broadest reasonable interpretation of the claims must give effect to the separately recited foundation software layer, domain layer, user case layer, and their dependency relationships; it cannot treat a single computing-device/data-model workflow in Briant as simultaneously satisfying each distinct layer without identifying corresponding layer structures and ordered dependencies.
Examiner’s Response:
The Examiner respectfully disagrees. Applicant argues that Briant does not disclose “a foundation software layer in an OT device that excludes service logic”. As can be seen in the §103 rejection above, the Applicant has not relied solely on Briant to disclose this limitation. It is through the combination of Briant, Barker and specifically Stelting that disclose this limitation.
Further, Applicant argues that Briant does not disclose “a domain layer depending on that foundation software layer”. However, as can be seen in the §103 rejection above, it is the Examiner’s position that Briant discloses this limitation. Specifically, Briant discloses that a computing device can be connected to one or more multiple control systems that utilizes a data model to provide context to received data from the various control systems. (see Paragraph 42) This can be reasonably interpreted as the “domain layer depending on the foundation software layer” as the control system(s) (domain layer) uses a data model (foundation software layer) to provide context to received data. The claims do not provide further detail in the claims on how the domain layer depends on the foundation software layer that precludes this interpretation.
Further still, Applicant argues that Briant does not disclose “a user case layer depending on the domain layer”. It is the Examiner’s position that Briant discloses this limitation as well. Specifically, Briant discloses that a computing device provides a user interface. The user interface can be reasonably considered the “user case layer”. This user interface allows a user to input transition conditions or transaction conditions such as to control the transition of data between components. (see Paragraph 29) It also enables a user to add a data model or context to datasets such that the retrieved data (domain layer) may continue to be transmitted to other devices with the appropriate context. (see Paragraph 27) This can be reasonably interpreted as the “user case layer depending on the domain layer”. The claims do not provide further detail in the claims on how the user case layer depends on the domain layer that precludes this interpretation.
In the Remarks, Applicant argues:
Stelting does not cure that deficiency. The Office Action relies on Stelting for the limitation that the foundation layer does not include service logic, but Stelting teaches a service-modeling paradigm in which the alleged foundation is itself a service layer. Stelting states that its modeling method groups "the services provided by tiers" into protocol services, business services, and architectural services, and that "the services create layers of services with protocol services being the lowest or foundation layer." Stelting, 0010. Stelting further explains that lower layer 210 "includes the protocol services" provided by the tiers of the system. Stelting, 0030. Thus, the reference's alleged foundation layer is a protocol-services layer in a multi-tier enterprise application model, not the claimed foundation software layer in an OT device that does not include service logic.
Examiner’s Response:
The Examiner respectfully disagrees. Applicant argues that Stelting “alleged foundation layer is itself a service layer”. The current claim language does not preclude that the foundation layer itself cannot be a “service layer” just that it does not include some “service logic”. Stelting discloses that business services layer (service logic) is separate from protocol services (foundation layer) (see Paragraph 10). Thus, the “foundation layer” does not include “service logic”.
In the Remarks, Applicant argues:
Nor does Barker remedy the missing architecture. The Office Action relies on Barker et al., col. 19, 11. 21-30, for comparing real-time operational data with thresholds, transmitting a warning, and stopping or reducing machine operation, and relies on Barker, col. 5, 11. 55-67, for "industrial operation" including manufacturing, assembly, transporting, and production operations having a plurality of machines. Those cited passages concern sensors, a data analyzer, warnings, and machine stop control in an industrial operation; they do not identify a Manufacturing Operation Management system or Manufacturing Execution System of the type separately treated in the Specification as IT devices that supply manufacturing operation data to the data platform. Specification, Detailed Description, FIG. 2 data platform/MOM disclosure; Specification, Detailed Description, IT devices disclosure. More importantly, Barker does not disclose the claimed foundation software layer, does not disclose that the foundation software layer excludes service logic, and does not establish the claimed public-information-model-based relationship among the foundation software layer, domain layer, user case layer, and data platform.
Examiner’s Response:
The Examiner respectfully disagrees. Applicant argues that Barker does not “identify a Manufacturing Operation Management system or Manufacturing Execution System of the type separately treated in the Specification as IT devices that supply manufacturing operation data to the data platform”. However, the current claim language does not include these limitations. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., identify a Manufacturing Operation Management system or Manufacturing Execution System of the type separately treated in the Specification as IT devices that supply manufacturing operation data to the data platform) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Further, Applicant argues that Barker “does not disclose that the foundation software layer excludes service logic, and does not establish the claimed public-information-model-based relationship among the foundation software layer, domain layer, user case layer, and data platform”. However, as can be seen in the §103 rejection above, Barker was not used to disclose these limitations.
In the Remarks, Applicant argues:
The Office Action's proposed combination also lacks the required articulated reasoning with rational underpinning. See MPEP § 2141, subsection III; KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007); In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006). The Office Action states that Stelting would have been incorporated to improve system design and development in complex, multi-tiered, object-oriented service environments, citing Stelting 9. But Stelting is directed to multi-tier, object-oriented service environments, whereas Independent Claim 1 and Independent Claim 6 require an OT-device foundation software layer that excludes service logic and supports a dependent OT domain layer and dependent user case layer. The rejection does not explain why a person of ordinary skill would have modified Briant's industrial data-context gateway and Barker's monitoring system with Stelting's enterprise service-layer taxonomy to arrive at the specifically claimed non-service-logic OT-domain software architecture.
Examiner’s Response:
The Examiner respectfully disagrees. In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, Stelting explicitly states why excluding “service logic” from a “foundation layer” would be obvious to one of ordinary skill. By having the separate layers/services, this would improve system design and development of complex, multi-tiered, object-oriented service environments such as the one found in the combination of Briant and Barker.
In the Remarks, Applicant argues:
Claims 3 and 8 are separately rejected over Briant, Barker, Stelting, Duggal, and Mackiewicz. The additional references do not cure the deficiencies of the base combination. The Office Action relies on Duggal 537 for a graph knowledge base that provides domain semantics and metadata for declarative composition of event-driven, data-centric, distributed applications. But Duggal is directed to a graph knowledge base for modeling and processing stateful cloud- native applications and describes a serverless platform for composing services, microservices, and serverless functions into stateful cloud-native applications. Duggal, Technical Field; Duggal, Detailed Description, serverless platform disclosure. Mackiewicz is cited for IEC61850 as a specific domain protocol corresponding to a resource. Office Action, Claim Rejections - 35 U.S.C. § 103, citing Mackiewicz, p. 8, section B, paragraph 3. Even accepting those teachings for purposes of argument, they do not disclose or suggest the missing non-service-logic foundation software layer or the ordered OT-device foundation/domain/user-case dependency architecture required by the independent claims. Claims 3 and 8 are therefore patentable for at least the same reasons as Independent Claim 1 and Independent Claim 6.
Examiner’s Response:
The Examiner respectfully disagrees. Applicant argues that Duggal and Mackiewicz “do not disclose or suggest the missing non-service-logic foundation software layer or the ordered OT-device foundation/domain/user-case dependency architecture required by the independent claims.” However, as can be seen in the §103 rejection above, Duggal and Mackiewicz were not used to disclose these limitations.
In the Remarks, Applicant argues:
Claims 4 and 9-10 are separately rejected over Briant, Barker, Stelting, and Chatterji. The Office Action relies on Chatterji 35 for knowledge graphs that define entities, semantic types, properties, and relationships between entities. Chatterji describes an IoT platform framework including an IoT layer 205, enterprise integration layer 210, data pipeline layer 215, data insight layer 220, application services layer 225, applications layer 230, core services layer 235, and an extensible object model 250 comprising knowledge graphs 251. Chatterji, FIG. 2. Those teachings do not provide the claimed foundation software layer that excludes service logic, and they do not supply the claimed dependency chain in which a domain layer depends on the foundation software layer and a user case layer depends on the domain layer. Claims 4 and 9-10 are therefore patentable for at least the same reasons as Independent Claim 1 and Independent Claim 6.
Examiner’s Response:
The Examiner respectfully disagrees. Applicant argues that Chatterji does “not provide the claimed foundation software layer that excludes service logic, and they do not supply the claimed dependency chain in which a domain layer depends on the foundation software layer and a user case layer depends on the domain layer.” However, as can be seen in the §103 rejection above, Chatterji was not used to disclose these limitations.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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