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 non-final and is in response to the claims filed September 21, 2023. Claims 1-20 are currently pending, of which claims 1-20 are currently rejected.
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.
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 4 and 16 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 4 recites “of at least one compute instance that serves as a virtual instance of at least one device of the DCS” and it is unclear if this is meant to be a standalone limitation that is missing language or is supposed to be part of the “maximum network bandwidth” limitation. It is also unclear if every separate indented limitation is part of a single limitation or part of the compute instance. The indentation and structure of the claim causes the metes and bounds of the claim to be indeterminable. Claim 16 recites similar language and is rejected for at least the same reasons therein.
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 therefor, subject to the conditions and requirements of this title.
Claims 13-20 is/are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter. During examination, the claims must be interpreted as broadly as their terms reasonably allow. In re American Academy of Science Tech Center, 367 F.3d 1359, 1369, 70 U.S.P.Q.2d 1827, 1834 (Fed. Cir. 2004). Independent claim 13 recites a “computer program”, which is not comprehensively defined by the specification. The broadest reasonable interpretation of a claim drawn to a computer program covers software per se in view of the ordinary and customary meaning of computer program, particularly when the specification is silent. Software per se is not a “process,” a “machine,” a “manufacture,” or a “composition of matter” as defined in 35 U.S.C. § 101. Examiner suggests adding a recitation of a host “processor”. The currently claimed “computers” does not make the claim a system comprising the computers, just that the program can be run on a computer.
Claims 14-20 are also directed to the computer program and are rejected for the same reasons therein, and through their dependency from above-rejected claim 13.
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-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).
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 2, Kocherry/Bawcom further teaches the method of claim 1, further comprising: 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).
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, of at least one compute instance that serves as a virtual instance of at least one device of the DCS, 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, an/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-20, the claims are directed to a computer program that implements the same features as the method of claims 1-8, respectively, and are therefore rejected for at least the same reasons therein.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
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