DETAILED ACTION
This action is in response to the filing 06/18/2026. Claims 1-20 are pending and have been fully examined.
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 the Claims
Claims 1-20 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Beveridge et al. (U.S. PGPub No. 20230412629) in view of Beohar et al. (U.S. PGPub No. 20180203754), further in view of Chandavarkar et al. (U.S. PGPub No. 20250165365), further in view of Murphy (U.S. PGPub No. 20240411607).
Regarding Claim 1, Beveridge teaches,
A method for managing a data protection system, the method comprising: monitoring, by an interaction manager, a data protection workload executing on the data protection system, wherein the data protection system comprises a plurality of services, and wherein the data protection workload is executed by the plurality of services communicating with each other using application programming interface (API) calls (each collection agent (202) collects traces ("monitors") of API calls made during the runtime of the application ("executed by the plurality of services communicating with each other using API calls") [0030&/0042]; where in an instance of e-commerce, by example, the API services may include managing customer information and checkout-processing ("data protection" in an instance of a user interface communicating with a client device) [0022]);
obtaining a copy of the API calls (where API call traces corresponding to API calls are further provided to an analytics platform and API call traces may be filtered/aggregated (therefore, "copy of") [0043, 0046]);
detecting a failure associated with the data protection workload using the copy of the API calls (analyzer (of the analytics platform, see Fig. 2) analyzes API call traces to determine of the API calls are anomalous [0032]);
performing a remediation action [...] using a failure prediction engine (upon validation of the failure, the system proceeds to determine and take a remedial action [0036]);
While Beveridge discloses performing a remediation [0036] and that a type of model used for analysis may be a support vector machine [0057], Beveridge does not appear to disclose and Beohar teaches,
performing a root cause analysis on the failure using historical API calls of the data protection system and based on a random forest machine learning algorithm and a support vector machine algorithm (a system using a machine learning algorithm including, at least, a support vector machine and a random forest algorithm to generate context of failure including root cause [0047]);
performing a remediation action based on the root cause analysis and using a failure prediction engine (where the error detection and response computing platform ("failure prediction engine"), including the machine learning application comprising SVMs and random forest algorithm predicting root cause (Fig. 1b, [0047]), further includes providing a suggested solution [to an error] [0049]);
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the API call trace analysis and failure detecting system of Beveridge employing general machine learning to incorporate the particular machine learning algorithms as disclosed by Beohar. The resulting combination uses machine learning in such a way that provides effective, efficient, scalable, and convenient solutions to problems associated with channel systems [Beohar; 0006].
While Beveridge discloses techniques for dynamically retraining ML models for detecting anomalous API call behavior[0081-0085], and Beohar discloses updating the rules/parameters of the machine learning system based on an efficacy rating [of a resolution] [0032], Beveridge in view of Beohar do not appear to explicitly disclose, and Chandavarkar teaches,
and updating an action-reward associated with the remediation action and applying a reinforcement learning on the failure prediction engine based on the action-reward to obtain an updated failure prediction engine (applying a reinforcement learning algorithm (including q-learning [0027]; where the reinforcement learning model is applied to a machine learning-based recovery service upon the recovery service performing one or more changes to the system ("the remediation action") [0148]; where q-learning employs evaluating actions to maximize a reward function [0029]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the API call failure detection of Beveridge in view of Beohar to include employing reinforcement learning to update the failure prediction engine of Chandavarkar. The resulting combination allows for increased adaptability to ensure that the system remains finely tuned to allow for changing conditions [Chandavarkar; 0148].
While Beveridge discloses performing a remediation action [0036] and Beohar discloses performing a remediation action based on a root cause analysis, Beveridge in view of Beohar, further in view of Chandavarkar do not appear to disclose and Murphy teaches,
wherein the remediation action comprises at least re-organizing an order of tasks performed by the plurality of services or resolving dependencies between the API calls (in a system where API calls are collected and analyzed to generate a dependency graph of tasks performed by API calls [0025]; an optimization analyzer may be applied to perform optimizations, including reordering tasks [0025]; inference logic may be trained to perform prediction, where such logic may be used to perform optimization and task reordering [0068-0069]; further, a dependency graph may be generated to represent dependencies between [API] calls or tasks [0029] where optimization of a task sequence may include generating a second/updated dependency graph based on potential optimization [0042]);
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the API call failure detection and remediation of Beveridge in view of Beohar, further in view of Chandavarkar, to include the particular remediation of reorganizing tasks as disclosed my Murphy. The resulting combination allows for improved efficiency and resource utilization in the system [Murphy; 0041].
Regarding Claim 2, Beveridge teaches,
The method of claim 1, further comprising: prior to the monitoring: obtaining, by the interaction manager, the historical API calls for previous data protection workloads (where historical API call traces are obtained for the "sequence model" [0079]);
performing an API sequence analysis on the historical API calls to obtain API embeddings of a sequencing of the historical API calls (where the sequential model is trained (via known techniques [0079]) to perform sequential pattern mining on API call feature vectors [0074]);
performing a payload similarity analysis on payloads of each of the historical API calls to obtain a similarity model of the historical API calls (where the sequential model is trained (via known techniques [0079]) to perform behavior sequence analysis resulting in likely "next" feature API call vectors in view of known/received vectors [0073]; where API trace vectors include payloads of API calls [0062]);
and performing a training on the failure prediction engine using the similarity model, the API embeddings… (where base ML models and sequential models are components of the analytics platform that detects anomalies ("the failure prediction engine") [Fig. 2 for within the analytics platform; 0032 for detecting anomalous calls]; where the base ML models and sequential model are trained [0079&0068]).
Beveridge does not appear to disclose and Beohar teaches [relied upon distinguished in bold],
performing a service log analysis on services logs associated with the previous data protection workloads, wherein the service logs each indicate a result of each of the previous data protection workloads (where machine learning applications may be trained on historical data and analysis database [0032]; where historical data and analysis database includes historical event data such as: context for the previous system events, the identified suggested solution, the associated efficacy ratings of the identified suggested solution ("a result of each of the previous data protection workloads" [0033]);
and performing a training on the failure prediction engine using the similarity model, the API embeddings, and the service log analysis (where the machine learning application is trained at least on historical data including service logs [0032-0033]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the API call trace analysis and failure detecting system trained on, at least, historical data of Beveridge to incorporate particularly historical data including failures and outcomes by Beohar. The resulting combination allows for a robust training set that improves the training of the failure-detecting machine learning model by providing “labeled” training examples in the form of known-failures and outcome awareness.
Regarding Claim 3, Beveridge does not appear to disclose and Beohar teaches,
The method of claim 2 wherein one of the previous data protection workloads resulted in a second failure based on an issue caused by one of the historical API calls, and wherein one of the service logs indicates the second failure (where machine learning applications may be trained on historical data and analysis database [0032]; where historical data and analysis database includes historical event data such as: context for the previous system events, the identified suggested solution, the associated efficacy ratings of the identified suggested solution ("a result of each of the previous data protection workloads" [0033]).
The same motivation for Claim 2 also applies to Claim 3.
Regarding Claim 4, Beveridge teaches,
The method of claim 2, further comprising: performing, by the interaction manager, a latency and response time calculation on the historical API calls to obtain a latency and response model, wherein the training is further based on the latency and response model (where API call trace vector features include response latency [0042], a base ML model employed in detecting anomalies in API calls includes API call trace block-based feature analysis [0067]; where the base ML models are trained [0068]).
Regarding Claim 5, Beveridge in view of Beohar do not appear to disclose and Chandavarkar teaches,
The method of claim 1, wherein the reinforcement learning is a deep Q-learning algorithm (where the reinforcement learning applied to the failure module [0148] may be a q-learning algorithm [0027]).
The same motivation for Claim 1 also applies to Claim 5.
Regarding Claim 6, Beveridge teaches,
The method of claim 1, wherein the plurality of services comprises: an asset backup service, a pillar service, an asset restoration service, a scheduler, and a user interface communicating with a client device (the provided API services may exemplarily include an e-commerce application exposing APIs at the application's user interface [0022]).
Regarding Claim 7, Beveridge teaches,
The method of claim 1, wherein the failure is detected based on one of a list consisting of: one of the API calls being initiated out of order, an overloading of one of the plurality of services, and a detected latency issue (anomalous API calls may be found for the following reasons: API calls in an unusual order ("initiated out of order") [0033], an abnormal volume of API calls ("overloading") [0034], and latency issues [0042 for "latency" being a feature, [0067] for analysis of the features]).
Claims 8-14 recite a shift in statutory category and are rejected under 35 U.S.C. 103 as being unpatentable for the same reasons as Claims 1-7, respectively, above. Beveridge further teaches a non-transitory computer readable medium storing computer readable code [0108].
Claims 15-20 recite a shift in statutory category and are rejected under 35 U.S.C. 103 as being unpatentable for the same reasons as Claims 1-4 and 6-7, respectively, above. Beveridge further teaches processors [0107] and memory [0108].
Response to Arguments
Applicant’s arguments filed 06/18/2026 have been fully considered.
The Examiner acknowledges the amendments made to Claims 2, 9, and 16 to correct minor typographical errors. Accordingly, the previous objection has been overcome.
In response to the argument provided for the previous rejection under 35 U.S.C. 103, the Examiner finds that the previously cited prior art of record (Beveridge, Beohar, and Chandavarkar) does not disclose the amended limitations of Claims 1, 8, and 15 reciting, “the remediation action comprises at least re-organizing an order of tasks performed by the plurality of services or resolving dependencies between the API calls.” However, the Examiner points to paragraphs 0025, 0029, 0042, and 0068-0069 of newly cited Murphy as applied in the rejection above. Accordingly, Claims 1-20 remain rejected under 35 U.S.C. 103.
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 AUDREY E WHITESELL whose telephone number is (703)756-4767. The examiner can normally be reached 8:30am - 5:00pm MST.
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 5712723655. 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.
/A.E.W./Examiner, Art Unit 2113
/MARC DUNCAN/Primary Examiner, Art Unit 2113
