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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 19 and 21 have been canceled.
Claims 1-18, 20 and 22 are pending.
Claims 1-18, 20 and 22 are rejected, grounds follow.
THIS OFFICE ACTION IS FINAL, see additional information at the conclusion of this action.
Priority
Examiner acknowledges that instant application is a Continuation of Applications 16/072,925 (now US patent 10,990,086) and 17/171,020 (now US patent 11,874,648) and has been accorded the benefit of the original priority date
Response to Arguments
Applicant’s arguments, see Remarks page 7, filed 26 February 2026, with respect to the 35 USC 112(b) rejection of claim 21 have been fully considered, but are moot because claim 21 has been cancelled. The 35 USC 112(b) rejection of Claim 21 has been withdrawn pursuant to said cancellation. Examiner notes for clarity of the record that the several amendments to the claims have introduced a new 35 USC 112(b) issue, see detailed rejection below.
Applicant’s arguments, see Remarks page 7, with respect to the 35 USC 101 rejection of claims 1-5 have been fully considered and are persuasive. Examiner agrees that the claim(s) now embrace statutory subject matter, and accordingly the 35 USC 101 rejection of claims 1-5 has been withdrawn.
Applicant's arguments, see Remarks Page 8 have been fully considered and they are persuasive in part. As to the persuasive part, Examiner agrees that the amendment overcomes the 35 USC 102 rejection of Claims 1-5, as the “DIMA” reference does not appear to teach or fairly suggest the amended subject matter. After further consideration, a new rejection in view of DIMA, Lawson and Rosca, has been made, see detailed rejection below.
As to the unpersuasive part; Examiner notes that the limitations added to the amended independent claims were previously presented in Claims 19 and 21. Examiner thanks applicant’s representative for addressing the rejections applied to Claims 19 and 21. Applicant argues (see Page 8) that none of the references, DIMA, Lawson, or Rosca, alone or in reasonable combination, teaches or fairly suggests “wherein the controller is configured such that the server is dynamically queryable for each object individually”. And discusses specifically the Rosca reference, alleging that it fails to teach the query is ‘dynamic’ for ‘each object individually’. Examiner disagrees, Rosca teaches a system where ([0074) “Queries for data can be issued by any controllers, allowing ad-hoc query execution, pre-defined queries, and also formula calculation based on controller tags.” Clearly recites dynamic queries being executed. Rosca also teaches queries may retrieve each individual object, such as individual (per second) recorded energy consumption data (see [0068] “ For example, the results of an infield analytic task that performs calculations (e.g., power consumption) every second” “can periodically (e.g., every hour or day) be migrated to the DDMS instance, allowing results to be accessible to other Intelligent PLCs and also external automation tools (e.g., SCADA, engineering tools, MES).” [n.b. the DDMS is the component which implements the ‘sql-like’ querying function, see [0031].) as well as events (ibid.), queries run against tagged data or timestamps (see [0073]), or structural and status object data (see [0053]). Examiner finds that the teachings of Rosca convey to one of ordinary skill in the art before the effective filing date of the application an industrial control system where the data objects of the server structure of an external interface (i.e. Rosca’s DDMS) of a controller (i.e. Rosca’s PLC controller) supports dynamic querying of individual objects of the server structure which are comprised of real time data (e.g. power consumption data) and descriptive data (e.g. timestamps, tags, etc.) and therefore reads on the disputed limitation and renders the claim obvious in combination with the other references applied to the rejection of previously presented Claims 19 and 21. Accordingly the rejection is maintained. Please see below for detailed rejection.
Applicant's arguments, see Remarks Page 9 have been fully considered but they are not persuasive. Applicant’s arguments merely allege patentability but do not specifically point out how the claims distinguish over the provisional double patenting rejection. After review Examiner finds that the amended independent claims do not recite subject matter that is patentability distinct from the prior Patents and accordingly the non-statutory obviousness-type double patenting rejections are maintained. Please see below for detailed rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-6 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the information structure" in Claim 1 line 7. There is insufficient antecedent basis for this limitation in the claim.
Claim(s) 2-6 inherit the deficiencies of their respective parent claim(s).
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.
Claim(s) 1-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wago; “DIMA – Dezentrale Intelligenze für modulare Anlagen” (2015). (Citations to Google Machine Translation; hereafter “DIMA”) in view of Lawson et al., US Pg-Pub 2013/0212420 and Rosca et al., US Pg-Pub 2020/0089182.
Regarding Claim 1, DIMA teaches:
A non-transitory computer readable medium containing a module type package (MTP), (Page 4 “To ensure that the module engineering information required for integration can be transferred to the PCS, it is stored in an information carrier, the so-called Module Type Package (MTP).”)
The MTP comprising: data (page 4, e.g. data about services)
and information for virtual and professional representation (page 4-5 e.g. “visualization using Scada system” Page 5 “This description contains information about the meaning of the operating screen element as well as its location and size )
of a module (Page 3 “The module supplier first designs the module and generates the MTP”) for a technical facility, (see Page 5, fig. 5, and Page 3: “DIMA (Decentralized Intelligence for Modular Plants) demonstrates the consistent modular and decentralized automation of a modular process-engineering production plant – taking both technical and organizational aspects into account. WAGO presented the DIMA methodology at the NAMUR general meeting in November 2014.”)
wherein the module type package is mapped into an information module of a server structure of the module, (see fig. 6, particularly the OPCUA-Node and OPCUA-server, which discloses mapping the MTP into an information module (i.e. the node) of a server structure (the OCPUA server) of the module.)
Please note this enlarged inset of DIMA fig. 6:
PNG
media_image1.png
747
916
media_image1.png
Greyscale
wherein the information structure of the server comprises a number of objects (see fig. 6, OPC-UA Nodes of the OPC-UA server are disclosed as including “Objects” with various properties.)
DIMA differs from the claimed invention in that:
DIMA does not appear to clearly articulate [the objects] each having at least one real-time value and a description of the real-time value;
DIMA does not appear to clearly articulate the controller is configured such that the server is dynamically queryable for each object individually.
However, Lawson teaches a system (see fig. 1) for a technical facility (see fig. 1, e.g. “Industrial facility”) including a controller (see fig. 3 “Controller 302”) where the controller is connected to a server by an external interface (see fig. 3 “Cloud interface component 314” and [0052] “Cloud interface component 314 can be configured to access the cloud through any suitable hardwired or wireless connection to the Internet (e.g., through a network connection to an Internet server”) where the server comprises objects (see fig. 11, table 1106; each table entry comprising an object) each having at least one real-time value (fig. 11, table 1106, ‘time stamp’ and ‘value’) and a description of the real-time value. (fig. 11, table 1106; “data tag”)
DIMA and Lawson are analogous art because they are from the same field of endeavor as the claimed invention and other references of industrial automation, and contain overlapping structural and functional similarity. Each uses a plurality of controllers to operate various aspects of an automated process; each transmits and receives process monitoring data across an automation network.
One of ordinary skill in the art before the effective filing date of the application could have modified the teachings of DIMA to include mapping the objects in the OPC-UA server structure of DIMA to include fields for at least one real time value and descriptions of the value, as suggested by Lawson.
One of ordinary skill in the art before the effective filing date of the application could have been motivated to make this modification in order to accurately document a sequence of events that occurred over geographically distributed locations in an industrial automation process, as suggested by Lawson. ([0079] “Since the time stamps applied to the stored industrial data conform to a common time standard (by virtue of synchronization of the internal clocks of the respective devices), data events at different locations can be aggregated into a chronological presentation in order to accurately document a sequence of events that occurred at geographically distributed locations.”)
And Rosca teaches a PLC (intelligent PLC, see [0031]) in an industrial control network (see fig. 1) which includes a data management layer (see [0031] “[the PLC] can provide a data management layer”) which may be a server ([0028] “Each instance of DDMS hosts client and server roles”) of a distributed data management platform ([0042] “each Intelligent PLC (or more generally, node) hosts an instance of the DDMS”) which is dynamically queryable ([0031] “[the PLC] can provide a data management layer that supports querying in an SQL like manner”; see [0074] “Queries for data can be issued by any controllers, allowing ad-hoc query execution”) for individual data objects of the PLC (e.g. historian data, events, see [0068]; tags and timestamps, see [0073]; structure and status, see [0053].)
Rosca is analogous art because it is from the same field of endeavor as the claimed invention and other references of industrial automation, and contains overlapping structural and functional similarity. Like the other references, Rosca uses a plurality of controllers to operate various aspects of an automated process; transmitting and receiving process monitoring data across an automation network.
One of ordinary skill in the art could have modified the teachings of Lawson to facilitate querying the controller(s) for individual objects using dynamic queries, as suggested by Rosca.
One of ordinary skill in the art could have been motivated to make this modification in order to empower distributed data access from external applications, and to improve interoperability with commercially available client tools, as suggested by Rosca. ([0061] “Access to the platform can be made directly by standard query languages like SQL/SPARQL or using client tools such as ODBC, OPC UA, Mongo APIs, which leverage interoperability on Intelligent PLCs and empower the distributed data access from external devices and applications.”)
Regarding Claim 2, DIMA in view of Lawson and Rosca teaches all of the limitations of parent claim 1,
DIMA further teaches:
wherein the server is an OPC-UA server of the module. (per fig. 6, see enlargement supra, the server is described as an OPCUA server).
Regarding Claim 3, DIMA in view of Lawson and Rosca teaches all of the limitations of parent claim 1,
DIMA further teaches:
information for querying and monitoring services of the module. (Page 4 “module engineering – generating the MTP” “implementation of parts of the coordination and procedure control for timely retrieval and monitoring (orchestration) of module services”)
Regarding Claim 4, DIMA in view of Lawson and Rosca teaches all of the limitations of parent claim 1,
DIMA further teaches:
a link to a state of the module (Page 4 “To orchestrate services across modules, knowledge of the current states, such as run, stop, or error, and corresponding state transitions is necessary. This information is determined by the decentralized intelligence of each module and transmitted via a communication interface.”) and all services of the module. (Page 4 “the functions provided by the modules are encapsulated as services.” “A module is represented as a unit, and the services offered by the module are represented as a so-called basic function”)
Regarding Claim 5, DIMA in view of Lawson and Rosca teaches all of the limitations of parent claim 1,
DIMA further teaches:
a description of an external interface of the module. (Page 5 “To translate module-specific operating screens into ones with a project-wide "look and feel," the operating screens must be available in a representation-independent description format. This description contains information about the meaning of the operating screen element as well as its location and size”)
Claim(s) 6-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lawson in view of DIMA, further in view of Rosca.
Regarding Claim 6, Lawson teaches:
A system, (see fig. 1) comprising: a module (see e.g. fig. 3) for a technical facility (see fig. 1, e.g. “Industrial Facility”) comprising: a technical hardware for executing a technical sub-process; (field devices, [0050] “Industrial controller 302 can exchange data with the controlled industrial processes 304.sub.1-304.sub.N through I/O 308, which can comprise one or more local or remote input and/or output modules that communicate with one or more field devices to effect control of the controlled industrial processes 304.sub.1-304.sub.N.”)
a controller (Fig. 3, Controller 302) for locally controlling the technical hardware, (fig. 3; “industrial controller 302 can be, for example, a programmable logic controller (PLC) or other type of programmable automation controllers (PAC) executing control program 310 to facilitate monitoring and control of one or more controlled industrial processes 304.sub.1-304.sub.N.”; wherein the controller is configured to control the technical hardware autonomously; (control program 310 is depicted with communication Input only from the controlled processes and accordingly is a standalone controller.)
and an external interface of the controller, (fig. 3, “cloud interface component” 314) wherein the external interface comprises a server, [0052] “Cloud interface component 314 can be configured to access the cloud through any suitable hardwired or wireless connection to the Internet (e.g., through a network connection to an Internet server”)
the server comprising a fixedly predetermined information structure with static information and dynamic information, ([0064] “Context component 804 an also apply contextual information to the time-stamped production data 802 that reflects the data's location within a hierarchical organizational model. Such an organization model can represent an industrial enterprise in terms of multiple hierarchical levels.” disclosing static and dynamic information; stored in a cloud database, see e.g. [0075]-[0077] and fig. 10)
wherein the static information describes the technical hardware and the controller, (see e.g. [0052] “the cloud interface component 314 can provide information to the cloud services about the industrial controller 302 and its context within the overall enterprise or plant hierarchy. For example, when the industrial controller 302 initially interfaces with the cloud platform during deployment, the cloud interface component 314 can provide such information as a device identifier for the controller; a geographic location of the controller; a location of the controller relative to the greater automation system, plant, or hierarchy to which the controller belongs;”) and wherein the controller writes the dynamic information as real-time values of the technical hardware into the information structure; ([0051] “During operation, industrial controller 302 generates or collects (near) real-time data relating to controlled industrial processes 304.sub.1-304.sub.N,” [0052] “Once configured, the cloud interface component 314 can push controller data to the cloud”; see also, e.g. [0075] “Time-stamped industrial data is received from industrial devices 1004 at device interface component 1014, which can store the received data on cloud storage 1012. … If data provided by industrial devices 1004 include contextual metadata, filter component 1016 can be configured to filter the data based on some aspect of this contextual metadata.”)
a process management level; (see fig. 6, and [0061] “For example, the cloud-based service may be an enterprise resource management (ERP) system that analyzes production data in view of one or more defined business goals”)
wherein the information structure of the server comprises a number of objects (see fig. 11, table 1106; each table entry comprising an object) each having at least one real-time value (fig. 11, table 1106, ‘time stamp’ and ‘value’) and a description of the real-time value. (fig. 11, table 1106; “data tag”)
Lawson differs from the claimed invention in that:
Lawson does not clearly articulate: a module type package (MTP) mapped into an information module of the server;
Lawson does not clearly articulate: wherein the controller is configured such that the server is dynamically queryable for each object individually.
However, DIMA teaches an industrial automation system (see Page 5, fig. 5, and Page 3: “DIMA (Decentralized Intelligence for Modular Plants) demonstrates the consistent modular and decentralized automation of a modular process-engineering production plant – taking both technical and organizational aspects into account. WAGO presented the DIMA methodology at the NAMUR general meeting in November 2014.”) where data and service information for a controller is encapsulated in a module type package (MTP) mapped into and information module of the server. (Page 3 “The module supplier first designs the module and generates the MTP” Page 4 “[engineering information] is stored in an information carrier, the so-called Module Type Package (MTP).” And fig. 6, see enlarged inset, next page)
PNG
media_image1.png
747
916
media_image1.png
Greyscale
DIMA and Lawson are analogous art because they are from the same field of endeavor as the claimed invention and other references of industrial automation, and contain overlapping structural and functional similarity. Each uses a plurality of controllers to operate various aspects of an automated process; each transmits and receives process monitoring data across an automation network.
One of ordinary skill in the art before the effective filing date of the application could have modified the teachings of Lawson to map the process control and monitoring data of the controllers of Lawson into a module-type package mapped into the server, as suggested by DIMA.
One of ordinary skill in the art before the effective filing date of the application could have been motivated to make this modification in order to ensure the module engineering information required for integration of the controllers into the overall system can be transferred, as suggested by DIMA. (Page 4 “To ensure that the module engineering information required for integration can be transferred to the PCS, it is stored in an information carrier, the so-called Module Type Package (MTP).”)
And Rosca teaches a PLC (intelligent PLC, see [0031]) in an industrial control network (see fig. 1) which includes a data management layer (see [0031] “[the PLC] can provide a data management layer”) which may be a server ([0028] “Each instance of DDMS hosts client and server roles”) of a distributed data management platform ([0042] “each Intelligent PLC (or more generally, node) hosts an instance of the DDMS”) which is dynamically queryable ([0031] “[the PLC] can provide a data management layer that supports querying in an SQL like manner”; see [0074] “Queries for data can be issued by any controllers, allowing ad-hoc query execution”) for individual data objects of the PLC (e.g. historian data, events, see [0068]; tags and timestamps, see [0073]; structure and status, see [0053].)
Rosca is analogous art because it is from the same field of endeavor as the claimed invention and other references of industrial automation, and contains overlapping structural and functional similarity. Like the other references, Rosca uses a plurality of controllers to operate various aspects of an automated process; transmitting and receiving process monitoring data across an automation network.
One of ordinary skill in the art could have modified the teachings of Lawson to facilitate querying the controller(s) for individual objects using dynamic queries, as suggested by Rosca.
One of ordinary skill in the art could have been motivated to make this modification in order to empower distributed data access from external applications, and to improve interoperability with commercially available client tools, as suggested by Rosca. ([0061] “Access to the platform can be made directly by standard query languages like SQL/SPARQL or using client tools such as ODBC, OPC UA, Mongo APIs, which leverage interoperability on Intelligent PLCs and empower the distributed data access from external devices and applications.”)
Regarding Claim 7, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
DIMA further teaches:
wherein the module type package comprises data and information for virtual and professional representation of a module for a technical facility. (page 4-5 e.g. “visualization using Scada system” Page 5 “This description contains information about the meaning of the operating screen element as well as its location and size )
Regarding Claim 8, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
DIMA further teaches:
wherein the module type package comprises information for querying and monitoring services of the module. (Page 4 “module engineering – generating the MTP” “implementation of parts of the coordination and procedure control for timely retrieval and monitoring (orchestration) of module services”)
Regarding Claim 9, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
DIMA further teaches:
wherein the module type package comprises a link to a state of the module (Page 4 “To orchestrate services across modules, knowledge of the current states, such as run, stop, or error, and corresponding state transitions is necessary. This information is determined by the decentralized intelligence of each module and transmitted via a communication interface.”) and all services of the module. (Page 4 “the functions provided by the modules are encapsulated as services.” “A module is represented as a unit, and the services offered by the module are represented as a so-called basic function”)
Regarding Claim 10, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
DIMA further teaches:
wherein the module type package comprises a link to a description of the external interface of the module. (Page 5 “To translate module-specific operating screens into ones with a project-wide "look and feel," the operating screens must be available in a representation-independent description format. This description contains information about the meaning of the operating screen element as well as its location and size”)
Regarding Claim 11, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
DIMA further teaches:
wherein the process management level is configured to query the module via the external interface of the module. (Page 4 “The module thus communicates directly with the batch tool and receives the command to execute a service from there. Once the module has correctly completed the execution of the service, it reports this as the "Completed" status of the ISA-S 88 state model.”)
Regarding Claim 12, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
DIMA further teaches:
wherein the module type package comprises a link to all services that the module provides to the process management level. (Page 4 “DIMA enables services to be sequenced as desired using batch tool functionality. The functional spectrum of a production plant is then visualized in the batch tool using multiple models. A module is represented as a unit, and the services offered by the module are represented as a so-called basic function (phase).”)
Regarding Claim 13, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 12,
DIMA further teaches:
wherein the services provided by the module are integrated into a process controller of the process management level. (Page 4 “Combining multiple modules in a plant necessitates scheduling the modules' services. For example, in a continuously operating reaction process, reactor start-up must be coordinated with the introduction of the starting materials.” Page 4 “This process generates information that is also required for integrating the module into the PCS.” See also Page 3 “The modules then only need to be integrated into the automation system, e.g., the process control system”)
Regarding Claim 14, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
DIMA further teaches:
wherein the module type package comprises a link to a description of external interface including an operation screen hierarchy and an operation screen description. (Page 5 “To translate module-specific operating screens into ones with a project-wide "look and feel," the operating screens must be available in a representation-independent description format. This description contains information about the meaning of the operating screen element as well as its location and size (Figure 4).”)
Regarding Claim 15, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
Lawson further teaches:
wherein the controller of the module generates the real-time values from control data and/or measurement data of the technical hardware. ([0051] During operation, industrial controller 302 generates or collects (near) real-time data relating to controlled industrial processes 304.sub.1-304.sub.N, such as part counts, temperatures, pressures, motor speeds or loads, vibration data, weights, quality test results, alarms, machine states, operator feedback, or other such information.”)
Regarding Claim 16, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
Lawson further teaches:
wherein the controller of the module generates the real-time values from states of the service provided by the technical hardware. ([0051] During operation, industrial controller 302 generates or collects (near) real-time data relating to controlled industrial processes 304.sub.1-304.sub.N, such as part counts, temperatures, pressures, motor speeds or loads, vibration data, weights, quality test results, alarms, machine states, operator feedback, or other such information. … data can be generated by control program 310 based on measured process values”)
Regarding Claim 17, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
Lawson further teaches:
wherein the controller generates the real-time values from historical values of control data and/or measurement data of the technical hardware and/or communication data. ([0051] “The data collected or generated by industrial controller data--raw data 306--can be stored in non-volatile memory associated with the industrial controller 302, … As used in this disclosure, the term "raw" data is intended to refer to any industrial data that has not been enhanced with time-stamp information. This can include, but is not limited to, data that has been collected, generated, and/or processed by an industrial device (e.g., a programmable logic controller, automation controller, human-machine interface, network infrastructure device, enterprise resource planning system, etc.), data stored on an industrial device or data historian, data generated by field devices (e.g., sensors, meters, etc.), or other such data.”)
Regarding Claim 18, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
Lawson further teaches:
wherein the controller of the module generates the real-time values by extrapolation based on control data and/or measurement data of the technical hardware and/or communication data. ([0051] “data can be generated by control program 310 based on measured process values (e.g., alarms, derived or calculated values, etc.).”
Regarding Claim 20, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
Lawson further teaches:
wherein the control of the technical hardware is done via at least one service provided by the controller and by the controlled technical hardware, ([0049] “industrial controller 302 can be, for example, a programmable logic controller (PLC) or other type of programmable automation controllers (PAC) executing control program 310 to facilitate monitoring and control of one or more controlled industrial processes”)
and wherein the at least one service is mapped into the information structure in the server. ([0052] “the cloud interface component 314 can provide information to the cloud services about the industrial controller 302 and its context within the overall enterprise or plant hierarchy.” “the cloud interface component 314 can provide such information as a device identifier for the controller; a geographic location of the controller; a location of the controller relative to the greater automation system, plant, or hierarchy to which the controller belongs; indications of other devices or systems in proximity to the controller (e.g., devices communicatively coupled to the controller);” see also fig. 9)
Regarding Claim 22, Lawson in view of DIMA and Rosca teaches all of the limitations of parent claim 6,
DIMA further teaches:
wherein the server is an OPC-UA server. (per fig. 6, see enlargement supra, the server is described as an OPCUA server).
Double Patenting
For clarity of the record, please note that this application is rejected under non-statutory double patenting over each of 11,874,648 and 10,990,086; separately.
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 6, 11, 15-18, 20 and 22 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-6 and 9-12 of U.S. Patent No. 11,874,648 in view of Wago; “DIMA – Dezentrale Intelligenze für modulare Anlagen” (2015). Although the claims at issue are not identical, they are not patentably distinct from each other because as illustrated in the table below, the reference patent, in view of the secondary reference, teaches or fairly suggests the claims at issue in the instant application.
Instant Application
11,874,648
6. A system comprising: a module for a technical facility comprising a technical hardware for executing a technical sub-process; a controller for locally controlling the technical hardware,
1. A module for a technical facility comprising: a technical hardware for executing a technical sub-process; a controller for locally controlling the technical hardware,
wherein the controller is configured to control the technical hardware autonomously;
wherein the controller is configured to control the technical hardware autonomously;
and an external interface of the controller, wherein the external interface comprises a server, the server comprising a fixedly determined information structure with static information and dynamic information, wherein the static information describes the technical hardware and the controller, and wherein the controller writes the dynamic information as real-time values of the technical hardware into the information structure;
and an external interface of the controller, wherein the external interface comprises a server, the server comprising a fixedly predetermined information structure with static information and dynamic information, wherein the static information describes the technical hardware and the controller, and wherein the controller writes the dynamic information as real-time values of the technical hardware into the information structure.
a process management level; and a module type package (MTP) mapped into the server;
(Claim 10.) …The module according to claim 6, wherein the objects of the information structure of the server form a module type package containing all information necessary to integrate the module into a technical facility. (in view of DIMA pages 4-5 (particularly fig. 5) depicting a MTP mapped into a server process management level.)
wherein the information structure of the server comprises a number of objects each having at least one real-time value and a description of the real-time value
6. The module according to claim 1, wherein the information structure of the server comprises a number of objects each having at least one real-time value and a description of the real-time value.
And wherein the controller is configured such that the server is dynamically queryable for each object individually.
11. The module according to claim 1, wherein the controller is configured such that the server is dynamically, in particular for each object individually queryable.
11. The system according to claim 6, wherein the process management level is configured to query the module via the external interface of the module.
11. The module according to claim 1, wherein the controller is configured such that the server is dynamically, in particular for each object individually queryable.
15. the system according to claim 6, wherein the controller of the module generates the real-time values from control data and/or measurement data of the technical hardware.
2. The module according to claim 1, wherein the controller generates the real-time values from control data and/or measurement data of the technical hardware.
16. The system according to claim 6, wherein the controller of the module generates the real-time values from states of the service provided by the technical hardware.
3. The module according to claim 1, wherein the controller generates the real-time values from states of the service provided by the technical hardware.
17. The system according to claim 6, wherein the controller generates the real-time values from historical values of control data and/or measurement data of the technical hardware and/or communication data.
4. The module according to claim 1, wherein the controller generates the real-time values from historical values of control data and/or measurement data of the technical hardware and/or communication data.
18. The system according to claim 6, wherein the controller of the module generates the real-time values by extrapolation based on control data and/or measurement data of the technical hardware and/or communication data
5. The module according to claim 1, wherein the controller generates the real-time values by extrapolation based on control data and/or measurement data of the technical hardware and/or communication data.
20. The system according to claim 6 wherein the control of the technical hardware is done via at least one service provided
9. The module according to claim 1, wherein the control of the technical hardware is done via at least one service provided by the controller and by the controlled technical hardware, and wherein the at least one service is mapped into the information structure in the server.
22. The system according to claim 6, wherein the server is an OPC-UA server.
12. The module according to claim 1, wherein the server is an OPC-UA server.
Claims 6, 11, 15-18, 20, and 22 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-6, 9-11 and 15 of U.S. Patent No. 10,990,086 in view of Wago; “DIMA – Dezentrale Intelligenze für modulare Anlagen” (2015). Although the claims at issue are not identical, they are not patentably distinct from each other because as illustrated in the table below, the reference patent, in view of the secondary reference, teaches or fairly suggests the claims at issue in the instant application.
Instant Application
10,990,086
6. A system comprising: a module for a technical facility comprising
(line 1) 1. A module for a technical facility comprising:
a technical hardware for executing a technical sub-process; a controller for locally controlling the technical hardware,
a technical hardware for executing a technical sub-process; a controller for locally controlling the technical hardware,
wherein the controller is configured to control the technical hardware autonomously;
(lines 15-18) wherein the controller is configured … to control the technical hardware autonomously;
and an external interface of the controller, wherein the external interface comprises a server, the server comprising a fixedly determined information structure with static information and dynamic information,
(lines 4-et.seq) and an external interface of the controller, wherein the external interface comprises a server, the server comprising a fixedly predetermined information structure with static information and dynamic information,
wherein the static information describes the technical hardware and the controller,
wherein the static information describes the technical hardware and the controller,
and wherein the controller writes the dynamic information as real-time values of the technical hardware into the information structure;
wherein the controller writes the dynamic information as real-time values of the technical hardware into the information structure,
wherein the information structure of the server comprises a number of objects each having at least one real-time value and a description of the real-time value
6. The module according to claim 1, wherein the information structure of the server comprises a number of objects each having at least one real-time value and a description of the real-time value.
And wherein the controller is configured such that the server is dynamically queryable for each object individually.
11. The module according to claim 1, wherein the controller is configured such that the server is dynamically, in particular for each object individually queriable.
a process management level; and a module type package (MTP) mapped into the server;
10. The module according to claim 6, wherein the objects of the information structure of the server form a module type package containing all information necessary to integrate the module into a technical facility. (Obvious in view of DIMA pages 4-5 (particularly fig. 5) depicting a MTP mapped into a server process management level.)
11. The system according to claim 6, wherein the process management level is configured to query the module via the external interface of the module.
11. The module according to claim 1, wherein the controller is configured such that the server is dynamically, in particular for each object individually queriable.
15. the system according to claim 6, wherein the controller of the module generates the real-time values from control data and/or measurement data of the technical hardware.
2. The module according to claim 1, wherein the controller generates the real-time values from control data and/or measurement data of the technical hardware.
16. The system according to claim 6, wherein the controller of the module generates the real-time values from states of the service provided by the technical hardware.
3. The module according to claim 1, wherein the controller generates the real-time values from states of the service provided by the technical hardware.
17. The system according to claim 6, wherein the controller generates the real-time values from historical values of control data and/or measurement data of the technical hardware and/or communication data.
4. The module according to claim 1, wherein the controller generates the real-time values from historical values of control data and/or measurement data of the technical hardware and/or communication data.
18. The system according to claim 6, wherein the controller of the module generates the real-time values by extrapolation based on control data and/or measurement data of the technical hardware and/or communication data
5. The module according to claim 1, wherein the controller generates the real-time values by extrapolation based on control data and/or measurement data of the technical hardware and/or communication data.
20. The system according to claim 6 wherein the control of the technical hardware is done via at least one service provided
9. The module according to claim 1, wherein the control of the technical hardware is done via at least one service provided by the controller and by the controlled technical hardware, and wherein the at least one service is mapped into the information structure in the server.
22. The system according to claim 6, wherein the server is an OPC-UA server.
15. The module according to claim 1, wherein the server is an OPC-UA server.
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 JOSHUA T SANDERS whose telephone number is (571)272-5591. The examiner can normally be reached Generally Monday through Friday.
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, Mohammad Ali can be reached at 571-272-4105. 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.
/J.T.S./Examiner, Art Unit 2119
/MOHAMMAD ALI/Supervisory Patent Examiner, Art Unit 2119
Prosecution Insights