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 .
Claims 1-18 are pending.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55 for Application No. EP21177460.9 filed on 06/02/2021.
Information Disclosure Statement
The references cited in the information disclosure statements (IDS) submitted on 12/04/2023 have been considered by the examiner.
Claim Objections
The following claims are objected to for informalities, lack of antecedent support, or for redundancies. The Examiner recommends the following changes:
Claim 4, line 2, replace “4the” with “the”
Appropriate correction is respectfully requested.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 12 is rejected under 35 U.S.C. 112(d) as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends. Claim 12 recites the limitation that is a duplicate of the limitation of claim 3 which it depends on. Applicant may cancel the claim, amend the claim to place the claim in proper dependent form or present a sufficient showing that the dependent claim complies with the statutory requirements.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 4-8 and 18 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Anicic et al. (US 2022/0058502 A1) (“Anicic”).
Regarding independent claim 1, Anicic teaches:
A method performed by an OPC UA client, the method comprising: importing a nodeset file pertaining to an OPC UA-enabled automation device, the nodeset file defining validation logic used to validate data to be written to the automation device; preparing data to be written to the automation device; and using the validation logic to validate the prepared data. (Anicic: [0008] “In one embodiment, a gateway for transforming a description of an industrial process equipment into a semantically enriched and graph-based data information model for automation purposes is disclosed. The gateway includes a parsing module for parsing information entities in the description of the industrial process equipment by a field communication protocol and for transforming the parsed information entities into declarative logic facts and asserting the declarative logic facts within a deductive database. The gateway further includes a knowledge engine using a mapping knowledge base for applying mapping rules to the declarative logic facts, whereby the declarative logic facts are deductively mapped onto the graph-based data information model. Eventually, the gateway includes an interface module for accessing the graph-based data object model.”) (Anicic: [0024] “OPC UA offers direct data access, regardless of the level of the automation pyramid. OPC UA further provides an information model and transport layer communications, where clients at any level of the pyramid may directly access data served by one or more OPC UA servers, hosted at any level. This includes OPC UA servers hosted at the field device level. OPC UA imposes a prerequisite in that information of heterogeneous automation devices and systems is to be represented with the OPC UA Information Model (OPC UA IM), which is a semantically enriched and graph-based data information model for automation purposes.”) (Anicic: [0035] “The gateway acts in a plug-and-play fashion (e.g., connects to the field device FD, reads the field device description FDD, and maps field device information such as device parameters to an OPC UA address space). Device parameters and corresponding values may then be accessed by the gateway-internal server SRV using any standard OPC UA client (not shown) or any standard OPC UA server (not shown) connected to the gateway-internal server SRV.”) (Anicic [0083]-[0094] “[0083] EDDL_POST_EDIT_ACTIONS—specifies methods that are to be executed after the variable has been written to the device; [0084] EDDL_POST_READ_ACTIONS—specifies methods that are to be executed after the variable was read from the device; [0085] EDDL_POST_WRITE_ACTIONS—specifies methods that are to be executed after the variable has been written to the device; [0086] EDDL_PRE_EDIT_ACTIONS—specifies methods that are to be executed immediately when the variable is going to be edited; [0087] EDDL_PRE_READ_ACTIONS—specifies methods that are to be executed before the variable is read; [0088] EDDL_PRE_WRITE_ACTIONS—specifies methods that are to be executed before the variable is written to the device; [0089] EDDL_READ_TIMEOUT—specifies the length of time, in ms, the EDD application is to wait for the returned variable; [0090] EDDL_REFRESH_ACTIONS—specifies EDD methods that are to be executed whenever the variable is displayed or refreshed; [0091] EDDL_RESPONSE_CODES—specify values a device may return as error information; [0092] EDDL_STYLE—specifies the way a variable is displayed; [0093] EDDL_VALIDITY—specifies whether an element is valid or invalid; and [0094] EDDL_WRITE_TIMEOUT—specifies the length of time, in ms, an EDD application is to wait for confirmation that the variable is successfully written to the device.”) (Anicic: [0204] “FIG. 8 shows a flowchart for querying and extracting OPC UA information from the Datalog Engine in order to recursively instantiate all references pointing from a source node.”) (Anicic: [0217] “The embodiments allow for a discovery of the mapping knowledge or a part thereof. A user or an application may, for example, query the storage of mapping knowledge via expressive semantic queries.”) (Anicic: [0220] “The embodiments allow for a validation of field device data against the mapping knowledge. For example, it may be checked whether field device data is in conformance to a specification.”) [The gateway or the field device reads on “automation device”, and the gateway or the field device being accessible by the OPC UA client or server reads on “an OPC UA-enabled automation device”. Querying/retrieving the mapping knowledge for a node reads on “importing a nodeset file …”. Using the mapping knowledge base for applying mapping rules where the declarative logic facts are mapped onto the graph-based data information model reads on “the nodeset file defining validation logic used to validate data …”. Actions that specify methods that are to be executed by the device reads on “preparing data to be written to …”. Checking that the field device data is in conformance to the specification reads on “… to validate the prepared data”.]
Regarding claim 2, Anicic teaches all the claimed features of claim 1. Anicic further teaches:
wherein the data is prepared before an OPC UA server of the automation device has been deployed. (Anicic: [0088] “EDDL_PRE_WRITE_ACTIONS—specifies methods that are to be executed before the variable is written to the device”)
Regarding claim 4, Anicic teaches all the claimed features of claim 1. Anicic further teaches:
wherein the validation logic is stored in the nodeset file in a predetermined XML element, (Anicic: [0212] “The OPC UA information extracted from the Query Engine may be converted into XML nodes within an XML Schema of OPC UA. OPC UA Server Config Generator accomplishes this task, and then passes the information downstream to the OPC UA Server. In this way, every standard OPC UA client may access data that originated as EDD field device descriptions.”)
4the method further comprising identifying the element that contains the validation logic according to an established convention. (Anicic: [0066] “According to an Industry Standard Specification entitled »IEC 62769-109-1:2015—Field Devices Integration (FDI)—Part 109-1: Profiles—HART and WirelessHART …”)
Regarding claim 5, Anicic teaches all the claimed features of claim 1. Anicic further teaches:
wherein the validation logic is stored in the nodeset file using a value attribute of a description of a UAVariable, (Anicic: [0096] “In the following, a mapping of an EDDL variable to a variable in the OPC UA information model is described. A Datalog atomic formula representing an OPC UA variable is specified as: …”)
the method further comprising identifying the UAVariable that contains the validation logic according to an established convention. (Anicic: [0066] “According to an Industry Standard Specification entitled »IEC 62769-109-1:2015—Field Devices Integration (FDI)—Part 109-1: Profiles—HART and WirelessHART …”)
Regarding claim 6, Anicic teaches all the claimed features of claim 1. Anicic further teaches:
wherein validating the data comprises using an information model to identify that a variable to be written is of a type that indicates a validation requirement and (Anicic: [0066]-[0080] “[0066] According to an Industry Standard Specification entitled »IEC 62769-109-1:2015—Field Devices Integration (FDI)—Part 109-1: Profiles—HART and WirelessHART« the description of attributes of an EDDL variable is specified as: [0067] EDDL_ID—UAObject node ID; [0068] EDDL_ID_1—variable node ID; [0069] EDDL_ID_2—variableType node ID; [0070] EDDL_ID_3—OPC_DataType node ID; [0071] EDDL_ID_4—node ID for variable EDDL_CONSTANT_UNIT; [0072] EDDL_ID_5—node ID for variable EDDL_STYLE; [0073] EDDL_ID_6—node ID for variable EDDL_VALIDITY; [0074] EDDL_VariableName—specifies identifier of a variable; [0075] EDDL_CLASS—specifies how the variable is used by the device and the EDD application for organization purposes and display; [0076] EDDL_LABEL—specifies the displayed designation of an element; [0077] EDDL_TYPE—specifies the data type of a variable; [0078] EDDL_CONSTANT_UNIT—is used if a variable has a units code that never changes; [0079] EDDL_DEFAULT_VALUE—specifies the default setting for the variable; [0080] EDDL_HANDLING—specifies the operations that may be performed on an element”)
executing the validation logic in relation to the variable to be written in response to the identifying. (Anicic [0083]-[0094] as discussed in claim 1)
Regarding claim 7, Anicic teaches all the claimed features of claims 1 and 6. Anicic further teaches:
wherein the information model further defines a status variable for carrying the result of the validation, the method further comprising modifying the status variable to indicate the result of executing the validation logic in relation to the variable to be written. (Anicic: [0126] “The following section describes a creation of an OPC UA Variable Node Class: EDDL_VALIDITY. The signature of eddl_Variable has a term called EDDL_VALIDITY. This term from an EDDL variable is to be mapped to an OPC UA Property, which is a type of an OPC UA Variable: opc_ UAVariable( EDDL_ID_6, “EDDL_VALIDITY”, “String”, “-1”, “Not_Used”, “Not_Used”, “Not_Used”, “Not_Used”, “Not_Used”) <= eddl_Variable.”)
Regarding independent claim 8, Anicic teaches:
A method performed by an OPC UA server, the method comprising: importing a nodeset file pertaining to an automation device in which the OPC UA server is embedded, the nodeset file defining validation logic used to validate data to be written to the automation device; receiving data to be written to the automation device; and using the validation logic to validate the received data. (Anicic: [0008] “In one embodiment, a gateway for transforming a description of an industrial process equipment into a semantically enriched and graph-based data information model for automation purposes is disclosed. The gateway includes a parsing module for parsing information entities in the description of the industrial process equipment by a field communication protocol and for transforming the parsed information entities into declarative logic facts and asserting the declarative logic facts within a deductive database. The gateway further includes a knowledge engine using a mapping knowledge base for applying mapping rules to the declarative logic facts, whereby the declarative logic facts are deductively mapped onto the graph-based data information model. Eventually, the gateway includes an interface module for accessing the graph-based data object model.”) (Anicic: [0024] “OPC UA offers direct data access, regardless of the level of the automation pyramid. OPC UA further provides an information model and transport layer communications, where clients at any level of the pyramid may directly access data served by one or more OPC UA servers, hosted at any level. This includes OPC UA servers hosted at the field device level. OPC UA imposes a prerequisite in that information of heterogeneous automation devices and systems is to be represented with the OPC UA Information Model (OPC UA IM), which is a semantically enriched and graph-based data information model for automation purposes.”) (Anicic: [0035] “The gateway acts in a plug-and-play fashion (e.g., connects to the field device FD, reads the field device description FDD, and maps field device information such as device parameters to an OPC UA address space). Device parameters and corresponding values may then be accessed by the gateway-internal server SRV using any standard OPC UA client (not shown) or any standard OPC UA server (not shown) connected to the gateway-internal server SRV.”) (Anicic [0083]-[0094] “[0083] EDDL_POST_EDIT_ACTIONS—specifies methods that are to be executed after the variable has been written to the device; [0084] EDDL_POST_READ_ACTIONS—specifies methods that are to be executed after the variable was read from the device; [0085] EDDL_POST_WRITE_ACTIONS—specifies methods that are to be executed after the variable has been written to the device; [0086] EDDL_PRE_EDIT_ACTIONS—specifies methods that are to be executed immediately when the variable is going to be edited; [0087] EDDL_PRE_READ_ACTIONS—specifies methods that are to be executed before the variable is read; [0088] EDDL_PRE_WRITE_ACTIONS—specifies methods that are to be executed before the variable is written to the device; [0089] EDDL_READ_TIMEOUT—specifies the length of time, in ms, the EDD application is to wait for the returned variable; [0090] EDDL_REFRESH_ACTIONS—specifies EDD methods that are to be executed whenever the variable is displayed or refreshed; [0091] EDDL_RESPONSE_CODES—specify values a device may return as error information; [0092] EDDL_STYLE—specifies the way a variable is displayed; [0093] EDDL_VALIDITY—specifies whether an element is valid or invalid; and [0094] EDDL_WRITE_TIMEOUT—specifies the length of time, in ms, an EDD application is to wait for confirmation that the variable is successfully written to the device.”) (Anicic: [0204] “FIG. 8 shows a flowchart for querying and extracting OPC UA information from the Datalog Engine in order to recursively instantiate all references pointing from a source node.”) (Anicic: [0217] “The embodiments allow for a discovery of the mapping knowledge or a part thereof. A user or an application may, for example, query the storage of mapping knowledge via expressive semantic queries.”) (Anicic: [0220] “The embodiments allow for a validation of field device data against the mapping knowledge. For example, it may be checked whether field device data is in conformance to a specification.”) [The gateway or the field device reads on “automation device”, and the gateway or the field device that hosts the OPC US server reads on “an automation device in which the OPC US server is embedded”. Querying/retrieving the mapping knowledge for a node reads on “importing a nodeset file …”. Using the mapping knowledge base for applying mapping rules where the declarative logic facts are mapped onto the graph-based data information model reads on “the nodeset file defining validation logic used to validate data …”. Actions that specify methods that are to be executed by the device reads on “receiving data to be written to …”. Checking that the field device data is in conformance to the specification reads on “… to validate the received data”.]
Regarding independent claim 18, Anicic teaches:
A method comprising using a control device to create a nodeset file pertaining to an OPC UA-enabled automation device, the nodeset file defining validation logic used to validate data to be written to the OPC UA-enabled automation device. (Anicic: [0008] “In one embodiment, a gateway for transforming a description of an industrial process equipment into a semantically enriched and graph-based data information model for automation purposes is disclosed. The gateway includes a parsing module for parsing information entities in the description of the industrial process equipment by a field communication protocol and for transforming the parsed information entities into declarative logic facts and asserting the declarative logic facts within a deductive database. The gateway further includes a knowledge engine using a mapping knowledge base for applying mapping rules to the declarative logic facts, whereby the declarative logic facts are deductively mapped onto the graph-based data information model. Eventually, the gateway includes an interface module for accessing the graph-based data object model.”) (Anicic: [0024] “OPC UA offers direct data access, regardless of the level of the automation pyramid. OPC UA further provides an information model and transport layer communications, where clients at any level of the pyramid may directly access data served by one or more OPC UA servers, hosted at any level. This includes OPC UA servers hosted at the field device level. OPC UA imposes a prerequisite in that information of heterogeneous automation devices and systems is to be represented with the OPC UA Information Model (OPC UA IM), which is a semantically enriched and graph-based data information model for automation purposes.”) (Anicic: [0035] “The gateway acts in a plug-and-play fashion (e.g., connects to the field device FD, reads the field device description FDD, and maps field device information such as device parameters to an OPC UA address space). Device parameters and corresponding values may then be accessed by the gateway-internal server SRV using any standard OPC UA client (not shown) or any standard OPC UA server (not shown) connected to the gateway-internal server SRV.”) (Anicic [0083]-[0094] “[0083] EDDL_POST_EDIT_ACTIONS—specifies methods that are to be executed after the variable has been written to the device; [0084] EDDL_POST_READ_ACTIONS—specifies methods that are to be executed after the variable was read from the device; [0085] EDDL_POST_WRITE_ACTIONS—specifies methods that are to be executed after the variable has been written to the device; [0086] EDDL_PRE_EDIT_ACTIONS—specifies methods that are to be executed immediately when the variable is going to be edited; [0087] EDDL_PRE_READ_ACTIONS—specifies methods that are to be executed before the variable is read; [0088] EDDL_PRE_WRITE_ACTIONS—specifies methods that are to be executed before the variable is written to the device; [0089] EDDL_READ_TIMEOUT—specifies the length of time, in ms, the EDD application is to wait for the returned variable; [0090] EDDL_REFRESH_ACTIONS—specifies EDD methods that are to be executed whenever the variable is displayed or refreshed; [0091] EDDL_RESPONSE_CODES—specify values a device may return as error information; [0092] EDDL_STYLE—specifies the way a variable is displayed; [0093] EDDL_VALIDITY—specifies whether an element is valid or invalid; and [0094] EDDL_WRITE_TIMEOUT—specifies the length of time, in ms, an EDD application is to wait for confirmation that the variable is successfully written to the device.”) (Anicic: [0204] “FIG. 8 shows a flowchart for querying and extracting OPC UA information from the Datalog Engine in order to recursively instantiate all references pointing from a source node.”) (Anicic: [0217] “The embodiments allow for a discovery of the mapping knowledge or a part thereof. A user or an application may, for example, query the storage of mapping knowledge via expressive semantic queries.”) (Anicic: [0220] “The embodiments allow for a validation of field device data against the mapping knowledge. For example, it may be checked whether field device data is in conformance to a specification.”) [The gateway reads on “a control device”. The field device reads on “automation device”, and the field device being accessible by the OPC UA client or server reads on “an OPC UA-enabled automation device”. Using the mapping knowledge base for applying mapping rules where the declarative logic facts are mapped onto the graph-based data information model reads on “the nodeset file defining validation logic used to validate data …”. The gateway transforming the parsed information entities into declarative logic facts reads on “create a nodeset file”.]
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 3 and 12-16 are rejected under 35 U.S.C. 103 as being unpatentable over Anicic, in view of DIXON et al. (US 2021/0026030 A1) (“Dixon”).
Regarding claim 3, Anicic teaches all the claimed features of claim 1. Anicic does not expressly teach the recitations of claim 3.
Dixon teaches:
wherein the validation logic is implemented using a PYTHON script. (Dixon: [0172] “The PYTHON language is a multi-paradigm programming language that supports object-oriented programming and structured programming. Features in the PYTHON language can support functional programming and aspect-oriented programming. The PYTHON language uses dynamic typing, and a combination of reference counting and a cycle-detecting garbage collector for memory management. It also features dynamic name resolution (late binding), which binds method and variable names during program execution. The PYTHON language includes filter( ), map( ), and reduce( ) functions; list comprehensions, dictionaries, and sets; and generator expressions. The PYTHON language library includes modules such as itertools and functools that can implement various functional tools.”)
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Anicic and Dixon before them, to modify the logic program or instructions, to incorporate PYTHON language.
One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to do this modification because it would allow for supporting object-oriented programming and structured programming. (Dixon: [0170] “As an example, an ingestion service can enable ingestion of data in a quick and easy way to enable data consumption in a predictable and consistent manner that can be tested and validated, for example, as to hypotheses and/or workflows.”) (Dixon: [0172] “The PYTHON language is a multi-paradigm programming language that supports object-oriented programming and structured programming. Features in the PYTHON language can support functional programming and aspect-oriented programming. The PYTHON language uses dynamic typing, and a combination of reference counting and a cycle-detecting garbage collector for memory management. It also features dynamic name resolution (late binding), which binds method and variable names during program execution. The PYTHON language includes filter( ), map( ), and reduce( ) functions; list comprehensions, dictionaries, and sets; and generator expressions. The PYTHON language library includes modules such as itertools and functools that can implement various functional tools.”)
Regarding claim 12, Anicic and Dixon teach all the claimed features of claims 1 and 3. Dixon further teaches:
wherein the validation logic is implemented using a PYTHON script. (Dixon: [0172] as discussed in claim 3)
Regarding claim 13, Anicic and Dixon teach all the claimed features of claims 1 and 3. Anicic further teaches:
wherein the validation logic is stored in the nodeset file in a predetermined XML element, (Anicic: [0212] “The OPC UA information extracted from the Query Engine may be converted into XML nodes within an XML Schema of OPC UA. OPC UA Server Config Generator accomplishes this task, and then passes the information downstream to the OPC UA Server. In this way, every standard OPC UA client may access data that originated as EDD field device descriptions.”)
the method further comprising identifying the element that contains the validation logic according to an established convention. (Anicic: [0066] “According to an Industry Standard Specification entitled »IEC 62769-109-1:2015—Field Devices Integration (FDI)—Part 109-1: Profiles—HART and WirelessHART …”)
Regarding claim 14, Anicic and Dixon teach all the claimed features of claims 1 and 3. Anicic further teaches:
wherein the validation logic is stored in the nodeset file using a value attribute of a description of a UAVariable, (Anicic: [0096] “In the following, a mapping of an EDDL variable to a variable in the OPC UA information model is described. A Datalog atomic formula representing an OPC UA variable is specified as: …”)
the method further comprising identifying the UAVariable that contains the validation logic according to an established convention. (Anicic: [0066] “According to an Industry Standard Specification entitled »IEC 62769-109-1:2015—Field Devices Integration (FDI)—Part 109-1: Profiles—HART and WirelessHART …”)
Regarding claim 15, Anicic and Dixon teach all the claimed features of claims 1 and 3. Anicic further teaches:
wherein validating the data comprises using an information model to identify that a variable to be written is of a type that indicates a validation requirement and (Anicic: [0066]-[0080] “[0066] According to an Industry Standard Specification entitled »IEC 62769-109-1:2015—Field Devices Integration (FDI)—Part 109-1: Profiles—HART and WirelessHART« the description of attributes of an EDDL variable is specified as: [0067] EDDL_ID—UAObject node ID; [0068] EDDL_ID_1—variable node ID; [0069] EDDL_ID_2—variableType node ID; [0070] EDDL_ID_3—OPC_DataType node ID; [0071] EDDL_ID_4—node ID for variable EDDL_CONSTANT_UNIT; [0072] EDDL_ID_5—node ID for variable EDDL_STYLE; [0073] EDDL_ID_6—node ID for variable EDDL_VALIDITY; [0074] EDDL_VariableName—specifies identifier of a variable; [0075] EDDL_CLASS—specifies how the variable is used by the device and the EDD application for organization purposes and display; [0076] EDDL_LABEL—specifies the displayed designation of an element; [0077] EDDL_TYPE—specifies the data type of a variable; [0078] EDDL_CONSTANT_UNIT—is used if a variable has a units code that never changes; [0079] EDDL_DEFAULT_VALUE—specifies the default setting for the variable; [0080] EDDL_HANDLING—specifies the operations that may be performed on an element”)
executing the validation logic in relation to the variable to be written in response to the identifying. (Anicic [0083]-[0094] as discussed in claim 1)
Regarding claim 16, Anicic and Dixon teach all the claimed features of claims 1, 3 and 15. Anicic further teaches:
wherein the information model further defines a status variable for carrying the result of the validation, the method further comprising modifying the status variable to indicate the result of executing the validation logic in relation to the variable to be written. (Anicic: [0126] “The following section describes a creation of an OPC UA Variable Node Class: EDDL_VALIDITY. The signature of eddl_Variable has a term called EDDL_VALIDITY. This term from an EDDL variable is to be mapped to an OPC UA Property, which is a type of an OPC UA Variable: opc_ UAVariable( EDDL_ID_6, “EDDL_VALIDITY”, “String”, “-1”, “Not_Used”, “Not_Used”, “Not_Used”, “Not_Used”, “Not_Used”) <= eddl_Variable.”)
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Anicic, in view of BRAUN et al. (WO 2020208161 A1) (“Braun”).
Regarding claim 9, Anicic teaches all the claimed features of claim 8. Anicic does not expressly teach the recitations of claim 9.
Braun teaches:
wherein the OPC UA server is an aggregating server. (Braun: Page 2 lines 4-6 “An OPC-UA system may be organized according to an aggregation architecture. An aggregation architecture comprises aggregated servers and aggregation servers, also referred to as aggregating servers in this disclosure.”)
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Anicic and Braun before them, to modify the architecture of the OPC UA servers hosted at the field device level, to incorporate an aggregation architecture comprising aggregating servers.
One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to do this modification because it would allow for providing a platform-independent distributed control system for all OPC UA-connected devices. (Braun: Page 1 lines 14-19 “OPC UA is a standard specification defining communication of on-line data from various devices from different manufacturers. Future Distributed Control Systems (DCS) will run on OPC UA-connected devices. OPC UA is a platform-independent, service oriented client-server architecture, which transports machine data as control values, measurement values and parameters, and describes the machine data semantically.”)
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Anicic, in view of Dixon, further in view of Tewari et al. (US 2020/0137078 A1) (“Tewari”).
Regarding claim 17, Anicic and Dixon teach all the claimed features of claims 1 and 3. Anicic and Dixon do not expressly teach the recitations of claim 17.
Tewari teaches:
wherein the validation logic is stored in the nodeset file in encrypted form. (Tewari: [0003] “In exemplary embodiments the present technology includes a method for security of industrial data streams arising from industrial applications and devices, comprising: (a) provisioning a fogNode that is communicatively coupled with a fog cloud manager through a forwarder of the fogNode; (b) providing a fogLet within the fogNode, the fogLet communicating with a plurality of operational technology devices; (c) providing fogLet identification information using a root of trust of the fogNode, the root of trust of the fogNode being located in the fogNode; (d) providing fogLet encryption information using the root of trust of the fogNode; (e) communicating the fogLet identification information and the fogLet encryption information to the fog cloud manager; (f) transferring the fogLet identification information and the fogLet encryption information to a third party cloud application for validation of industrial data streams from the plurality of operational technology devices; (g) receiving operational device authentication information from a third party tenant application, the third party tenant application communicating with the plurality of operational technology devices; (h) providing the operational device authentication information with fogLet identification information using the root of trust of the fogNode; and (i) communicating the operational device authentication information with the fogLet identification information to the third party tenant application, the third party tenant application communicating the operational device authentication information with the fogLet identification information to the third party cloud application, the third party cloud application validating the industrial data streams from the plurality of operational technology devices using the operational device authentication information and the fogLet identification information.”)
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Anicic, Dixon and Tewari before them, to modify the logic program and mapping knowledge base query process, to incorporate an encryption.
One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to do this modification because it would allow for a data security. (Tewari: [0002] “The present invention pertains to data analytics and a security service for industrial data streams arising from industrial applications and devices. In particular, but not by way of limitation, the present technology provides data analytics security for industrial automation and the Industrial Internet of Things (IIoT).”)
Allowable Subject Matter
Claims 10-11 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
It is noted that any citations to specific, pages, columns, lines, or figures in the prior art references and any interpretation of the reference should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See MPEP 2123.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W CHOI whose telephone number is (571)270-5069. The examiner can normally be reached Monday-Friday 8am-5pm.
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, Kenneth Lo can be reached at (571) 272-9774. 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.
/MICHAEL W CHOI/Primary Examiner, Art Unit 2116
Prosecution Insights