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 .
This Action is FINAL and is in response to the claims filed August 13, 2026. Claims 1, 3-13, and 15-20 are currently pending, of which claims 1, 4, 10, 12, 13, and 15-20 are currently amended. Claims 2 and 14 have been cancelled.
Response to Arguments
Rejections Under 35 USC 112
Applicant has amended the claims at issue and the previous rejections under 35 USC 112(b) have therefore been withdrawn. However, in light of the claim amendments, new rejections have been made, as detailed below.
Rejections Under 35 USC 101
Applicant has amended the claims at issue and the previous rejections under 35 USC 101 have therefore been withdrawn.
Prior Art Rejections
Applicant’s arguments regarding the previously cited art have been fully considered and are not persuasive. Specifically, Applicant has cancelled representative claim 2 and rolled that language into independent claim 1 and argues that Kocherry is incorrectly being treated “as if it were the claimed creation and reconciliation of a virtualized DCS deployment from a declarative and/or imperative deployment description” and that “Bawcom is applied only for general infrastructure-as-code concepts and deployment/topology descriptions. See Remarks 9-10.
Examiner respectfully disagrees with both Applicant’s arguments and characterization of the cited art. Firstly, the rejection is one of obviousness under 35 U.S.C. §103 and in response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). As Applicant correctly notes, Bawcom has been cited for the explicit teaching of declarative/imperative descriptions. However, Applicant appears to ignore the fact that Kocherry teaches the remaining limitations of the claims.
Declarative and imperative descriptions are merely high level programming paradigms. Kocherry is also clear that the topology information is retrieved from the topology and model generation engine, including instructions to execute said engine and its respective topologies. It would certainly be obvious to one of ordinary skill in the art that one of these generic programming paradigms can use to relationships retrieved in the topologies, especially when those topologies define relationships. See Kocherry paras. [0031-36].
Finally, Applicant argues that the DCS deployment of the claims are different from Kocherry’s teachings. Specifically, Applicant argues that Kocherry “concerns whether a test case passes” and the present claims concern “whether the deployed virtual DCS topology and instances match a desired deployment state derived from the deployment description.” See Remarks 10. Examiner again respectfully disagrees with Applicant’s arguments, as well as characterization of the prior art and claim language. Applicant’s claim language merely calls for comparing an actual state to an intended state of the DCS. Kocherry explicitly compares “the outcome of the execution of test cases with the expected outcomes of the execution”, where the test case can pass/fail based on differences from expected outcomes. New test cases arise with new equipment. The topology is updated with new equipment, and those are compared to expected outcomes. Expected outcomes are the intended state of the DCS. Regardless of whether it is a test case or called something different, Kocherry still, under the broadest reasonable interpretation of the claim, compares the state of the DCS obtained by creating virtual instances of the devices of the DCS and their connections to said intended state. See Kocherry paras. [0047], [0056], [0064], and [0084].
It is for at least these reasons, and the reasons cited below, that the claims remain rejected in this Action.
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.
Claim 13 and 15-20 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 13 recites “cause the one or more computers and/or compute instances to perform a method…” and there is insufficient antecedent basis for this limitation of the claim. Specifically, “the one or more computers and/or compute instances” are no longer introduced prior to this language (emphasis added). Applicant should amend the claims to be tied to the processor that was introduced in the amendments.
Claims 15-20 are rejected based on their dependency from above-rejected claim 13.
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in the European Patent Office on September 21, 2022. It is noted, however, that applicant has not filed a certified copy of the EPO application as required by 37 CFR 1.55. Examiner further notes that document retrieval requests have failed, as mailed on February 21, 2024 and November 7, 2024.
Examiner’s Note
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references 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 claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
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 (i.e., changing from AIA to pre-AIA ) 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.
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, 3-13, and 15-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kocherry et al. (WO 2017/115162; included on IDS filed September 21, 2023; hereinafter “Kocherry”) and further in view of Bawcom (U.S. 10,872,029 B1).
As per claim 1, Kocherry teaches a computer-implemented method for creating a virtual deployment of a distributed control system (DCS) for a given industrial process (See Kocherry paras. [0032-33]), comprising the steps of:
providing a topology of the assets executing the industrial process as well as control logic for controlling these assets (See Kocherry Fig. 3 and paras. [0017-19]: process topology with connected equipment in industrial plant);
providing at least one I/O simulator that is configured to supply, to the DCS, sensor and/or actor data that is realistic in the context of the given industrial process (See Kocherry paras. [0047-49]: process simulation models for communication between the real production process and industrial control devices);
determining, based at least in part on said topology of the assets and on the control logic, a topology of devices that form part of the DCS (See Kocherry paras. [0047] and [0084]: topology with identified control elements in the industrial plant, including control logics for the different industrial control devices);
creating, based at least in part on [the declarative and/or imperative description], virtual instances of the devices of the DCS and their connections in a chosen environment, wherein at least one device of the DCS is connected to at least one I/O simulator, so that the sought virtual deployment of the DCS results (See Kocherry paras. [0045-48], [0054-56], and [0094-95]: modeled instances of the relationships and communication between real processes and industrial control devices. This includes changing the topology when new equipment is added);
determining, from the declarative and/or imperative description, a representation of an intended state of the DCS; comparing the state of the DCS obtained by creating virtual instances of the devices of the DCS and their connections to said intended state; and in response to determining that the state of the DCS differs from the intended state of the DCS, creating, modifying and/or deleting virtual instances of devices of the DCS and their connections with the goal of bringing the state of the DCS towards its intended state (See Kocherry paras. [0056] and [0064]: “comparing the outcome of the execution of test cases with the expected outcomes of the execution”, where the test case can pass/fail based on differences from expected outcomes. New test cases arise with new equipment).
However, while Kocherry discloses the topology as well as the connections, Kocherry does not explicitly teach declarative and/or imperative descriptions.
Bawcom teaches establishing, based at least in part on this topology of devices, at least one declarative and/or imperative description of the DCS that characterizes multiple devices of the DCS, their placement, and their connections (See Bawcom cols. 2:45-49, 4:58-52, and 11:31-50: Infrastructure-as-Code (IaC) code generation that defines the topologies and connections of Kocherry).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine, with a reasonable expectation of success, the control system topologies of Kocherry with the declarative descriptions of Bawcom. One would have been motivated to combine these references because both references disclose virtual topological information and while declarative/imperative programming are common programming paradigms, Bawcom further enhances the topologies of Kocherry by improving the compliance capabilities as well as the efficiency via automation of the rollouts of changes, using well-known IaC methods (See Bawcom cols. 2:43-67).
As per claim 3, Kocherry/Bawcom teaches the method of claim 1. However, while Kocherry discloses the topology as well as the connections, Kocherry does not explicitly teach declarative and/or imperative descriptions.
Bawcom discloses wherein the declarative and/or imperative description comprises infrastructure-as-code instructions that, when executed by a cloud platform, and/or a virtualization platform, and/or a configuration management tool, causes the cloud platform, and/or the virtualization platform, and/or the configuration management tool, to create a virtual instance of at least one device of the DCS with properties defined in the declarative and/or imperative description (See Bawcom col. 10:49-67 to 11:1-14 and 12:12-28: creating cloud deployment models that are defined in the IaC. These are subject to the compliance rules).
It would have been obvious to combine Kocherry with the teachings of Bawcom for at least the same reasons as discussed above in claim 1.
As per claim 4, Kocherry/Bawcom furter teaches the method of claim 1. However, while Kocherry teaches the characterizations of the data, Kocherry does not explicitly teach declarative and/or imperative descriptions.
Bawcom teaches wherein the declarative and/or imperative description characterizes: a number, and/or a clock speed, and/or a duty cycle limit, of processor cores, and/or a memory size, and/or a mass storage size, and/or a type of network interface, and/or a maximum network bandwidth, and/or an identifier of an instance type from a library of instance types available on a particular cloud platform (See Bawcom cols. 13:19-39: AppCode ID unique identifier for instances of applications; 22:40-67 to 23:1-7: amount of memory required can be changed in the IaC definition).
It would have been obvious to combine Kocherry with the teachings of Bawcom for at least the same reasons as discussed above in claim 1.
As per claim 5, Kocherry/Bawcom teaches the method of claim 1. However, while Kocherry discloses the topology as well as the connections, Kocherry does not explicitly teach declarative and/or imperative descriptions.
Bawcom teaches wherein the declarative and/or imperative description characterizes an architecture, a bandwidth, and/or a latency, of at least one network to which multiple virtual instances of devices of the DCS are connected (See Bawcom cols. 2:45-49, 4:58-52, and 11:31-50: Infrastructure-as-Code (IaC) code generation that defines the topologies and connections of Kocherry. This includes network infrastructure, virtual machines, and connection topologies).
It would have been obvious to combine Kocherry with the teachings of Bawcom for at least the same reasons as discussed above in claim 1.
As per claim 6, Kocherry/Bawcom further teaches the method of claim 1, further comprising: test-executing the control logic on the virtual deployment of the DCS; monitoring the behavior of the control logic during execution; comparing this behavior to a given expected behavior of the control logic; and evaluating, from a result of this comparison, according to a predetermined criterion, whether the test of the control logic has passed or failed (See Kocherry paras. [0060-644]: “comparing the outcome of the execution of test cases with the expected outcomes of the execution”, where the test case can pass/fail based on differences from expected outcomes. This includes control logics that are tested by the test cases).
As per claim 7, Kocherry/Bawcom further teaches the method of claim 6, wherein the test-executing comprises supplying, by the at least one I/O simulator, to the control logic, sensor and/or actor data that, in case a particular to-be-detected software error is present in the control logic, causes the behavior of the control logic to depart from the expected behavior (See Kocherry paras. [0060-644]: “comparing the outcome of the execution of test cases with the expected outcomes of the execution”, where the test case can pass/fail based on differences from expected outcomes. This includes control logics that are tested by the test cases).
As per claim 8, Kocherry/Bawcom further teaches the method of claim 7, wherein the to-be-detected software error comprises one or more of: concurrent or other multiple use of one and the same variable; wrong setting and resetting of variables; wrong reactions of the control logic to changes in variables; wrong limit or set-point values; missing or wrongly implemented interlocking logic; wrongly defined control sequences or sequences of actions; and an overflow and/or clipping of variables (See Kocherry paras. [0049], [0058-64], and [0079-80]: test cases that are eventually pass/fail. This includes settings for actual control equipment, such as fluid level settings).
As per claim 9, Kocherry/Bawcom further teaches the method of claim 6, further comprising: in response to determining that the test of the control logic has passed: setting up a physical DCS that corresponds to the virtual deployment of the DCS; and connecting the devices of the physical DCS to the assets executing the industrial process, rather than to the I/O simulator (See Kocherry paras. [0050-52] and [0064]: testing pass/fail. If the test case is passed, this can then be drawn from the repository when selecting control actions from the tested candidate control functions. These are associated with actuating components in the plant).
It would have been obvious to combine Kocherry with the teachings of Bawcom for at least the same reasons as discussed above in claim 1.
As per claim 10, Kocherry/Bawcom further teaches the method of claim 6, further comprising: in response to determining that the test of the control logic has failed: modifying the declarative and/or imperative description of the DCS, and updating the virtual deployment of the DCS based on this modified declarative and/or imperative description; and/or modifying the control logic for improving the performance of the control logic, and resuming the test-executing with the updated virtual deployment of the DCS, and/or with the modified control logic (See Kocherry paras. [0056] and [0064]: “comparing the outcome of the execution of test cases with the expected outcomes of the execution”, where the test case can pass/fail based on differences from expected outcomes. New test cases arise with new equipment; see also Bawcom col. 24:17-47: compliance checks and if the IaC fails to meet, then the checks can be repeated until compliance is met. The user is provided “with an opportunity to make the necessary changes to the IaC such that it meets the compliance requirements”).
It would have been obvious to combine Kocherry with the teachings of Bawcom for at least the same reasons as discussed above in claim 1.
As per claim 11, Kocherry/Bawcom teaches the method of claim 6. However, while Kocherry the virtual deployment of the DCS, Kocherry does not explicitly teach a figure of merit.
Bawcom teaches assigning, by a predetermined criterion, to a virtual deployment of the DCS and/or to the execution of the control logic on this virtual deployment, a figure of merit; and optimizing the declarative and/or imperative description of the DCS with the goal of improving this figure of merit, under the constraint that the test of the control logic on the respective virtual deployment of the DCS passes (See Bawcom cols. 2:2-3, 9:36-67 to 10:1-5, and 18:17-53: scoring information associated with development of applications to be deployed. This includes optimizing based on ease to migrate as well as prioritizing based on scores provided by the application scoring module. These application features are being applied to the testing and deployment of control logic of Kocherry).
It would have been obvious to combine Kocherry with the teachings of Bawcom for at least the same reasons as discussed above in claim 1.
As per claim 12, Kocherry/Bawcom further teaches the method of claim 6, further comprising: simulating a failure in at least one virtual instance of a device of the DCS, and/or in at least one connection of one such instance; and monitoring the influence of this simulated failure on the behavior of the control logic (See Kocherry paras. [0064] and [0079-80]: monitoring changes from test generations and the cause of those changes).
As per claims 13 and 15-20, the claims are directed to a non-transitory computer medium that implements the same features as the method of claims 1 and 3-8, respectively, and are therefore rejected for at least the same reasons therein. Furthermore, Kocherry/Bawcom teaches a non-transitory computer medium comprising machine-readable instructions that, when executed by a processor, cause the one or more computers and/or compute instances to perform a method for creating a virtual deployment of a distributed control system (DCS) for a given industrial process, comprising the steps of said method of claims 1-8 (See Kocherry paras. [0030-34] and [0037]).
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 Nicholas Klicos whose telephone number is (571)270-5889. The examiner can normally be reached Mon-Fri 9:00 AM-5:00 PM.
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, Scott Baderman can be reached at (571) 272-3644. 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.
/NICHOLAS KLICOS/Primary Examiner, Art Unit 2118
Prosecution Insights