Prosecution Insights
Last updated: May 29, 2026
Application No. 17/406,888

INFRASTRUCTURE MONITORING SYSTEM

Final Rejection §103§112
Filed
Aug 19, 2021
Priority
Sep 30, 2020 — provisional 63/085,345
Examiner
TRUONG, LOAN
Art Unit
2114
Tech Center
2100 — Computer Architecture & Software
Assignee
Arris Enterprises LLC
OA Round
8 (Final)
77%
Grant Probability
Favorable
9-10
OA Rounds
0m
Est. Remaining
90%
With Interview

Examiner Intelligence

Grants 77% — above average
77%
Career Allowance Rate
460 granted / 596 resolved
+22.2% vs TC avg
Moderate +13% lift
Without
With
+12.7%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
19 currently pending
Career history
628
Total Applications
across all art units

Statute-Specific Performance

§101
2.8%
-37.2% vs TC avg
§103
76.9%
+36.9% vs TC avg
§102
14.2%
-25.8% vs TC avg
§112
1.9%
-38.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 596 resolved cases

Office Action

§103 §112
DETAILED ACTION This office action is in response to applicants’ remarks filed on September 4, 2025 in application 17/406,888. Claims 1-9 are presented for examination. Claim 1-3 is amended. Claims 10-15 are previously cancelled. IDS submitted on December 10, 2021 was acknowledged. Terminal Disclaimer for application 17/584,839 was filed and approved on October 16, 2023. 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 . Response to Arguments Applicant's arguments filed September 4, 2025 have been fully considered but they are not persuasive. In regard to the remarks for 35 USC 112 for steps f-g and c-e, refer to the rejection for further details. In regard to the claimed limitation of the first and second containers being isolated, Aghajanyan et al. teach of a server computer hosting three containers where each of the containers provide an execution environment for an application that runs within the container para. 76, fig. 11. For the motivation to combine remarks, applicant’s own specification refer to creating a ticket provided to technical support that indicates the nature of the fault (para. 31) which is equated to the ticket of Srivastava et al. For these reasons, the rejections are maintained. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim 1 is/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 1 recited: c) receiving, a first fault indicating said first network device has a failure by which the first network device has ceased to operate; d) after receiving said first fault, using a machine learning process to process data from said first log and said second log, visualizing a first and second source of said fault, where said machine learning process includes a model that is trained and use said trained model to identify said first source of first fault and second source of second fault e) after identifying said first source and said second source perform a mitigation process to remedy a cause of said first fault and said second fault *** f) prior to receiving said first fault, using said machine learning process to process data from said first log information identifying a predictive source of a future predictive fault that has not yet occurred g) after identifying said predictive source of said future predictive fault, performing a mitigation process based upon said first log information to proactively prevent a cause of said future predictive fault. It is indefinite as to how f-g of proactively preventing said first fault and c-e the first fault still occurred. If the fault is prevented then c-e would not happen. If the fault happen then f-g did not happen. It is indefinite as to how both situations can happen on said first and second faults. Applicant’s specification describes based on prediction, the management system may attempt to mitigate the process, such as triggering mitigation activities and in addition may automatically create a ticket that is provided to technical support, such as a support engineer, para. 31. Applicant’s specification describes the management system 150 may receive an indication of a fault 500 and based upon an analysis by the machine learning process 510 based upon log files 520, and attempt to mitigate the fault 530 (fig. 5, para. 28). This would describe claimed c-e. Applicant’s specification further teach the management system 150 may provide increasingly higher robustness by including a predictive fault determination 600 based upon an analysis of the log files 610 using the machine learning process 620 (fig. 6, para. 29). This would describe claimed f-g. Therefore, the claimed invention can on run under normal condition mitigating a fault (fig. 5)(steps c-e) or run at the higher robustness of predicting fault which would use substantially more memory and/or substantially more processor usage (fig. 6, para. 29-31)(steps f-g). The two implementations of mitigating a received fault vs mitigating predicted future faults are run by two different processes and cannot be claimed as one. Further clarification is advised. Claim Rejections - 35 USC § 103 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. 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. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1-9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Aghajanyan et al. (US 2021/0216559) in further view of Srivastava et al. (US 2018/0260760) in further view of Teppoeva et al. (US 2021/0383206). In regard to claim 1, Aghajanyan et al. teach a method for managing network devices interconnected to a communications network comprising: a) receiving, by a management system, first log information from a first agent operating within a fist software container managed by a container orchestration system associated with a first said network device interconnected to said communications network (host agents are configured to monitor and collect performance statistics, alerts and events, para. 69, 122, fig. 8, 824, 825, 826); b) receiving, by said management system, second log information from a second agent operating within a second software container managed by a container orchestration system associated with a second said network device interconnected to said communications network (host agents are configured to monitor and collect performance statistics, alerts and events, para. 69, 122 fig. 8, 824, 825, 826), where said first container and said second container are operating on the same first server, where each of said first container and said second container are isolated from one another and bundle their own respective software, libraries, and configuration files (server computer used to host three containers, OSL virtualization involves an OSL virtualization layers 1102 that provides operating-system interfaces 1104-1106 to each of the containers 1108-1110. The containers, in turn, provide an execution environment for an application that runs within the execution environment provided by containers 1108. The container can be thought of as a partition of the resources generally available to higher-level computation entities through the operating system interface 430, para. 76, fig. 11); Aghajanyan et al. does not explicitly teach but Srivastava et al. teach c) receiving, by said management system that includes said container orchestration system operating on a second server separate from said first server, a first fault from said first agent indicating said first network device has a failure by which the first network device has ceased to operate that is received after receiving said first log information (cloud platform may receive ticket data, para. 15), a second fault from said second agent indicating said second network device has a failure by which the second network device has ceased to operate that is received after receiving said second log information (cloud platform may receive ticket data, para. 15, cloud platform may use the data model to further analyze historical ticket data with the same or similar ticket type, para. 16); d) after receiving said first fault indicating said first network device has cease to operate and said second fault indicating said second network device has ceased to operate said management system using a machine learning process to process data from said first log information and said second log information identifying a first source of said first fault based upon said first log information and a second source of said second fault based upon said second log information (the cloud platform may apply a machine learning technique to determine how issues associated with the subset of the historical ticket data were resolved, para. 17), said management system visualizing said first source of said fault to an operator and said second source of said fault to said operator (status update to the client device, para. 19), wherein said machine learning process includes a model that is trained (training machine learning module, para. 43) based upon training data that includes (1) previous faults and course of action used to repair such fault (analyze the particular resolutions associated with the subset of historical ticket data, para. 72) and (2) previous faults and course of actions that did not result in repair of such fault (ways the issue was attempted to be resolved, para. 13), that is used to make decisions without having been explicitly programmed to make such decisions (ticket data model that accurately and intelligently provides recommended resolutions to ticket issues, para. 13), where said machine learning process uses said trained model to identify said first source of said first fault without additional reference to any log information other than said first fault information associated with said first fault received from said first network device in response to the occurrence of said first fault (trend determination module may identify a correlation relating to one or more data points, para. 48), and uses said trained model to identify said second source of said second fault without additional reference to any log information other than said second fault information associated with said second fault from said second network device in response to the occurrence of said second fault (trend determination module may identify a correlation relating to one or more data points, para. 48) it is noted that the module could run multiple times for multiple errors where the modules can operate on multiple first and second platform, para. 49; e) after identifying said first source of said first fault by which the first network device has ceased to operate said management system performing a mitigation process to remedy a cause of said first fault (initiate automatic resolution of the ticket, para. 48) and identifying said second source of said second fault by which the second network device has ceased to operate said management system performing a mitigation process to remedy a cause of said second fault (initiate automatic resolution of the ticket, para. 48) it is noted that multiple errors and multiple tickets can be resolved; It would have been obvious to modify the method of Aghajanyan et al. by adding Srivastava et al. machine learning and resolution modules. A person of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to make the modification because it would aid in using machine learning and modeling for classifying and determine a resolution (para. 16-17). Aghajanyan et al. and Srivastava et al. does not explicitly teach but Teppoeva et al. teach f) said management system being further capable of identifying a predictive source of a future predictive fault, wherein prior to receiving said first fault said management system using said machine learning process to process data from said first log information identifying said predictive source of said future predictive fault based upon said first log information (the hardware failure prediction service may segment time series data to include a specific number of events of one or more non-filtered types that precede a hardware failure event that occurred on a server computing device, para. 19), said management system visualizing a first source of said future predictive fault to an operator, where said machine learning process include said model (hardware failure event may be flagged and/or otherwise reported to an administrator, para. 22, 47); (g) after identifying said predictive source of said future predictive fault said management system performing a mitigation process based upon said first log information (project data structure may utilize a data summary type of data structure, a data cube type of data structure, or the like, to enable analysis of millions or billions of points of structured or unstructured data from log files … may interact with external data structures to obtain additional information associated with ticket data, para. 35) to proactively prevent a cause of said future predictive fault (error mitigation engines implemented to prevent interruptions or other problems associated with server hardware failures, para. 55). It would have been obvious to modify the method of Aghajanyan et al. and Srivastava et al. by adding Teppoeva et al. identifying patterns in event logs to predict and prevent. A person of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to make the modification because it would aid in predicting hardware failure events that are going to occur in the near future (para. 4). In regard to claim 2, Aghajanyan et al. teach the method of claim 1 wherein said failure of said first network device is related to a hardware device (physical hardware problems, para. 85). In regard to claim 3, Aghajanyan et al. teach the method of claim 1 wherein said failure of said first network device is related to software (problems with objects in a data center, para. 86). In regard to claim 4, Aghajanyan et al. does not explicitly teach but Srivastava et al. teach the method of claim 1 wherein said machine learning process is trained based upon log information from network devices together with fault information (process the ticket data based on the ticket model, para. 16, process the historical ticket data to generate a data model, para. 64). Refer to claim 1 for motivational statement. In regard to claim 5, Aghajanyan et al. does not explicitly teach but Srivastava et al. teach the method of claim 4 wherein said machine learning process is trained based upon courses of action that resulted in repairs of faults (training a machine learning model to recommend resolutions and/or providing recommended resolutions, para. 73). Refer to claim 1 for motivational statement. In regard to claim 6, Aghajanyan et al. does not explicitly teach but Srivastava et al. teach the method of claim 1 wherein said machine learning process is modified based upon said first log information and said first fault (train the cognitive computing engine to analyze the ticket data where a cognitive computing engine apply a machine learning technique, para. 68) Refer to claim 1 for motivational statement. In regard to claim 7, Aghajanyan et al. does not explicitly teach but Srivastava et al. teach the method of claim 6 wherein said machine learning process is modified based upon a mitigation of said first fault (archive maintains updated information regarding the effectiveness levels of resolutions and cloud platform may access this information to make subsequent determinations regarding a resolution to implement, para. 96). Refer to claim 1 for motivational statement. In regard to claim 8, Aghajanyan et al. does not explicitly teach but Srivastava et al. teach the method of claim 7 wherein said mitigation of said first fault includes one or more actions that mitigated said first fault (ticket resolution information identifies one or more ways in which the issues was resolved, which may include failed resolution attempts, para. 64). Refer to claim 1 for motivational statement. In regard to claim 9, Aghajanyan et al. does not explicitly teach but Srivastava et al. teach the method of claim 8 wherein said mitigation of said first fault includes one or more actions that failed to mitigate said first fault (ticket resolution information identifies one or more ways in which the issues was resolved, which may include failed resolution attempts, para. 64). Refer to claim 1 for motivational statement. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO 892. Cella et al. (US 2022/0197246) predictive maintenance application ************************** McClymont, JR (US 2021/0136097) machine learning models with predict anomaly Verma et al. (US 2018/0024889) restarting of containers Petri et al. (US 10,904,376) monitor container and logs execution and state information Brown (US 2021/0248023) trace data collection and analysis agent in container or device DeLozier et al. (US 10,289,464) event prediction Choudhury et al. (US 2021/0342204) machine learning to predict application failure Bi et al. (US 2019/000489) error logs retrieved for input to the model Ang (US 2021/0406711) machine learning model with trained data logs ************************** Yan et al. (US 11,893,507) machine learning with predictive models Vasseur et al. (US 9,294,488) predicted attack mitigation packet with machine learning model Sopan (US 11,637,862) predictive machine learning model Sadaghiani et al. (US 10,341,374) machine learning model with threat mitigation ************************** Di Pietro et al. (US 2021/0279632) telemetry traces with machine learning Woodruff et al. (US 11,140,455) agent containers Kabbinale et al. (US 11,860,721) training a machine learning model Wang et al. (US 2023/0040564) causal learning for of machine learning Alavi (US 2022/0382613) error dynamics analysis Koneru (US 11,397,629) automated resolution, machine learning of past error logs ************************** Nguyen et al. (US 11,275,646) machine learning model with training dataset Yao et al. (US 2021/0406913) machine learning model with resolution rate ************************** Clarke et al. (US 2023/0123010) machine learning model to determine error Pillay et al. (US 9,710,122) machine learning algorithm for customer support Madhava Rao et al. (US 2019/0130310) cognitive IT event handler ************************** Khokhar (9,311,176) entry log identify errors and remedy Mahindru et al. (US 2020/0099592) health diagnostic Antony et al. (US 2018/0349213) log level adjustable Kumar et al. (US 2017/0364406) identify patches, logs, error code and remedy Rajagopal et al. (US 2015/0227404) agent to identify condition and remedies Gill et al. (US 8,984,220) path faults Hayden et al. (US 2019/0163594) log monitoring agents 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 LOAN TRUONG whose telephone number is 408-918-7552. The examiner can normally be reached on 10AM-6PM PST M-F. 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, Ashish Thomas can be reached on 571-272-0631. 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. /Loan L.T. Truong/Primary Examiner, Art Unit 2114 Loan.truong@uspto.gov
Read full office action

Prosecution Timeline

Show 12 earlier events
Jun 21, 2024
Non-Final Rejection mailed — §103, §112
Sep 23, 2024
Response Filed
Jan 03, 2025
Final Rejection mailed — §103, §112
Mar 25, 2025
Request for Continued Examination
Mar 30, 2025
Response after Non-Final Action
Jun 12, 2025
Non-Final Rejection mailed — §103, §112
Sep 04, 2025
Response Filed
May 06, 2026
Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12639154
AUTO-HEALING FOR BLOCKCHAIN CONFIGURATION DRIFTS
1y 11m to grant Granted May 26, 2026
Patent 12632345
PRIORITIZATION IN CLOUD MIGRATION FOR DEDUPLICATION SYSTEMS
3y 5m to grant Granted May 19, 2026
Patent 12613776
PARITY CACHE FOR RAID RELIABILITY, ACCESSIBILITY, AND SERVICEABILITY OF A MEMORY DEVICE
3y 8m to grant Granted Apr 28, 2026
Patent 12591485
STORAGE SYSTEM AND MANAGEMENT METHOD FOR STORAGE SYSTEM
2y 0m to grant Granted Mar 31, 2026
Patent 12585557
SYNCHRONIZATION OF CONTAINER ENVIRONMENTS TO MAINTAIN AVAILABILITY FOR A PREDETERMINED ZONE
3y 5m to grant Granted Mar 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

9-10
Expected OA Rounds
77%
Grant Probability
90%
With Interview (+12.7%)
3y 2m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 596 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month