FINAL OFFICE ACTION
Status of the Claims
Claims 1 and 7-13 are rejected under 35 U.S.C. 103
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.
Claims 1 and 7-13 are rejected under 35 U.S.C. 103 as being unpatentable over Baker et al. (U.S. Publication No. 2025/0077374 A1), hereinafter referred to as Baker, in view of Kayal et al. (U.S. Patent No. 10,684,940 B1), hereinafter referred to as Kayal.
Regarding Claim 1, Baker teaches:
A test support device for designing a fault that matches a microservice state that changes over time in a test target system, the test support device comprising: a memory storing: ([0043]);
microservice information including, for each microservice, a reliability function set in the microservice, a setting item set to realize the reliability function, and a setting value set in the setting item; (Figs. 3-6, [0046]; regarding, “table 300 of a telemetry database illustrating a plurality of fault scenarios and telemetry data associated with each of the plurality of fault scenarios in accordance with one or more embodiments. As illustrated, table 300 includes a plurality of entries 302 that each include an identification of the service under test 304, an identification of the configuration 306 of the service under test, an identification of a fault scenario 308 applied to the configuration of the service under test, one or more telemetry data 310 collected during the application of the fault scenario to the configuration of the service under test, and one or more SLIs 312 calculated based on the telemetry data 310.”; Fig. 4, [0050]; regarding, “table 400 of a telemetry database illustrating a plurality of fault scenarios and a plurality of anomalies associated with each of the plurality of fault scenarios in accordance with one or more embodiments. As illustrated, table 400 includes a plurality of entries 402 that each include an identification of a fault scenario 404 and one or more anomalies 406 that comprise the fault scenario 404.”);
microservice state information including an identifier of a computer resource deployed as the microservice, an operation rate of each computer resource, and a utilization rate of a processor used in the computer resource; (Figs. 3 and 6, [0035]; regarding, “the performance analysis system 120 is a computing system that analyzes the behavior of the service under test 112 and the computing resources utilized by the service under test 112.”; [0037]; regarding, “Capacity SLIs measure the resource utilization and capacity limits of the service under test 112. Capacity SLIs can include metrics like CPU usage, memory usage, disk space utilization, or network bandwidth consumption.”);
fault condition information including, for each reliability function, a fault type indicating a fault to be generated in the microservice, a fault setting item related to the fault, and a setting value set in the fault setting item; (Figs. 3-6, [0045]);
and fault setting information associated with a reliability function, a fault type, and a fault setting item; (Figs. 3-6, [0045]);
and a processor configured to: select the microservice and the reliability function to be tested for a fault based on the microservice information; ([0061]; regarding, “the method 700 includes selecting, based on the telemetry data, a first fault scenario from the first plurality of fault scenarios. In some embodiments, multiple fault scenarios can be identified based on the first plurality of fault scenarios. In one embodiment, the first fault scenario is selected based on a determination that a service level indicator, calculated based on the recorded telemetry data, regarding the operation of the service under test corresponding to the first fault scenario deviates from an expected value by more than a threshold amount.”);
select the fault type based on the fault condition information; ([0051]; regarding, “table 500 includes a plurality of entries 502 that each include an identification of an anomaly 504, an identification of a computing resource 506 that the anomaly will be applied to, an identification of a type 508 of the computing resource 506, an anomaly type 510 that will be applied”);
determine whether a state of the microservice satisfies the fault condition information based on the microservice state information; ([0060]; regarding, “The telemetry data provides real-time information about the state and performance of the computing resources utilized by the service under test.”; [0061]; regarding, “the first fault scenario is selected based on a determination that a service level indicator, calculated based on the recorded telemetry data, regarding the operation of the service under test corresponding to the first fault scenario deviates from an expected value by more than a threshold amount.”);
select, based on the microservice state information, an identifier of a computer resource of the microservice that is to generate the fault; ([0031]; regarding, “the chaos engine 130 may identify each computing resource and a type of each computing resource in the configuration 114 and select anomalies to apply to one or more of the computing resources for a fault scenario 132.”);
set the identifier of the computer resources as a setting value of the fault setting item in the fault setting information; ([0031]; regarding, “the chaos engine 130 may obtain the configuration 114 of the computing environment 110 to identify the computing resources in the computing environment 110 and use this information during the creation of the anomalies in the fault scenarios.”);
determine, when the state of the microservice is determined to satisfy the fault condition information, whether a fault occurrence situation of the microservice satisfies the fault condition information based on the microservice state information; ([0033]; regarding, “The chaos engine 130 is configured to analyze the data relating to the operation of the service under test 112 under the first fault scenario and to responsively generate one or more additional fault scenarios that are applied to the service under test. For example, the chaos engine 130 analyzes the data in the telemetry metric database 122 relating to the operation of the service under test 112 under a first fault scenario to identify one or more anomalies of the first fault scenario”);
and generate, when the fault occurrence situation of the microservice is determined not to satisfy the fault condition information, the fault in the microservice based on the fault setting information and then determine again whether the state of the microservice satisfies the fault condition information, ([0034]; regarding, “an iterative process of applying a fault scenario, analyzing telemetry data of the service under test during the fault scenario, and responsively generating one or more additional fault scenarios is executed until a termination condition is met.”);
wherein, when the reliability function is autoscale, the fault type is computer resource kill or processor load, ([0031]; regarding, “Each fault scenario 132 includes one or more anomalies, such as injecting network latency, randomly terminating services, introducing a central processing unit (CPU) spikes, or simulating sudden increases in user traffic (e.g., creating and injecting artificial sure traffic to the service under test). The chaos engine 130 can generate fault scenarios 132 based on one or more of the configurations 114 of computing resources, data relating to the operation of the service under test 112 from the performance analysis system 120, and user input.”).
Baker fails to explicitly disclose but Kayal teaches:
wait until the state of the microservice satisfies the fault condition information when the state of the microservice is determined not to satisfy the fault condition information; (Col. 8, lines 45-55; regarding, “The control plane sends fault injection rules 315 to these agents 320A, 320B, instructing them to inspect the messages and perform fault-injection actions (e.g., one or more of abort, delay, and modify) if a message matches a given criteria.”);
and when the reliability function is timeout, the fault type is HTTP status. (Col. 10, lines 10-15; regarding, “From the perspective of a microservice 110 making an API call, failures in a remote microservice or the network can manifest in the form of delayed responses, error responses (e.g., HTTP 404, HTTP 503)”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to combine Baker with the teachings of Kayal. Doing so could improve the resilience of a given microservice to failure (Kayal, Col. 3, lines 10-18).
Regarding Claim 7, Baker in view of Kayal teaches the device of claim 1. Baker in view of Kayal further teach:
wherein when the reliability function is autiscale and the fault type is processor load, the fault condition information specifies that the computer resource to generate the fault is all computer resources of target microservices when being automatically scaled up to a maximum number. (Baker, [0031]; regarding, “Each fault scenario 132 includes one or more anomalies, such as… introducing a central processing unit (CPU) spikes, or simulating sudden increases in user traffic (e.g., creating and injecting artificial sure traffic to the service under test). The chaos engine 130 can generate fault scenarios 132 based on one or more of the configurations 114 of computing resources, data relating to the operation of the service under test 112 from the performance analysis system 120, and user input.”).
Regarding Claim 8, Baker teaches:
A test support method for designing a fault that matches a microservice state that changes over time in a test target system the method comprising:
Storing, by a processor, microservice information in a memory, wherein the microservice information includes, for each microservice, a reliability function set in the microservice, a setting item set to realize the reliability function, and a setting value set in the setting item; (Figs. 3-6, [0046]; regarding, “table 300 of a telemetry database illustrating a plurality of fault scenarios and telemetry data associated with each of the plurality of fault scenarios in accordance with one or more embodiments. As illustrated, table 300 includes a plurality of entries 302 that each include an identification of the service under test 304, an identification of the configuration 306 of the service under test, an identification of a fault scenario 308 applied to the configuration of the service under test, one or more telemetry data 310 collected during the application of the fault scenario to the configuration of the service under test, and one or more SLIs 312 calculated based on the telemetry data 310.”; Fig. 4, [0050]; regarding, “table 400 of a telemetry database illustrating a plurality of fault scenarios and a plurality of anomalies associated with each of the plurality of fault scenarios in accordance with one or more embodiments. As illustrated, table 400 includes a plurality of entries 402 that each include an identification of a fault scenario 404 and one or more anomalies 406 that comprise the fault scenario 404.”);
Storing, by a processor, microservice state information in the memory, wherein the microservices state information includes an identifier of a computer resource deployed as the microservice, an operation rate of each computer resource, and a utilization rate of a processor used in the computer resource; (Figs. 3 and 6, [0035]; regarding, “the performance analysis system 120 is a computing system that analyzes the behavior of the service under test 112 and the computing resources utilized by the service under test 112.”; [0037]; regarding, “Capacity SLIs measure the resource utilization and capacity limits of the service under test 112. Capacity SLIs can include metrics like CPU usage, memory usage, disk space utilization, or network bandwidth consumption.”);
Storing, by a processor, fault condition information in the memory, wherein the fault condition information includes, for each reliability function, a fault type indicating a fault to be generated in the microservice, a fault setting item relate to the fault, and a setting value set in the fault setting item; (Figs. 3-6, [0045]);
Storing by a processor, fault setting information in the memory, wherein the fault setting information is associated with a reliability function, a fault type, and a fault setting item; (Figs. 3-6, [0045]);
Selecting, by the processor, the microservice and the reliability function to be tested for a fault based on the microservice information; ([0061]; regarding, “the method 700 includes selecting, based on the telemetry data, a first fault scenario from the first plurality of fault scenarios. In some embodiments, multiple fault scenarios can be identified based on the first plurality of fault scenarios. In one embodiment, the first fault scenario is selected based on a determination that a service level indicator, calculated based on the recorded telemetry data, regarding the operation of the service under test corresponding to the first fault scenario deviates from an expected value by more than a threshold amount.”);
Selecting, by the processor, the fault type based on the fault condition information; ([0051]; regarding, “table 500 includes a plurality of entries 502 that each include an identification of an anomaly 504, an identification of a computing resource 506 that the anomaly will be applied to, an identification of a type 508 of the computing resource 506, an anomaly type 510 that will be applied”);
Determining, by the processor, whether a state of the microservice satisfies the fault condition information based on the microservice state information; ([0060]; regarding, “The telemetry data provides real-time information about the state and performance of the computing resources utilized by the service under test.”; [0061]; regarding, “the first fault scenario is selected based on a determination that a service level indicator, calculated based on the recorded telemetry data, regarding the operation of the service under test corresponding to the first fault scenario deviates from an expected value by more than a threshold amount.”);
Selecting, by the processor based on the microservice state information, an identifier of a computer resource of the microservice that is to generate the fault; ([0031]; regarding, “the chaos engine 130 may identify each computing resource and a type of each computing resource in the configuration 114 and select anomalies to apply to one or more of the computing resources for a fault scenario 132.”);
Setting, by the processor, the identifier of the computer resource as a setting value of the fault setting item in the fault setting information; ([0031]; regarding, “the chaos engine 130 may obtain the configuration 114 of the computing environment 110 to identify the computing resources in the computing environment 110 and use this information during the creation of the anomalies in the fault scenarios.”);
Determining, by the processor when the state of the microservice is determined to satisfy the fault condition information, whether a fault occurrence situation of the microservice satisfies the fault condition information based on the microservice state information; ([0033]; regarding, “The chaos engine 130 is configured to analyze the data relating to the operation of the service under test 112 under the first fault scenario and to responsively generate one or more additional fault scenarios that are applied to the service under test. For example, the chaos engine 130 analyzes the data in the telemetry metric database 122 relating to the operation of the service under test 112 under a first fault scenario to identify one or more anomalies of the first fault scenario”);
And generating, by the processor when the fault occurrence situation of the microservice is determined not to satisfy the fault condition information, the fault in the microservice based on the fault setting information and then determining again whether the state of the microservice satisfies the fault condition information, ([0034]; regarding, “an iterative process of applying a fault scenario, analyzing telemetry data of the service under test during the fault scenario, and responsively generating one or more additional fault scenarios is executed until a termination condition is met.”);
Wherein, when the reliability function is autoscale, the fault type is computer resource kill or processor load, ([0031]; regarding, “Each fault scenario 132 includes one or more anomalies, such as injecting network latency, randomly terminating services, introducing a central processing unit (CPU) spikes, or simulating sudden increases in user traffic (e.g., creating and injecting artificial sure traffic to the service under test). The chaos engine 130 can generate fault scenarios 132 based on one or more of the configurations 114 of computing resources, data relating to the operation of the service under test 112 from the performance analysis system 120, and user input.”).
Baker fails to explicitly disclose but Kayal teaches:
Waiting, by the processor, until the state of the microservice satisfies the fault condition information when the state of the microservices is determined not to satisfy the fault condition information; (Col. 8, lines 45-55; regarding, “The control plane sends fault injection rules 315 to these agents 320A, 320B, instructing them to inspect the messages and perform fault-injection actions (e.g., one or more of abort, delay, and modify) if a message matches a given criteria.”);
And when the reliability function is timeout, the fault type is HTTP status. (Col. 10, lines 10-15; regarding, “From the perspective of a microservice 110 making an API call, failures in a remote microservice or the network can manifest in the form of delayed responses, error responses (e.g., HTTP 404, HTTP 503)”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to combine Baker with the teachings of Kayal. Doing so could improve the resilience of a given microservice to failure (Kayal, Col. 3, lines 10-18).
Regarding Claim 9, Baker in view of Kayal teaches the device of claim 1. Baker in view of Kayal further teach:
wherein the processor is configured to execute a test covering all fault types for all reliability functions of all microservices, or to execute a test covering a specific fault type for a specific reliability function of a specific microservice selected in advance. (Baker, [0028]; regarding, “…automatically creating fault scenarios to be applied to a service under test, recording the telemetry of the service under test during the fault scenarios, and responsively creating and apply additional fault scenarios. In addition, automated service validation using chaos engineering increases the scope and breadth of the disruptions and failures included in the fault scenarios by randomly creating fault scenarios and iteratively creating new fault scenarios to apply to the service under test based on identified impacts of previously applied fault scenarios. As a result of applying automated service validation using chaos engineering, the reliability of the service under test is improved.”).
Regarding Claim 10, Baker in view of Kayal teaches the device of claim 1. Baker in view of Kayal further teach:
wherein when selecting the identifier of the computer resource of the microservice that is to generate the fault, the processor is configured to select a computer resource from among computer resources of the microservice having a high CPU utilization rate based on the microservice state information. (Baker, [0037]; regarding, “Capacity SLIs measure the resource utilization and capacity limits of the service under test 112. Capacity SLIs can include metrics like CPU usage, memory usage, disk space utilization, or network bandwidth consumption.”; [0051]; regarding, “In another example, for a processor the anomaly type can include a delay anomaly type, a utilization rate anomaly type”).
Regarding Claim 11, Baker in view of Kayal teaches the device of claim 1. Baker in view of Kayal further teach:
wherein when the reliability function is timeout and the fault type is HTTP status, the processor is configured to determine, as the setting value of the fault setting item, a fault duration longer than a standby time included in the microservice information. (Kayal, Col. 10, lines 10-16, 54-65; regarding, “From the perspective of a microservice 110 making an API call, failures in a remote microservice or the network can manifest in the form of delayed responses, error responses (e.g., HTTP 404, HTTP 503), invalid responses, connection timeouts and failure to establish the connection… Timeouts ensure that an API call to a microservice completes in a bounded time, to maintain responsiveness and release resources associated with the API call in a timely fashion. Bounded retries handle transient failures in the system by retrying API calls with the expectation that the fault is temporary, with such API calls retried a bounded number of times (possibly using an exponential back-off strategy to avoid overloading the called microservice). Circuit breakers prevent failures from cascading across the microservice chain by transitioning to open mode for a predetermined timeframe when repeated calls to a microservice fail”).
Regarding Claim 12, Baker in view of Kayal teaches the device of claim 11. Baker in view of Kayal further teach:
wherein the processor is configured to determine the fault duration as a value that is twice the standby time. (Kayal, Col. 8, lines 43-55; regarding, “The execution plane 310 of the framework 300 is where testing occurs, and can include network proxies referred to herein as fault-injection agents 320A, 320B that proxy API calls to and from the microservice and can manipulate the arguments, return values, and timing of these calls, thus acting as fault injectors. The AI failure model agent 115 can operate as part of a control plane 305 of the testing framework. The control plane sends fault injection rules 315 to these agents 320A, 320B, instructing them to inspect the messages and perform fault-injection actions (e.g., one or more of abort, delay, and modify) if a message matches a given criteria.”).
Regarding Claim 13, Baker in view of Kayal teaches the device of claim 1. Baker in view of Kayal further teach:
wherein when the reliability function is autoscale and the fault type is computer resource kill, the fault condition information specifies that the computer resource to generate the fault is a maximum number of computer resources not exceeding a predetermined percentage of target microservices. (Baker, [0031]; regarding, “Each fault scenario 132 includes one or more anomalies, such as… introducing a central processing unit (CPU) spikes, or simulating sudden increases in user traffic (e.g., creating and injecting artificial sure traffic to the service under test). The chaos engine 130 can generate fault scenarios 132 based on one or more of the configurations 114 of computing resources, data relating to the operation of the service under test 112 from the performance analysis system 120, and user input.”; [0034]; regarding, “the termination condition may be a determination that a service level indicator of the service under test has exceeded a threshold value, which may be set by an operator of the service under test 112. In a further embodiment, the termination condition may be a determination that a service level indicator of the service under test has deviated from an expected value by more than a threshold amount, which may be set by an operator of the service under test 112.”).
Response to Arguments
Applicant’s arguments filed 05/19/2026 have been fully considered.
Applicant’s amendments overcome the 101 rejection.
Applicant’s argues Baker fails to disclose the claimed microservice information and fault condition information of claim 1 and similarly claim 8 (“Remarks”, Page 21-22). Examiner respectfully disagrees. As claimed, the microservice information includes a reliability function, a setting item, and a setting value, the fault condition information includes a fault type, a fault setting item, and a setting value. Baker discloses in figures 3-6 information that the Examiner interprets as the claimed microservice information and fault condition information. Further Baker in combination with newly cited reference Kayal discloses the mapping between reliability function, fault types, and fault parameters such as autoscale and HTTP status.
Applicant’s arguments regarding the claimed fault setting, the claimed state-gated control sequence, and the reliability-function/fault-type mapping, claim 7 and claims 9-13 (“Remarks”, Pages 22-28) are considered moot as a new grounds of rejection has been applied. Please see the above rejection containing newly cited reference Kayal. Baker in view of Kayal teaches the claimed argued limitations.
Conclusion
THIS ACTION IS MADE FINAL. 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 MATHEW GUSTAFSON whose telephone number is (571)272-5273. The examiner can normally be reached Monday-Friday 8: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, Bryce Bonzo can be reached at (571) 272-3655. 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.
/MICHAEL MASKULINSKI/Primary Examiner, Art Unit 2113
/M.D.G./Examiner, Art Unit 2113
Prosecution Insights