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 .
Status of Claims
Claims 1-20 are presented for examination in this application. The application filing date on 09/09/2024. Claims 1 and 12 are independent.
Examiner notes
(A). Drawings submitted on 09/09/2024 comply with the provisions of 37 CFR 1.121(d).
(B). IDS submitted on 06/02/2026, all references considered by the Examiner except where lined through. Because application did not provide the particular NPL.
(C). Limitations have been provided with the Bold fonts in order to distinguish from the cited part of the reference (Italic).
(D). Examiner has cited particular columns, line numbers, references, or figures in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses to fully consider the reference in entirety, as potentially teaching all or part of the claimed invention. See MPEP § 2141.02 VI and 2123.
The examiner requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111 (c).
Priority
Applicant claims priority to provisional application No. 63/537,361 filed on September 8, 2023 related to this application. The submission claim is in compliance with the provisions of 37 CFR 1.78. Accordingly, the provisional application’s date is being considered by the examiner.
Claim Objections
Claims 1-20 are objected to because of the following informalities:
Claim 1:
Line 12, insert --the-- before “incident report”.
Claim 11:
Line 1, “the incident” lacks proper antecedent basis.
Claim 12:
Line 13, insert --the-- before “incident report”.
Claim 19:
Lines 1-2, “the incident” lacks proper antecedent basis.
Claims 2-10, 13-18, and 20 are dependent claims of objected claims; therefor they inherit the same issues as in the base claims.
Appropriate correction is required.
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 of this title, 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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-2, 4-8, 12-13, 15-16 and 20 are rejected under 35 U.S.C. 103 as being obvious over Deng et al (US 20170024299 A1, hereinafter Deng) in view of Verma et al (US 20240414044 A1, hereinafter Verma).
As to claim 1, Deng discloses a computer-implemented method comprising:
determining, by a fault injection system, one or more fault injection parameters for testing one or more target components of a target system (par. 0003, “… computer-implemented method can include steps of determining one or more fault conditions to be associated with a fault injection implementation based on one or more parameters associated with a request for the fault injection implementation; generating a specification for a lifecycle of the fault injection implementation based on the one or more fault conditions; and executing the fault injection implementation in a target system”. Further, par. 0038, “Step 202 includes determining [i.e. testing] one or more fault conditions to be associated with a fault injection implementation based on one or more parameters associated with a request for the fault injection implementation, wherein said determining is carried out automatically by a decision-making component executing on a hardware processor [i.e. target system component]. The fault conditions can include fault type, fault occasion, fault location, and/or target system workload.”);
injecting the one or more faults into the one or more target components of the target system according to the determined parameters (abstract, Methods, systems, and computer program products for providing fault injection to Cloud-provisioned machines are provided herein. A method includes determining one or more fault conditions to be associated with a fault injection implementation based on one or more parameters associated with a request [i.e. identified] for the fault injection implementation; … Further, par. 0042,… the fault injection specification component. Further, such an embodiment includes monitoring one or more predetermined items [i.e. identified parameters] of data during the fault injection implementation in the target system, and outputting the one or more predetermined items of data monitored during the fault injection implementation to a database executing on the hardware processor and communicatively linked to the execution component. Further, see pars. 0003 and 0038 in the above);
monitoring behavior of the one or more target components and the target system to assess performance of the components and system under adverse conditions created by the one or more injected faults (par. 0017, … fault injectors onto the target machines (via sub-component 122), setup of the fault injection campaigns (via sub-component 124), and management of the FI experiment lifecycles (via sub-component 126). Moreover, the executor 118 collects monitoring and performance data of the target machines … . Further, par. 0042, … an embodiment includes monitoring one or more predetermined items of data during the fault injection implementation in the target system, and outputting the one or more predetermined items of data monitored during the fault injection implementation to a database executing on the hardware processor and communicatively linked to the execution component.);
detecting, by the fault injection system (par. 0042, determining a set of multiple fault conditions to be associated with a target system fault injection implementation based on one or more parameters associated with a request for the fault injection implementation …), creation of an incident report at the target system (par. 0033, the FI plan executor component 118 drives the life-cycle of fault injection experiment via sub-component 126. Such actions include initializing the test bed machines and saving the VM images of the initialized machines. Such initialization includes installing the FI infrastructures and tools as well as Cloud monitoring tools onto the machines with the target applications and/or systems. Also, initialization includes generating scripts for the life-cycle, which can include, for example, scripts for starting the saved VM images, starting the workload, injecting the fault [i.e. incident], waiting for experiment completion, and copying the logs [i.e. incident report] and monitoring data );
Deng does not explicitly disclose the following limitation but,
Verma discloses implementing one or more countermeasures to automatically roll back the one or more injected faults responsive to detecting incident report creation (par. 0037, the fault definition also includes remediation information 310. Remediation information identifies the remediation plan for addressing the impact of a fault on the cloud infrastructure. For example, remediation information can identify the type of remediation plan, e.g., failover plan, backup solution, automatic rollback procedure, and the like, as well as parameters of the remediation plan).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Deng to include implementing one or more countermeasures to automatically roll back the one or more injected faults responsive to detecting incident report creation, as disclosed by Verma, for the purpose of identifying the type of remediation plan (see par. 0037 of Verma).
As to claim 2, Verman discloses the computer-implemented method further comprising:
generating, by the fault injection system, a fault injection report describing performance of the target component and target system under the adverse conditions (par. 0005, … the method includes receiving a fault definition that defines at least one fault type to be injected into one or more targeted components of the cloud infrastructure, the cloud infrastructure providing at least one service to clients and including a plurality of components that perform various tasks in support of the at least one service, the plurality of components including hardware and software components, the targeted components being selected from the plurality of components, the fault definition being an electronic file that identifies the at least one fault type intended to negatively impact [i.e. adverse condition] performance of the one or more targeted components …);
and sending the fault injection report to the target system responsive to roll back of the one or more injected faults (par. 0069, … The fault injection system of item 1, wherein the fault definition includes remediation information, the remediation information indicating a remediation plan for mitigating the fault, the remediation plan including at least one of a failover plan, a backup plan, and a rollback plan. …).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Deng to include generating, by the fault injection system, a fault injection report describing performance of the target component and target system under the adverse conditions and sending the fault injection report to the target system responsive to roll back of the one or more injected faults, as disclosed by Verma, for the purpose of identifying the type of remediation plan (see par. 0037 of Verma).
As to claim 4, Deng discloses wherein the fault injection system injects the one or more faults into the target component via pin-level injection (par. 0025, … the invention, there can be multiple fault locations for the same type of error. By way of example, for a network error, at least one embodiment of the invention can include injecting into a switch [i.e. pin-level], a network interface controller (NIC), a device driver, a system call, a socket library, a library call, an application, etc. …).
Verman discloses the computer-implemented method wherein the target component is a hardware component of the target system (par. 0027, The practice of chaos testing is widely utilized for assessing the resilience of a system in the face of unfavourable conditions by deliberately introducing faults into its various components. However, existing chaos testing tools and methods frequently rely on the arbitrary or subjective selection of individual faults to be injected into different components of a target system. …)
As to claim 5, Deng discloses the computer-implemented method wherein the fault injection parameters include one or more of a fault type, a fault location (par. 0017, … the cloud environment, as well as the fault injection-related data (for example, fault type, fault occasion, fault location, workload, etc.), and places such data into the cloud data/monitoring data database 130 and the knowledge base on fault/error 132, respectively.), a fault activation time or condition (par. 0036, … analysis methods can include, for example, generating histograms of outcome cases (with crash, hang, fail-silent violation, success, and finer outcome categories), …), and (par. 0025, … such distributions of different error locations and/or target components can be inferred by learning from historical data such as, for example, past error behavior of the target machine, system …).
Varma discloses a fault amplitude (par. 0041, In embodiments, the fault monitoring component 208 is configured to compare previous performance levels of components (i.e., performance levels prior to the fault being introduced) to performance levels of the components while the fault is being injected into the cloud infrastructure to determine an impact of the fault on the components of the cloud infrastructure. …),
As to claim 6, Deng discloses the computer-implemented method wherein the one or more countermeasures are defined (pars. 0032-0035, … FIG. 1, the FI plan executor component 118 includes sub-component 120 for installing a central FI controller, sub-component 122 for deploying an FI agent and fault injector, sub-component 124 for setting-up an FI campaign, and sub-component 126 for managing the life-cycle of an FI experiment. Fault injection requires precise coordination of the FI campaign setup, workload execution, interception and injection of the fault injector. … the FI plan executor component 118 drives the life-cycle of fault injection experiment via sub-component 126. Such actions [i.e. countermeasures] include initializing the test bed machines and saving the VM images of the initialized machines. …) and
Verma discloses tested prior to injection of the one or more faults (par. 0041, In embodiments, the fault monitoring component 208 is configured to compare previous performance levels of components (i.e., performance levels prior to the fault being introduced) to performance levels of the components while the fault is being injected into the cloud infrastructure to determine an impact of the fault on the components of the cloud infrastructure. …).
As to claim 7, Deng discloses the computer-implemented method wherein at least one of the fault injection parameters is specified by an operator of the target system via input to the fault injection system (par. 0013, the parameters of the request may include, as free-form strings or structured data, the target machines for the fault injection, the configuration file for the fault injection (including user name and password, for example), the purpose of the fault injection, guidelines and/or heuristics on fault types, etc. The decision-making planner component 104 includes a sub-component (or engine) 106 for deciding fault type, a sub-component (or engine) 108 for deciding fault occasion, a sub-component (or engine) 110 for deciding fault location, and a sub-component (or engine) 112 for deciding workload. As further detailed herein, the decision-making planner component 104 outputs data to an FI plan specification component 114, which forwards input to an FI plan executor component 118.).
As to claim 8, Deng discloses the computer-implemented method wherein the fault injection system detects creation of an incident by calling an application programming interface (API) associated with the target system (par. 0016, component 102 exposes an API for external entities to invoke the fault injection service. After receiving a request, component 102 processes the request and assigns a task to the decision-making planner 104. The decision-making planner 104 uses analytics mechanisms to automatically make decisions on fault injection, wherein such decisions can include fault type (via sub-component 106), fault occasion (via sub-component 108 …).
As to claim 12, it is a medium claim, having similar limitations of claim 1. Thus, claim 12 is also rejected under the same rationale as cited in the rejection of claim 1.
As to claim 13, it is the medium claim, having similar limitations of claim 2. Thus, claim 13 is also rejected under the same rationale as cited in the rejection of claim 2.
As to claim 15, it is the medium claim, having similar limitations of claim 4. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of claim 4.
As to claim 16, it is the medium claim, having similar limitations of claim 8. Thus, claim 16 is also rejected under the same rationale as cited in the rejection of claim 8.
As to Claim 20, Deng discloses the non-transitory computer-readable storage medium wherein the fault injection parameters include a predicted impact on target component or system behavior (par. 0017, … the cloud environment, as well as the fault injection-related data (for example, fault type, fault occasion, fault location, workload, etc.), and places such data into the cloud data/monitoring data database 130 and the knowledge base on fault/error 132, respectively. … Further, par. 0025, … such distributions of different error locations and/or target components can be inferred by learning from historical data such as, for example, past error behavior of the target machine, system …).
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being obvious over Deng et al. and Verma et al. as applied to claims 1, 12 in above and further in view of Papak et el. (US 20180285239 A1, hereinafter Papak).
As to claim 3, Verma discloses the computer-implemented method wherein the target component is a software component of the target system (par. 0004, … the cloud infrastructure providing at least one service to clients and including a plurality of components that perform various tasks in support of the at least one service, the plurality of components including hardware and software components, the targeted components being selected from the plurality of components … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Deng to include the computer-implemented method wherein the target component is a software component of the target system, as disclosed by Verma, for the purpose of monitoring the impact of faults on the components which enables component dependencies to be determined (see abstract of Verma).
Deng as modified by Verma does not explicitly disclose the following limitations but,
Papak discloses and wherein the fault injection system injects the one or more faults into the target component via runtime injection techniques (par. 0068, and wherein the fault injection system injects the one or more faults into the target component via runtime injection techniques).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Deng to include wherein the fault injection system injects the one or more faults into the target component via runtime injection techniques, as disclosed by Papak, for the purpose of checking the current operating status (most recent connections to dependencies and so on) of the target system at that time (see par. 0065 of Papak).
As to claim 14, it is the medium claim, having similar limitations of claim 3. Thus, claim 14 is also rejected under the same rationale as cited in the rejection of claim 3.
Claims 9 and 17 are rejected under 35 U.S.C. 103 as being obvious over Deng et al. and Verma et al. as applied to claims 1, 12 in above and further in view of Lanchares et el. (US 20100162231 A, hereinafter Lanchares).
As to claim 9, Deng as modified by Verma does not explicitly disclose the following limitation but,
Lanchares discloses the computer-implemented method wherein an incident is manually created at the target system in response to detection of one or more anomalies in a target system component or subsystem (par. 0023, … the event through which the request for the software applications and/or content is generated is manually or automatically triggered by a user device on behalf of the device itself or of a set of target user devices arranged to receive the respective applications and/or contents. Further, par. 0057, … the user device [i.e. target system] or devices 4 receiving 140 the requested software applications and/or contents send back response signals about possible detected incompatibilities or operation errors -anomalies]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Deng to include the computer-implemented method wherein an incident is manually created at the target system in response to detection of one or more anomalies in a target system component or subsystem, as disclosed by Lanchares, for the purpose to manually adapt those applications and falling in undue expenses and complexity for a proper development of said marketing system (see par. 0004 of Lanchares).
As to claim 17, it is the medium claim, having similar limitations of claim 9. Thus, claim 17 is also rejected under the same rationale as cited in the rejection of claim 9.
Claims 10 and 18 are rejected under 35 U.S.C. 103 as being obvious over Deng et al. and Verma et al. as applied to claims 1, 12 in above and further in view of Tennur et el. (US 20210406832 A1, hereinafter Tennur) and Demarne et al. (US 20220283793 A1, hereinafter Demarne).
As to claim 10, Deng discloses the computer-implemented method wherein an incident is automatically created at the target system by:
responsive (par. 0031, … steps of automatic deployment of the test bed and fault injection infrastructure and/or tools, a strategy for driving the life-cycle of an FI experiment from beginning to end (which can include, for example, creating the scripts for each step in the life-cycle), and documenting the monitoring tools and logs that are leveraged for collecting data).
Tennur discloses running on the target system, a probe configured to execute on the target system at a specified interval to collect telemetry data describing operations of the target system (0052, the process may receive telemetry data from multiple devices including a computing device of the user. For example, in FIG. 1, the server 104 may receive telemetry data, such as the telemetry data 148, from multiple computing devices, such as the representative computing device 102. The computing device 102 may send the telemetry data 148 to the server 104 (i) periodically (e.g., at a predetermined interval) …);
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Deng to include running on the target system, a probe configured to execute on the target system at a specified interval to collect telemetry data describing operations of the target system, as disclosed by Tennur, for the purpose to check particular set of events occurring within a predetermined period of time (see par. 0052 of Tennur).
Demarne discloses responsive to telemetry data failing one or more tests (par. 0057, Various criteria for determining the success or failure of the software test may be defined in software deployment manager 106 based on specified telemetry data).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Deng to include responsive to telemetry data failing one or more tests, as disclosed by Demarne, for the purpose to define or check the software deployment manager based on specified telemetry data and/or customer support data metrics. (see par. 0057 of Demarne).
Claims 11 and 19 are rejected under 35 U.S.C. 103 as being obvious over Deng et al. and Verma et al. as applied to claims 1, 12 in above and further in view of Barry et al. (US 20050216421 A1, hereinafter Barry).
As to claim 11, Deng discloses the computer-implemented method wherein the incident is associated with an incident log including one or more of an identification of an anomaly in the target system, an initial classification of the anomaly(par. 0036, … , generating histograms of outcome cases (with crash, hang, fail-silent violation, success, and finer outcome categories), log correlation for tracing error propagation, clustering faults or failures, correlation analysis among fault type [i.e. classification of the anomaly]), timestamps (par. 0037, … a certain period of time in software aging, etc., and example temporal parameters can include time elapsed between fault injections), a source of the anomaly (par. 0022, … scenarios of error [i.e. anomaly] occurrences that were encountered for the target machine, system and/or application and for the same type of machines, systems and/or applications as encountered in other data sources. …), an initial assessment of an impact of the anomaly on the target system (par. 0011, … the given fault injection campaign based on intelligent decision making, as well as user-provided input information. Further, as detailed herein, such a service orchestrates each fault injection experiment and generates a reliability evaluation [i.e. assessment), response measures (par. 0035, … the FI plan executor component 118 drives the life-cycle of fault injection experiment via sub-component 126. Such actions [i.e. response measures] include initializing the test bed machines and saving the VM images of the initialized machines. …),
Verma discloses and an identification of previous incidents associated with the one or more infected components or subsystems (par. 0019, … method that has been used to identify faults in hardware and software systems involves injecting faults into select hardware and software components so that the impact of the fault can be observed and plans for addressing the fault can be made. Fault injection is effective in identifying fault impacts and component dependencies in hardware and software systems having a limited number of components. Previous fault injection techniques, however, are not effective in identifying the impact of faults and component).
Verma discloses an indication of one or more infected components or subsystems (abstract, the cloud infrastructure. The system monitors the impact of faults on the components which enables component dependencies to be determined.),
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Deng to include an indication of one or more infected components or subsystems, as disclosed by Verma, for the purpose to define or check the system or software impact. (see abstract and par. 0004 of Verman).
Barry discloses network logs, (par. 0552, … specific event [i.e. incident] information such as alarms, reporting and user information. It also tracks the users who log on from the various client terminals via the client browser applications and stores such information as the user's log on password, access security, and the various alarm descriptions and their status as reported by network management system 1004),
an initial assessment of an impact of the anomaly on internal and external users of the target system (par. 0580, … artificially biased evaluation [i.e. assessment]criteria, percent allocation, and manipulation of user-defined peg-counter variables. SCP 1110 also supports the routing and blocking of incoming calls using event-level data based on one or more of the following characteristics: … . Further, par. 0774, … the workstations are applicable to both internal employees and external customers and users who will access the enterprise applications.),
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Deng to include network logs and an initial assessment of an impact of the anomaly on internal and external users of the target system, as disclosed by Barry, for the purpose to check security process. (see abstract and pars. 0773-0774 of Barry).
As to claim 19, it is the medium claim, having similar limitations of claim 11. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of claim 11.
Conclusion
11. Prior arts made of record are considered pertinent to applicant's disclosure. See MPEP § 707.05 (C) For Examples:
I. Cao et al. (CN 117455458 A) discloses: “ The invention claims an automatic operation and maintenance method, device, equipment and storage medium, belonging to the technical field of operation and maintenance management. The application obtains the operation and maintenance index monitoring item of the target device; if there is abnormality in the operation and maintenance index monitoring item, analyzing the abnormality in the operation and maintenance index monitoring item through the preset operation and maintenance robot, and outputting the operation and maintenance solution to the related personnel according to the analyzed result, for the related personnel to examine whether the operation and maintenance solution is executed; under the condition that the related personnel agree to execute the operation and maintenance solution, according to the operation and maintenance solution, through the operation and maintenance robot, performing automatic operation and maintenance on the target device, namely, through the preset operation and maintenance robot, analyzing the abnormality existing in the operation and maintenance index monitoring item, and outputting the corresponding operation and maintenance solution to the related personnel, so that the related personnel can realize the effect of automatic operation and maintenance to the target device according to the operation and maintenance solution after the approval is finished, so as to improve the operation and maintenance efficiency” (please see abstract).
II. Baset et al. (US 20150161025 A1) discloses: “Methods, systems, and articles of manufacture for injecting faults at select execution points of distributed applications are provided herein. A method includes monitoring a run-time state of each of multiple components of a distributed application to determine one or more sequence of events that triggers a fault injection point at one of the multiple components; defining a fault injection scenario in a specification based on said monitoring, wherein said fault injection scenario comprises a description of one or more sequence of events during which an intended fault is to be injected to a target component of the multiple components at one selected event; and executing the fault injection defined in the specification to perform injection of the intended fault during run-time of the distributed application.” (please see abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD H KABIR whose telephone number is (571)270-1341. The examiner can normally be reached M-F, 8: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, Sam Sough can be reached at 571-272-6799. 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.
/Mohammad Kabir/
Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
