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-8 and 11-18 are pending.
Claims 9-10 are cancelled.
Claims 8 and 11-12 are allowable.
Information Disclosure Statement
The references cited in the information disclosure statements (IDS) submitted on 06/08/2026 have been considered by the examiner.
Response to Amendment
Applicant’s amendments to the claim 4 have overcome each and every objections previously set forth. The objections of the claim 4 have been withdrawn.
Applicant’s amendments to the claim 12 have overcome each and every 112(d) rejections previously set forth. The 112(d) rejections of the claim 12 have been withdrawn.
Applicant’s amendments to independent claim 8 have overcome each and every 102 rejections previously set forth. The 102 rejections of independent claim 8 have been withdrawn.
Response to Arguments
Applicant’s arguments with respect to the 102 rejections of independent claims 1 and 18 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
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, 4-7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Anicic et al. (US 2022/0058502 A1) (“Anicic”), in view of Schulz et al. (US 2020/0333770 A1) (“Schulz”)
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”.]
Anicic does not expressly teach: the nodeset file including an association linking the validation logic to a data parameter of the automation device.
Shulz teaches:
the nodeset file including an association linking the validation logic to a data parameter of the automation device. (Shulz: [0024] “In one embodiment, the analyzer may execute a conformance test associated with the at least first technical specification to validate the conformance of the server data model with the at least first technical specification prior to deriving the one or more element types. During the conformance text, the analyzer checks if the server data model adheres to one or more of the technical specifications stored in the technical specifications database. For example, a server may include an annotation with an explicit reference to a technical standard. The analyzer can then check if the actual server data model really complies with the respective standard as specified in the technical specifications database. This improves the reliability of the corresponding element type derivations and therefore can improve a selection of transformation rule sets providing appropriate transformation packages for the server.”) [The data model reads on “the nodeset file”. The conformance test associated with the at least first technical specification annotated with the explicit reference, reads on “an association linking the validation logic to a data parameter of the automation device”.]
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 Shulz before them, to modify the automation devices and systems is to be represented with the OPC UA Information Model, to incorporate conformance test associated with the technical specification.
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 corresponding technical specification with validation be used for the derivation of the corresponding model element types. (Shulz: [0040] “In case the analyzer cannot unambiguously identify at least one technical specification matching the server data model 111, the analyzer may execute a conformance test prior to deriving the one or more element types. In the conformance test, the analyzer validates the conformance of the server data model 111 with one or more of the technical specifications 310, 311, 312 to identify at least one technical specification which matches the meta-model to which the server data model 111 adheres. Such validation can make use of all of the above mentioned data model structure elements and compare such elements with the model structure elements of the various technical specifications. If at least parts of the server data model show a similarity with the corresponding model structure elements of a corresponding technical specification above a predefined similarity threshold value, the corresponding technical specification is used for the derivation of the corresponding model element types.”)
Regarding claim 2, Anicic and Shulz teach 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 and Shulz teach 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.”)
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 5, Anicic and Shulz teach 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 and Shulz teach 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 and Shulz teach 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 18, Anicic teaches:
A method comprising using a control device during development 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”.]
Anicic does not expressly teach: wherein creating the nodeset file comprises embedding a script defining the validation logic in the nodeset file and linking the script to a specified data parameter of the automation device via a reference in the nodeset file such that the script is invokable for validating data for said specified data parameter.
Shulz teaches:
wherein creating the nodeset file comprises embedding a script defining the validation logic in the nodeset file and linking the script to a specified data parameter of the automation device via a reference in the nodeset file such that the script is invokable for validating data for said specified data parameter. (Shulz: [0024] “In one embodiment, the analyzer may execute a conformance test associated with the at least first technical specification to validate the conformance of the server data model with the at least first technical specification prior to deriving the one or more element types. During the conformance text, the analyzer checks if the server data model adheres to one or more of the technical specifications stored in the technical specifications database. For example, a server may include an annotation with an explicit reference to a technical standard. The analyzer can then check if the actual server data model really complies with the respective standard as specified in the technical specifications database. This improves the reliability of the corresponding element type derivations and therefore can improve a selection of transformation rule sets providing appropriate transformation packages for the server.”) (Shulz: [0040] “In case the analyzer cannot unambiguously identify at least one technical specification matching the server data model 111, the analyzer may execute a conformance test prior to deriving the one or more element types. In the conformance test, the analyzer validates the conformance of the server data model 111 with one or more of the technical specifications 310, 311, 312 to identify at least one technical specification which matches the meta-model to which the server data model 111 adheres. Such validation can make use of all of the above mentioned data model structure elements and compare such elements with the model structure elements of the various technical specifications. If at least parts of the server data model show a similarity with the corresponding model structure elements of a corresponding technical specification above a predefined similarity threshold value, the corresponding technical specification is used for the derivation of the corresponding model element types.”) [The data model reads on “the nodeset file”. The conformance test associated with the at least first technical specification, annotated with the explicit reference, reads on “embedding a script defining the validation logic and linking …”. The conformance test that analyzer uses to validate reads on “such that the script is invokable for validating data …”.]
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 Shulz before them, to modify the automation devices and systems is to be represented with the OPC UA Information Model, to incorporate conformance test associated with the technical specification.
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 corresponding technical specification with validation be used for the derivation of the corresponding model element types. (Shulz: [0040] “In case the analyzer cannot unambiguously identify at least one technical specification matching the server data model 111, the analyzer may execute a conformance test prior to deriving the one or more element types. In the conformance test, the analyzer validates the conformance of the server data model 111 with one or more of the technical specifications 310, 311, 312 to identify at least one technical specification which matches the meta-model to which the server data model 111 adheres. Such validation can make use of all of the above mentioned data model structure elements and compare such elements with the model structure elements of the various technical specifications. If at least parts of the server data model show a similarity with the corresponding model structure elements of a corresponding technical specification above a predefined similarity threshold value, the corresponding technical specification is used for the derivation of the corresponding model element types.”)
Claims 3 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Anicic, in view of Shulz, further 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, Shulz 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 13, Anicic, Shulz 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, Shulz 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, Shulz 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, Shulz 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 17 is rejected under 35 U.S.C. 103 as being unpatentable over Anicic, in view of Shulz, further in view of Dixon, further in view of Tewari et al. (US 2020/0137078 A1) (“Tewari”).
Regarding claim 17, Anicic, Shulz and Dixon teach all the claimed features of claims 1 and 3. Anicic, Shulz 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, Shulz, 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).”)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 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