DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 21-30 are pending in the application.
Claims 31-40 are non-elected.
Examiner’s Note: The examiner has cited particular passages including column and line numbers, paragraphs as designated numerically and/or figures as designated numerically in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claims, other passages, paragraphs and figures of any and all cited prior art references may apply as well. It is respectfully requested from the applicant, in preparing an eventual response, to fully consider the context of the passages, paragraphs and figures as taught by the prior art and/or cited by the examiner while including in such consideration the cited prior art references in their entirety as potentially teaching all or part of the claimed invention. MPEP 2141.02 VI: “PRIOR ART MUST BE CONSIDERED IN ITS ENTIRETY, INCLUDING DISCLOSURES THAT TEACH AWAY FROM THE CLAIMS."
Election/Restrictions
Applicant's election with traverse of Group I: claims 21-30 in the reply filed on 08/14/2026 is acknowledged.
Applicant's arguments filed in response to the Restriction Requirement dated June 18, 2026, have been fully considered but are not persuasive. The restriction requirement between Group I and Group II is maintained.
As an initial matter, the Office agrees that Group I and Group II are related as a subcombination and combination, respectively. Under MPEP § 806.05(c), restriction between a combination and a subcombination is proper where: (1) the combination as claimed does not require the particulars of the subcombination as claimed for patentability; and (2) the subcombination has utility by itself or in another materially different combination. In addition, where the inventions are otherwise shown to be distinct, there must be a serious search and/or examination burden if restriction is not required. MPEP §§ 806.05(c), 808.02.
Applicant's argument concerning claims 36 and 38-40 is not persuasive.
Applicant asserts that claim 38 expressly requires "producing an output model" and therefore requires the particulars of Group I claim 21. Applicant similarly asserts that claims 36 and 38-40 recite subject matter corresponding to claims 21, 29, and 30.
The argument overlooks that the test under MPEP § 806.05(c) is whether the combination as claimed requires the particulars of the subcombination as claimed, rather than whether the combination includes subject matter that is generally related to, or overlaps conceptually with, the subject matter of the subcombination.
Claim 21 is directed to a particular method of producing an output model, and specifically requires:
(1) obtaining a defined concrete configuration of the compressor system before production of the compressor system; and
(2) producing the output model using that obtained defined concrete configuration, wherein the output model comprises representations of compressors and peripheral devices and representations of operational relationships among the compressors and peripheral devices from specific points of view and in specific domains.
Claim 38, by contrast, merely recites producing an output model "using the predetermined configuration of the compressors and peripheral devices and the specification for the at least one compressor or peripheral device." Claim 38 does not require the configuration to be obtained before production of the compressor system, does not require the configuration to be a "defined concrete configuration" as recited in claim 21, and does not require the output model to contain the particular representations of operational relationships "from specific points of view and in specific domains" recited in claim 21. Thus, claim 38 does not require all of the particulars of the subcombination of claim 21. The mere fact that both claims recite production or use of an output model does not establish that the combination of Group II requires the specific subcombination of Group I.
Likewise, claim 36 does not incorporate the particulars of claim 21. Claim 36 recites that the predetermined configuration comprises a representation of compressors and peripheral devices and a representation of operational relationships among the compressors and peripheral devices from specific points of view and in specific domains. This limitation is directed to the predetermined configuration used by the control method of Group II; it does not require the particular method of producing an output model recited in claim 21, including obtaining the defined concrete configuration before production of the compressor system and using that configuration to produce the claimed output model.
Similarly, claims 39 and 40 do not require the particulars of claims 29 and 30 as claimed. Claim 29 requires that the one or more derived models be produced based on the output model of claim 21 and that the derived models take into account operational relationships among the individual compressors and peripheral devices. Claim 30 further requires establishing monitoring logic based on the output model and the derived models of claim 29. Claims 39 and 40 recite related functionality in Group II, but do not incorporate the complete limitations of claims 21 and 29, including the particular manner in which the output model is produced and the particular configuration from which that output model is produced.
Accordingly, claims 36 and 38-40 do not establish that the Group II combination requires the Group I subcombination as claimed. At most, those claims demonstrate that certain aspects of the two inventions may be used together. Such overlap does not preclude restriction where the combination does not require the particulars of the separately claimed subcombination.
MPEP § 806.05(c) explains that where the combination claim does not require the specific characteristics of the separately claimed subcombination, the inventions may be distinct if the subcombination has separate utility and a serious search and/or examination burden exists. The MPEP further recognizes that the presence of a more specific combination claim does not necessarily alter a properly established combination/subcombination restriction.
Applicant's argument concerning the serious search/examination burden is also not persuasive. Applicant asserts that the Restriction Requirement merely recited alternative grounds for burden and failed to identify an actual different field of search.
The Office disagrees. MPEP § 808 requires the examiner to state both the reasons why the inventions are distinct and the reasons why a serious search and/or examination burden would result if restriction were not required. MPEP § 808.02 identifies separate classification, separate status in the art, and a different field of search as appropriate ways to demonstrate a serious search burden. Here, Group I and Group II have been identified as directed to different claimed subject matter and are classified in different technological areas, namely CPC F04D27/001 for the output-model-producing subject matter and CPC G05B17/02 for the control and monitoring subject matter. The former is directed to producing a model representing the compressor system and its operational relationships, whereas the latter is directed to receiving configuration and device specifications, storing those data, and controlling and monitoring the compressor system using the stored configuration and specifications.
The respective searches therefore encompass different aspects of the prior art. Searching for references directed to automated generation of an output model of a compressor system based upon a defined configuration is not necessarily coextensive with searching for references directed to automatic acquisition/sign-on of compressor and peripheral-device specifications, storage of those specifications in a control unit, and control of the compressor system according to the stored configuration and specifications. Consequently, the different classifications and the differing substantive focus of the two groups provide an appropriate basis for finding a serious search burden under MPEP § 808.02. MPEP § 808.02 expressly recognizes separate classification as evidence that each invention has attained recognition in the art as a separate subject for inventive effort and a separate field of search.
Applicant's assertion that searching claims 21-30 would necessarily locate all art pertinent to claims 31-40 is not supported by evidence. The fact that the inventions concern the same overall compressor system does not establish that the relevant prior art is coextensive. The restriction inquiry concerns whether the claimed inventions are sufficiently distinct such that separate examination would impose a serious burden, not whether the inventions share a common field of technology.
Separate utility
The second prong of MPEP § 806.05(c) is also satisfied. Group I has utility independently of the particular control-and-monitoring combination recited in Group II. The output model produced according to claims 21-30 may be used as a model for a compressor system in connection with control, monitoring, diagnosis, evaluation, or other compressor-system applications, and is not limited to the particular automatic specification-transfer and storage operations recited in claim 31.
The fact that Group I may also be used with Group II does not negate its separate utility. MPEP § 806.05(c) expressly permits a subcombination to have separate utility "either by itself or in another materially different combination." Accordingly, the record establishes both required aspects of distinctness: (1) the Group II combination does not require the particulars of the Group I subcombination as claimed; and (2) the Group I subcombination has utility separately from the particular combination of Group II. A serious search burden is additionally present because the groups encompass different subject matter and separate fields of search.
Accordingly, Applicant's traversal has been considered but does not overcome the stated grounds for restriction. The restriction requirement between Group I (claims 21-30) and Group II (claims 31-40) is therefore maintained.
The requirement is still deemed proper and is therefore made FINAL.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefore, subject to the conditions and requirements of this title.
Claims 21-30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
Claim 21 recites a mental process and is therefore directed to an abstract idea.
Step 1: The claim is to a method which is a process and therefore is one of the four categories of patent eligible subject matter.
Step 2A, Prong 1: The claim recites the limitation of
"obtaining a defined concrete configuration of the compressor system before production of the compressor system"; and
"producing the output model of the compressor system using the obtained defined concrete configuration."
The resulting output model is further characterized as comprising:
"a representation of compressors and peripheral devices in the compressor system"
and
"a representation of operational relationships among the compressors and peripheral devices from specific points of view and in specific domains."
These limitations amount to obtaining information concerning a defined system configuration and organizing and representing that information in a model. Such activities fall within the mental-process grouping of abstract ideas because the claimed information can be reviewed, organized, and represented by a human without requiring a particular technological implementation.
For example, a person may be provided with a defined configuration of a compressor system, including the compressors, peripheral devices, and their operational relationships, and may produce a corresponding diagram or model identifying those components and relationships from specified viewpoints or within specified domains. The claim does not require that the output model be generated by a particular processor, algorithm, computer architecture, or other technological mechanism.
The recitation that the method is "for producing an output model for use in a control and monitoring unit of a compressor system" does not alter this conclusion. Claim 21 does not require the output model to actually be used by the control and monitoring unit to control or monitor the compressor system. Rather, the claim ends upon production of the output model. Thus, the recited intended use does not meaningfully limit the claimed information-gathering and information-representation activity. Accordingly, claim 21 recites the abstract idea of obtaining information defining a system configuration and generating a representation of that information.
Step 2A, Prong Two: Integration Into a Practical Application
The additional elements of claim 21, considered individually and as an ordered combination, do not integrate the recited abstract idea into a practical application.
The recitation of a "compressor system," "compressors," and "peripheral devices" merely identifies the subject matter about which information is obtained and represented. The claim does not require a physical compressor system to be operated, controlled, monitored, diagnosed, or otherwise physically modified as a result of producing the output model. The claimed configuration is expressly obtained "before production of the compressor system." Thus, the claimed method can be performed during planning, before the physical compressor system exists. The claim therefore does not require an interaction with a physical compressor system that would transform the abstract information-representation activity into a practical application.
Likewise, the recited "specific points of view" and "specific domains" merely specify categories or perspectives according to which the operational relationships are represented. They do not require a particular technological improvement in compressor operation or a particular technological means for producing the model.
The phrase "for use in a control and monitoring unit" is also insufficient to integrate the abstract idea into a practical application because the claim does not recite actually using the model in such a unit. Accordingly, claim 21 is directed to an abstract idea and does not integrate the abstract idea into a practical application.
Step 2B: Significantly More
The additional elements, considered individually and as an ordered combination, do not amount to significantly more than the recited abstract idea.
The claimed "compressor system," "compressors," "peripheral devices," "defined concrete configuration," and "output model" merely identify the environment, information, and representation involved in performing the abstract idea. These elements do not require a particular unconventional computer architecture, specialized processor, improved memory structure, or other technological implementation. Nor does the claim recite an unconventional technique for generating the model. Rather, the claim broadly requires producing a representation of the defined configuration and operational relationships. Accordingly, claim 21 is not patent eligible
Regarding claim 22, claim 22 depends from claim 21 and further recites:
"storing the produced output model in a memory operatively connected to the control and monitoring unit." The additional limitation of storing information in memory does not integrate the abstract idea into a practical application and does not amount to significantly more than the abstract idea. Storing information in a memory is a conventional computer function that merely permits the information representation to be retained for subsequent use. The claim does not recite an improvement to the memory itself or an unconventional technique for storing the model. Accordingly, claim 22 is also directed to the same abstract idea and lacks an additional element or ordered combination that amounts to significantly more. Claim 22 is not patent eligible.
Regarding claim 23, the claim recites that "the control unit uses the stored output model to control the compressor system according to the stored output model." Although this limitation introduces use of the model in controlling the compressor system, the claimed control operation merely applies the previously generated information representation to the operation of the compressor system according to the information contained in the model.
The claim does not identify any particular improvement to compressor control, any particular control algorithm, or any particular technological mechanism by which the output model improves operation of the compressor system. The recited control operation therefore constitutes application of the abstract model to its intended field of use rather than an integration of the abstract idea into a particular technological improvement. Accordingly, claim 23 is not patent eligible.
Regarding claim 24, the claim further specifies that the stored output model is used to:
"control the compressor system, to monitor the compressor system, to diagnose the compressor system, to evaluate the compressor system, or combinations thereof." These additional functions merely identify intended uses of the information represented by the output model. Controlling, monitoring, diagnosing, and evaluating a system using information concerning that system do not, without more, establish a technological improvement to the compressor system or to the claimed modeling technique. The claim does not specify how the model technically improves any of these operations. Accordingly, claim 24 is not patent eligible.
Regarding claims 25 and 26, claim 25 further recites:
"establishing a monitoring logic using the output model" and using the monitoring logic to control the compressor system. Claim 26 further specifies that establishing the monitoring logic may be performed "automatically." These limitations do not alter the eligibility analysis. Establishing monitoring logic based on information represented in a model constitutes further processing and use of information. The term "automatically" merely indicates that the operation may be performed without manual intervention and does not itself identify a particular technological improvement or unconventional implementation. The claims do not recite a particular improved control technique, processor architecture, or other technological mechanism that produces a technical improvement in the compressor system. Accordingly, claim 25 and claim 26 are not patent eligible.
Regarding claim 27, the claim specifies that the particular viewpoints and domains include: "compressed air operational relationships, heat-recovery-related operational relationships, cooling-water-circuit-related operational relationships, or power-supply-related operational relationships." These limitations merely identify particular categories of information represented by the output model. Specifying additional subject matter about which information is collected or represented does not remove the claim from the abstract-idea exception. The claim continues to require obtaining and representing information concerning operational relationships rather than requiring a particular technological improvement to the compressor system. Accordingly, claim 27 is not patent eligible.
Regarding claim 28, the claim specifies that the output model may be produced:
"after production of the compressor system when the output model is to be used in the control system of the compressor system." This limitation merely specifies when the model is generated relative to production of the compressor system. Changing the temporal point at which an abstract information-representation process is performed does not integrate that process into a practical application. Accordingly, claim 28 is not patent eligible.
Regarding claim 29, the claim 29 further recites:
"producing one or more derived models based on the output model, the derived models taking into account operational relationships among the individual compressors and the peripheral devices." The production of derived models remains an information-processing activity directed to representing and organizing information concerning relationships among components. The claim does not recite a particular technological mechanism for producing the derived models or a particular technological improvement resulting from them. Accordingly, claim 29 is not patent eligible.
Regarding claim 30, the claim 30 further recites:
"establishing a monitoring logic based on the output model and the derived models" where the models take into account operational relationships among the individual compressors and peripheral devices. This limitation further processes the information represented by the models to establish monitoring logic. Such additional information processing does not, without a recited technological improvement, transform the underlying abstract idea into patent-eligible subject matter. Accordingly, claim 30 is not patent eligible.
In conclusion
For the foregoing reasons, claims 21–30 are rejected under 35 U.S.C. § 101 as being directed to an abstract idea without additional elements, considered individually or as an ordered combination, that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 21-25 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over McKim et al. US Pub. No. 2009/0292514 (“McKim”) in view of Blevins et al. US Pub. No. 2007/0174225 (“Blevins”).
Regarding claim 21, McKim teaches a method for producing an output model for use in a control and monitoring unit of a compressor system [See Abstract, para. 0002, 0006, 0160, 0180; Fig. 4A], the method comprising:
Obtaining a defined concrete configuration of the compressor system before production of the compressor system [See para. 0134-0135, 0146-0153, 160; Figs. 8-14];
(In other words, McKim teaches obtaining preliminary smart piping and instrumentation diagrams (P&IDs) from an engineering, procurement, and construction contractor. The smart P&ID contain structured data objects defining the equipment, instruments, piping connections, process streams, control interfaces, equipment properties, and design operating conditions of a particular plant configuration).
[0152] 3. The designer receives preliminary smart P&IDs from EPC.
[0160] The following summarizes features of an exemplary automated (computerized) translation framework for generating process simulation models. The function of such translation framework (process simulation model generator) is to enable a controls application engineer to checkout/test the accuracy and validity of their control design prior to actually building a physical plant process that incorporates the simulated plant/process design.
and producing the output model of the compressor system using the obtained defined concrete configuration, [See para. 0135-0145, 0151-0157; Figs. 9-12]
(in other words, McKim teaches executing an automated translation framework on the object data contained in the preliminary smart P&ID files. The translator maps the source P&ID objects to corresponding process simulation model objects, creates the process model, initialized the model objects using other plant design data, and creates and connects simulated sensors and controllers according to the P&ID markings and control-system I/O tag conventions.)
McKim further teaches that the automatic model generator:
[0162] (1) Plant items/equipment of interest are translated from SP P&ID objects to corresponding process simulation model object(s);
[0163] (2) The pipe-run (piping) connections between plant items are translated using process streams;
[0164] (3) The graphical layout of the SP P&ID (locations of the equipment as well as the pipe-run segments) is retained as much as possible when translated to a simulation model view;
[0165] (4) Each SP P&ID drawing is translated to a simulation model flowsheet (one model flowsheet diagram per P&ID drawing) in the simulation;
[0166] (5) Supports automatically updating the process simulation model instances to entries within an I/O cross-referencing table using tag data from the control instrumentation database.
the output model comprising a representation of compressors and peripheral devices in the compressor system [See para. 0181, 0170-0174, 0134-0145, 0153-0166; Figs. 10A-10C, 13 and 16]
(in other words, McKim teaches that the process model generator recognizes the equipment units depicted in the P&ID and creates corresponding equipment model objects. McKim expressly identifies a compressor, heat exchanger, flash drum, and distillation column as examples of recognized equipment units and teaches configuring and connecting those units according to the P&ID. McKim further teaches a P&ID-to-model mapping file that maps equipment codes to processes-model classes, including “Drum,” “HeatExchanger,” “ScrewCompressor,” and “FlangdNozzle” [para. 0170-0174]. McKim also teaches representing peripheral devices including pipes, valves, vessels, instrument, sensors, transmitters, nozzles, and process controllers and connecting the peripheral device model objects to the appropriate equipment parameters and control system I/O points [0134-0145, 0153-0166; Figs. 10A-10C, 13 and 16]).
and a representation of operational relationship among the compressors and peripheral devices [para. 0134-0145, 0162-0166];
(McKim further teaches that the equipment units, including compressors and heat exchangers, are configure and connected according to the P&ID withing the simulator system and that cause-and-effect models represent the interactions among multiple control loops and equipment parameters [para. 0180-0187; Fig. 18-19])
McKim does not expressly teaches that the operational relationships among the compressors and peripheral devices are represented from specific points of view and in specific domains.
Blevins teaches a process-control modeling system that represents physical equipment using smart process objects. The smart process objects are connected by connection elements representing pipes, conduits, power cables, conveyors, process streams and communications between the modeled devices [para. 0031-0032, 0038-0040; Fig. 2-3].
[0076] Generally speaking, when the configuration engineer creates a process module or a graphic display, the configuration application 38 automatically stores the smart process objects, along with the connections therebetween, in a database. This database can then be used to create other process modules and graphic displays which may, for example, provide different views using one or more of the same smart process objects. As such, when creating the second view, the configuration engineer can simply reference the smart process object, as already created and stored within the database, and any methods, etc. stored therewith to place that smart process object in the second view. In this manner, the database can be populated as the process control modules and graphic displays are created and the database can be used at any time to create and execute other views, modules, and graphic displays using smart process objects which already exist within the process flow database. Using such a database, each smart process object within the database may support or be used in process modules and referenced in multiple graphic displays. As will also be understood, the process modules may be constructed by building displays for these modules and then specifying flow algorithms to be used in or associated with process modules. Of course, individual process modules may be spread across and executed by different computers and process modules may be communicatively connected to one other to operate in conjunction with each other, either on the same or on different computers. When this is done, input and output streams will be externally referenced to tie process modules together.
(Blevins teaches automatically storing the smart process objects and the connections between the objects in a database. The stored objects and connections are then used to create other process modules and graphical displays that provide different views using one or more of the same smart process objects).
Blevins also teaches representing and analyzing the equipment and its operational relationships in specific operational domains. In particular, Blevins teaches process modules containing algorithms configured to perform mass-balance calculations, heat-balance calculations, flow calculations, flow routing, flow-efficiency analysis, flow optimization, energy-stream analysis, and economic calculations. [See para. 0077-0081]
Thus, Blevins teaches using selected views and process modules to represent the equipment and operational relationships relevant to a particular technical domain, including a fluid-flow domain, thermal or heat-recovery domain, energy domain, electrical-power domain, efficiency domain, or control domain. In other words, Blevins teaches that the operational relationships among the equipment are represented from specific points of view and in specific domains.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify the output model of McKim with the different equipment views and domain-specific process modules of Blevins. The motivation for doing so would have been to allow a control engineer or operator to select and analyze the compressors, peripheral devices, and operational relationships relevant to a particular control, monitoring, or engineering task, such as compressed-air flow, cooling-water flow, heat recovery, energy efficiency, or electrical-power supply, while reusing the common equipment objects and connections already generated from McKim’s P&ID. The modification would have predictably improved visualization and analysis of the complex compressor-system configuration and avoided recreating separate equipment objects and connections for each operational domain, because Blevins expressly teaches generating different views and process modules from the same stored process objects and their connections.
Regarding claim 22, McKim teaches storing the produced output model in a memory operatively connected to the control and monitoring unit [See para. 0083-0090, 0142-0145, 0145; Fig. 4A-4B – McKim teaches storing the produced output model in the memory of computer 410, which hosts the process-simulation model and the associated virtual control-system definition and is therefore operatively connected to the control and monitoring unit].
Regarding claim 23, McKim teaches wherein the control unit uses the stored output model to control the compressor system according to the stored output model.
McKim teaches connecting the generated process-simulation-model objects to the I/O components of a virtual process-control system. The resulting platform combines the virtual control system, which executes the actual control logic in a virtual runtime environment, with the stored process model. The process model receives control-system outputs and returns modeled process values to the control-system inputs so that the control logic operates according to the equipment, connections, parameters, and physical response behavior represented in the stored model. [para. 0083-0090; figs. 4A-4B]
McKim further teaches connecting outputs of the dynamic process-simulation model to I/O blocks of a virtual or actual control system for verification of the process-control-system logic and the plant-equipment design. [para. 0180]
McKim, however, does not expressly teach that the control unit uses the stored output model to control the actual compressor system during operation, rather than using the model principally to simulate the compressor system and verify the control logic.
Blevins teaches a process-control system having controllers that execute control modules to control field devices and other physical equipment in a process plant. Blevins further teaches process modules formed from interconnected smart process objects representing the physical devices, streams, and operational relationships of the process plant. [para. 0024-0032, 0038-0040]
Blevins teaches that the simulation algorithms associated with the process modules may access parameters from the control strategy, including control modules downloaded to the controllers and field devices, and may provide data or information to those control modules. [para. 0077]
Blevins further teaches that the process modules may reference, and be referenced by, controller modules to use the parameters, control strategies, and other information associated with the controller modules. [para. 0080]
The process modules are made of processing elements, streams, and their associated connections and correspond to the graphical objects representing the physical plant equipment. [para. 0081]. Thus, Blevins teaches using the stored representation of the equipment and its operational relationships in communication with the controller modules that control the corresponding physical process equipment.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify the control-system arrangement of McKim such that the control unit uses the stored compressor-system output model to control the corresponding physical compressor system, as taught by Blevins. The motivation for doing so would have been to reuse the equipment objects, process streams, operating parameters, and control-system I/O relationships already established in McKim’s stored model when implementing the control strategy in the actual controller, thereby maintaining consistency between the modeled compressor-system configuration and the physical compressor-system control configuration. The modification would also have reduced duplicate configuration effort and errors because Blevins teaches communication between the stored process modules and the controller modules, including providing model information to the control modules executed by the controllers and field devices.
Regarding claim 24, McKim further teaches wherein the control unit uses the stored output model to control the compressor system, to monitor the compressor system, to diagnose the compressor system, to evaluate the compressor system, or combinations thereof [para. 0083-0090, 0160, 0180; figs. 4A-4B - McKim teaches using the generated process-simulation model to evaluate the control-system configuration and the modeled plant process. Specifically, the generated process model is connected to I/O blocks of a virtual or actual control system for personnel training and verification of the process-control-system logic, configuration, and plant-equipment design.
Regarding claim 25, McKim teaches automatically generating a process simulation model from plant-design resources, such as P&IDs, and connecting the generated model to the input/output points of a process control system. McKim, para. 0048–0053, 0057–0059, 0075–0077, 0103–0105, and Figs. 4A–4B and 8–10C.
McKim does not expressly teach establishing a monitoring logic using the output model; and the control unit uses the monitoring logic to control the compressor system.
Blevins teaches establishing monitoring logic using a model of a process system. In particular, Blevins teaches a process module comprising interconnected process objects that represent physical plant equipment and their operational connections. An expert module is integrated with the process module and includes expert rules associated with the process module. The expert rules reference parameter data of the modeled equipment and are applied by an expert engine to detect abnormal situations associated with the modeled process unit. [para. 0108–0117, 0120–0128, Fig. 10, and claim 17].
Blevins further teaches that the expert engine applies the rules to process or simulation data generated or obtained from the process module. The monitored data may include process variables, alarms, operating modes, setpoint changes, historical values, predicted values, and data associated with other process modules and equipment [para. 0113–0117]. Accordingly, Blevins’s expert rules constitute “monitoring logic,” and the rules are established using the equipment representations, parameters, and operational relationships contained in the process model.
Blevins also teaches using the monitoring logic to control the modeled process system. Specifically, upon detecting an applicable condition, the expert rules may perform actions including:
“overwriting a control signal value, overwriting a set point value, modifying an equipment setting, shutting down equipment, etc.” [para. 0118]. The expert engine uses the model-based monitoring rules to change control signals, setpoints, or equipment settings and thereby control the process equipment [para. 0113-0114]. Blevins additionally claims an expert module containing rules associated with the process module and adapted to detect abnormal situations during operation of the process plant. [claims 11 and 17–20 of Blevins]. Therefore, McKim in view of Blevins teaches establishing a monitoring logic using the output model; and the control unit uses the monitoring logic to control the compressor system.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify McKim’s model-based compressor control system to include the expert monitoring rules taught by Blevins. One would have been motivated to use the equipment objects, connections, operating parameters, and simulation data already available in McKim’s output model to establish monitoring rules capable of detecting abnormal operating conditions and initiating appropriate control actions. Blevins expressly explains that integrating the expert module with the process module makes the expert system easier to configure by automatically making the model’s data available to the expert module, thereby avoiding the time-consuming manual identification and configuration of the required process data.
Regarding claim 28, McKim teaches that the transformations used to generate the process-simulation model may be rerun to accommodate plant-design changes and that simulation testing or analysis may result in changes that are transferred back to the plant-design databases. [para. 0140-0141]
McKim does not expressly teach producing the output model after production of the compressor system when the output model is to be used in the control system of the compressor system.
Matheny teaches producing a configuration model after production or installation of the physical industrial system when the configuration model is to be used by the control system.
Matheny teaches that a control-system engineer may create a new configuration database 84 in response to a new installation of component control system 78 at a factory or other site having PLCs controlling the physical control modules. [Matheny, ¶ 0065]
Matheny teaches that configuration database 84 may be initially populated on client computer 86 located within the installed plant or remotely from the plant. The database is populated from the P&IDs with information relating to the installed physical components, including valves, pumps, and instruments. After the database is populated, database 84 and instructions 90 are transferred to the PLCs, which use the configuration database and instructions to operate plant 10. [Matheny, ¶¶ 0066-0067; fig. 5]
Matheny further teaches initially populating and modifying the configuration database while the production lines controlled by the controller and database are still operating to produce products. [Matheny, ¶ 0007]
Thus, Matheny teaches producing or updating the configuration model after production and installation of the physical system when the resulting model is to be used by the control system to operate the system.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify the model-generation method of McKim and Blevins to permit the output model to be produced or updated after production of the compressor system, as taught by Matheny. The motivation for doing so would have been to configure the control system according to the compressors and peripheral devices actually installed, to account for installation-specific changes or later modifications, and to permit the resulting output model to be transferred to and used by the control unit to operate the physical compressor system. The modification would have predictably maintained correspondence between the stored output model and the as-built compressor-system configuration.
Regarding claim 29, McKim teaches the method including producing an output model representing the equipment of a compressor system and the operational relationships among the equipment. In particular, McKim automatically generates a plant-process simulation model from plant-design information, such as P&IDs, wherein the model includes process equipment, connections, process streams, and cause-and-effect relationships [para. 0048–0053, 0057–0059, 0075–0077, 0103–0105, and Figs. 8–10C].
McKim does not expressly teach producing one or more derived models based on the output model, wherein the derived models take into account operational relationships among the individual compressors and peripheral devices.
Blevins teaches producing one or more additional or derived models based on an existing representation of a process system. Specifically, Blevins teaches that a configuration application stores smart process objects, together with the connections between the objects, in a database, and that:
“This database can then be used to create other process modules and graphic displays which may, for example, provide different views using one or more of the same smart process objects.”
Blevins further teaches that the database can be used to create and execute “other views, modules, and graphic displays” using the previously created smart process objects [para. 0084–0086]. Blevins also teaches that a process module may be automatically generated from a process graphic display, or that a graphic display may be automatically generated from the process module [para. 0091–0093].
The process modules produced by Blevins take into account operational relationships among the represented equipment because the modules contain interconnected process objects representing corresponding physical plant entities, including valves, tanks, pumps, piping elements, and streams. The process modules also contain flow or simulation algorithms that operate across the interconnected objects to perform mass-balance, heat-balance, flow-routing, efficiency, and optimization calculations [See para. 0086–0091, 0113–0115, Fig. 10; claim 11]. Thus, Blevins’s additional process modules and views constitute producing one or more derived models based on the output model, wherein the derived models take into account operational relationships among the individual equipment and peripheral devices.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify McKim’s automatically generated output model to produce the additional process modules and views taught by Blevins. One would have been motivated to do so to reuse the equipment objects and connections already contained in McKim’s model to provide different application-specific representations, simulations, and operational analyses without separately recreating the compressor-system configuration. Such a modification would predictably reduce duplicated configuration work, maintain consistency between the models, and permit different operational aspects of the compressor system to be analyzed using the same underlying equipment and connection data.
Regarding claim 30, the combination of McKim and Blevins teaches the method of claim 29, as discussed above.
Blevins further teaches establishing monitoring logic based on the output model and the derived models. In particular, Blevins teaches integrating an expert module with a process module representing interconnected plant equipment. The expert module contains expert rules configured to detect and manage abnormal situations associated with the physical elements represented by the process module [See para. 0108–0113 and Fig. 10].
The expert rules are based on information from the modeled equipment and its operational relationships because the expert engine applies the rules to data associated with the process module, analyzes process or simulation data generated by the process module, obtains variables, alarms, parameters, operating modes, historical values, and predicted values from the interconnected process objects and may analyze data from other process modules and equipment not depicted in the particular process module [See para. 0113–0117].
The resulting rules constitute monitoring logic because they detect abnormal operating conditions and initiate responsive actions, including generating an alarm, displaying a notification, screening related alarms, changing a control signal or setpoint, modifying an equipment setting, or shutting down equipment [para. 110–113]. Blevins expressly claims configuring an expert module having “a set of expert rules associated with the process module” that reference parameter data of the process module and detect abnormal situations associated with the modeled plant unit [See claim 17 pf Blevins]. Blevins also teaches establishing the monitoring logic based on both the graphic representation and the derived process module. Configuration of the expert module may be performed with reference to the process graphic, while the resulting expert rules are associated with and reference parameters of the corresponding process module [See para. 0120–0128]. Thus, the process graphic corresponds to the output model, the automatically generated process module corresponds to the derived model, and the associated expert rules correspond to monitoring logic based on those models. In other words, Blevins teaches establishing a monitoring logic based on the output model and the derived models which take into account operational relationships among the individual equipment and the peripheral devices.
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to provide the McKim establishing a monitoring logic based on the output model and the derived models which take into account operational relationships among the individual equipment and the peripheral devices taught by Blevins. The ordinary skill in the art would have been motivated to use the equipment objects, connections, simulation parameters, and operational relationships already represented in the models as inputs to monitoring rules so that abnormal operating conditions could be detected and appropriate alarms or corrective actions generated. Blevins expressly identifies easier expert-system configuration and avoiding the time-consuming manual identification and configuration of plant data as benefits of integrating the expert rules with the process model. The combination therefore would have constituted the predictable use of Blevins’s known model-based monitoring technique with McKim’s automatically generated compressor-system model to obtain model-consistent monitoring and abnormal-condition detection.
Claims 26, 28 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over McKim/Blevins as applied to claim 21-25 above, and further in view of Matheny et al. US Pub. No. 2015/0153725 (“Matheny”).
Regarding claim 26, McKim/Blevins does not expressly teach establishing the monitoring logic further comprises automatically establishing the monitoring logic.
Blevins teaches process modules formed from interconnected smart process objects representing physical devices and the operational relationships among those devices. Blevins teaches that a process module may be automatically generated from a graphical display and that the functionality of the automatically generated process module is determined by the process-graphic elements. The process module corresponds to the equipment objects, streams, and connections represented in the graphical display and may include mass or energy streams used by the simulation function blocks [para. 0079-0081]. Blevins further teaches that the configuration application automatically stores the smart process objects and their connections in a database and uses the stored objects and connections to create and execute additional process modules and graphical views [para. 0076]. Blevins also teaches that the automatically generated process modules may be integrated with control modules and expert modules. The expert modules apply rules to process data and simulation data obtained from the process modules to detect and mitigate abnormal operating situations [para. 0085-0089, 0100-0104]. Blevins further teaches that using smart process objects to create integrated process modules and graphical displays enables execution engine 48 to automatically detect leaks, produce smart alarms with minimal user-configuration activity, track flow and mass balances, track process losses, and provide higher-level plant diagnostics. [para. 0089]
Thus, Blevins teaches automatically generating a process module from modeled equipment objects and their relationships and using the automatically generated module to provide monitoring and diagnostic functions.
Matheny further teaches automatically establishing monitoring and interlock logic from an output model containing representations of physical equipment and operational relationships. Matheny teaches that configuration database 84 stores equipment-module definitions, control-module identifiers, instrument identifiers, physical connections, acquire relationships, interlock relationships, triggering events, and trigger values. The PLC instructions use this information to monitor the physical equipment and control operation of the corresponding equipment modules [para. 0065-0067, 0104, and 0106-0107]. Matheny teaches automatically populating database 84 with routing and interlock information after a route is selected. Specifically, client 86 automatically populates the equipment-module definition table with the source and destination, automatically populates acquire table 256 with the valves to be acquired, and automatically populates interlock table 258 with the valves to be interlocked [para. 0182]. Matheny further teaches that client 86 determines which valves should be interlocked by analyzing which valves feed into or out of the acquired valves through the pipes represented in the configuration database. The system excludes valves already acquired and automatically adds the remaining connected valves to interlock table 258 [para. 0182]. The automatically determined interlock relationships constitute monitoring logic because the PLC subsequently monitors the status and availability of the identified components and uses the interlock information to determine whether the equipment module may operate. [para. 107, 0112-0118, and 0182-0187]. Matheny also teaches automatically determining whether an equipment component is unavailable or conflicts with another operating equipment module. In response, component control system 78 automatically searches for an alternative route and may automatically implement the alternative route using available components. [para. 0183-0187]. In summary, Matheny teaches establishing the monitoring logic further comprises automatically establishing the monitoring logic.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify the model-based monitoring arrangement of McKim and Blevins to automatically establish the monitoring logic using the equipment connections, routing information, acquire relationships, and interlock relationships represented in the output model, as taught by Matheny. The motivation for doing so would have been to reduce the manual programming required to configure monitoring and interlock logic and to ensure that the monitoring logic accurately corresponded to the physical equipment and operational relationships already represented in the output model. The modification would have predictably produced monitoring logic identifying which components should be monitored, acquired, or interlocked during operation and would have enabled the controller to automatically detect equipment conflicts and control the system using an available operational route.
Regarding claim 28, McKim teaches that the transformations used to generate the process-simulation model may be rerun to accommodate plant-design changes and that simulation testing or analysis may result in changes that are transferred back to the plant-design databases. [para. 0140-0141]
McKim/Blevins does not expressly teach producing the output model after production of the compressor system when the output model is to be used in the control system of the compressor system.
Matheny teaches producing a configuration model after production or installation of the physical industrial system when the configuration model is to be used by the control system.
Matheny teaches that a control-system engineer may create a new configuration database 84 in response to a new installation of component control system 78 at a factory or other site having PLCs controlling the physical control modules [para. 065]. Matheny teaches that configuration database 84 may be initially populated on client computer 86 located within the installed plant or remotely from the plant. The database is populated from the P&IDs with information relating to the installed physical components, including valves, pumps, and instruments. After the database is populated, database 84 and instructions 90 are transferred to the PLCs, which use the configuration database and instructions to operate plant 10 [para. 0066-0067; fig. 5]. Matheny further teaches initially populating and modifying the configuration database while the production lines controlled by the controller and database are still operating to produce products [para. 0007].
Thus, Matheny teaches producing or updating the configuration model after production and installation of the physical system when the resulting model is to be used by the control system to operate the system. In the words, Matheny teaches producing the output model after production of the system when the output model is to be used in the control system of the compressor system.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify the model-generation method of McKim and Blevins to permit the output model to be produced or updated after production of the compressor system, as taught by Matheny. The motivation for doing so would have been to configure the control system according to the compressors and peripheral devices actually installed, to account for installation-specific changes or later modifications, and to permit the resulting output model to be transferred to and used by the control unit to operate the physical compressor system. The modification would have predictably maintained correspondence between the stored output model and the as-built compressor-system configuration.
Claims 27 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over McKim/Blevins as applied to claim 21 above, and further in view of Lefebvre et al. US Pub. No. 2009/0246036 (“Lefebvre”).
Regarding claim 27, McKim in view of Blevins teaches the method of claim 21, as discussed above.
Blevins teaches representing operational relationships from specific points of view and in specific domains. Blevins teaches that the same process module may support different views for selected sets of equipment. Blevins further teaches View 1, View 2, and View 3 for creating different views of a process module or graphical display using some of the same underlying smart process objects [para. 0074-0075; fig. 3]. Blevins teaches that configuration application 38 automatically stores the smart process objects and the connections between the objects in a database. The stored objects and connections may then be used to create additional process modules and graphical displays providing different views using one or more of the same smart process objects[para. 0076]. Blevins also teaches process modules directed to specific operational domains, including mass balancing, heat balancing, flow calculations, flow routing, flow efficiency, flow optimization, energy-stream analysis, and economic calculations [para. 0077-0081].
McKim and Blevins do not expressly teach wherein the specific points of view and the specific domains comprise compressed air operational relationships, heat-recovery-related operational relationships, cooling-water-circuit-related operational relationships, or power-supply-related operational relationships.
Lefebvre teaches wherein the specific points of view and the specific domains comprise compressed air operational relationships.
Lefebvre teaches a compressed-air unit comprising one or more compressed-air networks and multiple communicating controllers that control components forming part of the compressed-air networks. [See Abstract; para. 0001-0003 and 0012-0015]. Lefebvre teaches a compressed-air unit 1 comprising communication network 2 and multiple branches containing
a temperature sensor 7, a cooling tower 8, compressors 10, 11, and 14, dryers 12 and 15, a controllable valve 16, a pressure sensor 17, and a flow-rate sensor 18 [See 0019-0023; Fig. 1]. Lefebvre teaches that controller 9 directly controls compressors 10 and 11 and indirectly controls dryer 12 connected to compressor 10. Controller 13 controls compressor 14, dryer 15, and valve 16 and receives measurements from pressure sensor 17 [See para. 0021-0023]. Lefebvre further teaches that the different components of compressed-air unit 1 may be interconnected in different arrangements and may form a single compressed-air network or different compressed-air networks. [See para. 0024-0025]. Lefebvre teaches operational relationships among the compressors and peripheral devices. Specifically, each controller determines the operational condition of the components directly or indirectly connected to it. Controller 6 determines the operational condition of cooling tower 8; controller 9 determines the operational condition of compressors 10 and 11 and dryer 12; and controller 13 determines the operational condition of compressor 14, dryer 15, and valve 16 [See par. 0030-0031]. The controllers mutually communicate through communication network 2. Each controller compares information received from the other controllers and determines operating points for the connected components based in part on measurements from temperature sensor 7, pressure sensor 17, and flow-rate sensor 18 [See para. 0032-0034]. Lefebvre further teaches that controller 13 calculates a required flow rate of compressed gas to be supplied to the compressed-air network based on the pressure measured by pressure sensor 17. Controller 13 determines the appropriate allocation of compressed-air production between compressor 14 and the combination of compressors 10 and 11 [See para. 0035-0036]. Controller 13 controls compressor 14 and communicates a calculated desired value to controller 9. Controller 9 controls compressors 10 and 11 so that compressors 10, 11, and 14 collectively provide the required pressure in the compressed-air unit according to a distribution scheme based on energy consumption, maintenance, or equipment life [ See para. 0036-0038]
Lefebvre additionally teaches controlling compressed-air components based on operational parameters including pressure, flow rate, dew point, air quality, temperature, equipment operating condition, energy consumption, and maintenance condition [See para. 0043-0050].
Lefebvre identifies components of the compressed-air domain as including:
compressed-air sources, including screw compressors and piston compressors;
compressed-air users;
compressed-air-processing devices, including dryers, heat exchangers, filters, and moisture and oil separators; and
compressed-air valves [See para. 0061-0065]
Lefebvre further teaches that these components are physically interconnected by pipes and connected to respective controllers for monitoring and control [See para. 0065-0067]
Thus, Lefebvre teaches the specific points of view and the specific domains comprise compressed air operational relationships, heat-recovery-related operational relationships, cooling-water-circuit-related operational relationships, or power-supply-related operational relationships. In other words, Lefebvre teaches wherein the specific points of view and the specific domains comprise compressed air operational relationships, heat-recovery-related operational relationships, cooling-water-circuit-related operational relationships, or power-supply-related operational relationships.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify the different equipment views and domain-specific process modules of the McKim-Blevins output model to represent the compressed-air operational relationships as discussed above of Lefebvre. The motivation for doing so would have been to enable the control and monitoring unit to identify and analyze the compressors, dryers, valves, sensors, cooling equipment, piping connections, operating conditions, and coordinated compressor-production relationships relevant to the compressed-air domain. The modification would have predictably allowed McKim’s P&ID-generated equipment model to provide a compressed-air-specific view for controlling and monitoring the compressed-air network according to pressure, flow, equipment availability, air-quality, and energy requirements.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Patent no. 6,643,555 to Eller et al. teach an invention is directed to an apparatus for generating an application for a control system wherein a control process is defined as a physical model and a topological model. The apparatus comprises an analyzer for examining the physical model and the topological model to ensure operable cooperation between the physical and topological models; and a generator for receiving the physical model and the topological model. The models are input into the generator wherein the application is to be generated and executed on the control system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT HUY TRAN whose telephone number is (571)272-7210. The examiner can normally be reached M-F 7:00-4:00.
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, Kamini S Shah can be reached at 571-272-2279. 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.
VINCENT H TRAN
Primary Examiner
Art Unit 2115
/VINCENT H TRAN/Primary Examiner, Art Unit 2115
Prosecution Insights