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, see Arguments against Art Rejections for Claims 1, 6-13, 16, and 21 and Art Rejections for Claim 20, filed January 14, 2026, with respect to rejections of the claims under 35 U.S.C. 103 have been fully considered and are persuasive. As discussed in the interview held January 14, 2026, the amended claims overcome the current rejections. The rejections of the claims have been withdrawn. However, a new rejection of the claims is made in light of new art found in a search of the prior art prompted by amendments.
Claim Rejections - 35 USC § 102
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim 20 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Qadri et al. (US Patent Application Publication 2022/0206485).
Regarding claim 20, Qadri teaches a method of operating a network access control and management server, comprising:
detecting a failure (Abstract) of the network access control and management server that is configured to provide one or more services (Paragraphs 0001 – 0005, the cloud system contains on-prem servers that work in conjunction with services. The means of the on-prem server to communicate with the provider is interpreted as network access control and management);
with one or more sensors, measuring a first supply voltage (Paragraph 0113, battery parameters including voltage are measured and provided for power management data) and a first temperature of the network access control and management server (Paragraph 0051, physical conditions such as temperature are used as a monitoring rule; i.e. voltage and temperature are operating conditions) when the failure is detected (Paragraphs 0006 and 0007, the system log stores operating conditions; Paragraph 0029, the operating conditions include the failures of components);
with the one or more sensors, continuously monitoring a second supply voltage and a second temperature of the network access control and management server (Paragraph 0032, the on-prem server monitors itself);
with the failure prediction model, predicting an additional failure of the server that will impact the one or more services by computing a confidence level of the prediction based on the second supply voltage and the second temperature and determining whether the computed confidence level exceeds a threshold (Paragraph 0032, the anomaly detection signature contains a set of thresholds that are compared to system data in order to detect a failure) and by calculating a time of the additional failure of the server (Paragraph 0035, the monitor rule can predict when a future failure may occur); and
in response to predicting the additional failure of the server, restarting a faulty component of the network access control and management server before the time of the additional failure of the server (Paragraph 0055, one proposed action in response to a predicted failure is to reboot the faulty component, as part of predictive maintenance; Paragraph 0006, the system raises a proactive alert that allows the issue to be resolved before it causes a failure).
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1, 6 – 13, 16 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Qadri in view of Bell (US Patent 10,048,996, cited in previous action).
Regarding claim 1, Qadri teaches a method for operating a server, comprising:
with the server, providing one or more services relating to network access control and management of a network (Paragraphs 0001 – 0005, the cloud system contains on-prem servers that work in conjunction with services. The means of the on-prem server to communicate with the provider relates to network access control and management);
detecting a failure that has occurred at the server (Abstract);
obtaining log information and metrics data relating to the detected failure that has occurred at the server (Paragraphs 0006 and 0007, the system log stores operating conditions; Paragraph 0029, the operating conditions include the failures of components);
generating and training a server failure prediction model to recognize a pattern of the log information and metrics data relating to the detected failure that has occurred at the server (Paragraph 0049, a machine learning model analyzes log data of past failures to learn how to generate monitoring thresholds that correspond to the failures);
with the server failure model, detecting a behavior of the server matching the pattern to predict a failure of the server (Paragraph 0033, the monitor rule includes calculated thresholds based on previous conditions are used to determine when a failure of the server may occur) and calculate a timing of the failure (Paragraph 0035, the monitor rule can predict when a future failure may occur);
in response to predicting the failure of the server, restarting a faulty component of the server based on the calculated timing of the failure to avoid disruption in the one or more services relating to network access control and management of the network (Paragraph 0055, one proposed action in response to a predicted failure is to reboot the faulty component, as part of predictive maintenance; Paragraph 0006, the system raises a proactive alert that allows the issue to be resolved before it causes a disruption).
Qadri does not explicitly teach that obtaining log information and metrics data relating to the detected failure includes at least determining types of client devices that are connected to the network when the detected failure occurred at the server.
Qadri does teach, however, that client devices affect the operating conditions of the server (Paragraphs 0040/0041, the specific behavior of users utilizing a server may affect operating conditions, and the method of Qadri may adapt to said behavior).
Bell teaches a similar system to Qadri, determining types of client devices that are connected to the network when the detected failure occurred at the server (Column 7 lines 26 – 54, client identities, class of storage requested, data types, and types of requests of clients may be tracked for management, and that information may be used as part of a monitoring service to maintain system components).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention that one of the operating conditions of Qadri that the monitoring rules are based on could be types of client devices, as taught by Bell. Using client device types as operating conditions provides the advantage of another feature for the system to consider as a threshold, improving its precision in predicting failures. Qadri notes that the log data it considers may comprise any suitable type of data that defines the performance and operating state of the server (Paragraph 0049), and that client devices affect the operating state of the server (Paragraphs 0040/0041). Bell teaches that this information on client devices is useful for system maintenance (Column 7 lines 48 – 51). It would be clear to one of ordinary skill in the art that types of clients and similar information taught by Bell would be suitable as a form of data tracked by Qadri.
Regarding claim 6, Qadri in view of Bell teaches the method of claim 1, wherein obtaining log information and the metrics data relating to the detected failure that has occurred at the server further comprises determining a number of compute components in use by the server when the detected failure occurred at the server (Bell column 10 lines 53 – 64, operational metrics include utilization statistics for processors) or determining a number of storage components in use by the server when the detected failure occurred at the server (Qadri paragraphs 0047/0048/0050/0051, the system tracks the usage, data rates, and other conditions of individual storage devices; Bell column 10 lines 53 – 64, operational metrics include utilization statistics for storage components).
Regarding claim 7, Qadri in view of Bell teaches the method of claim 1, wherein obtaining the log information and the metrics data relating to the detected failure that has occurred at the server further comprises determining an operating condition of equipment associated with the server when the detected failure occurred at the server (Qadri Abstract, the system analyzes system data defining operating conditions of the server; Bell column 9 line 45 – column 11 line 58, Bell describes a number of different forms of operational metrics relating to server equipment).
Regarding claim 8, Qadri in view of Bell teaches the method of claim 1, wherein obtaining the log information and the metrics data relating to the detected failure that has occurred at the server further comprises determining a version of an operating system, software, or firmware being run by the server when the detected failure occurred at the server (Qadri paragraphs 0006/0039/0056 monitor rules define operating condition thresholds for particular hardware and software running on the on-prem server, monitor rules are tailored to the unique environments of the on-prem server).
Regarding claim 9, Qadri in view of Bell teaches the method of claim 1, wherein obtaining the log information and the metrics data relating to the detected failure that has occurred at the server further comprises determining the number of client devices that are connected to the network when the detected failure occurred at the server (Bell column 7 lines 26 – 54, identities, requests, and information on individual clients may be tracked for management, and that information may be used as part of a monitoring service to maintain system components).
Regarding claim 10, Qadri in view of Bell teaches the method of claim 1, wherein predicting the failure of the server further comprises computing a confidence level of the prediction and determining whether the computed confidence level exceeds a threshold (Qadri paragraph 0032, the anomaly detection signature contains a set of thresholds that are compared to system data in order to detect a failure; Bell column 12 lines 43 – 47, a confidence threshold).
Regarding claim 11, the combination of Qadri and Bell as applied to claim 1 teaches the method of claim 1, but does not teach that predicting the failure of the server further comprises computing a probability of the failure.
Bell further teaches computing a probability of the failure (Column 4 line 15; column 12 lines 43 – 47).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention that predicting the failure of the server by Qadri comprises computing a probability of the server as taught by Bell. It would be obvious because it allows the method to advantageously consider whether the event is likely enough to warrant intervention (Bell column 12 lines 43 – 54, a threshold is applied to the likelihood of failure to determine whether the risk warrants informing a client), which aligns with the methods of Qadri (Qadri paragraphs 0006/0007, the system is made in order to intervene before a failure has a negative impact). Although Qadri does not explicitly compute a probability, implicitly, the prediction indicates that the failure is likely to occur. It would be clear to one of ordinary skill in the art that there is some consideration of the probability of failure when Qadri predicts a failure, because a prediction of failure would not be useful if the probability of the prediction being correct is low.
Regarding claim 12, Qadri in view of Bell teaches the method of claim 1, further comprising:
in response to predicting the failure of the server by the server failure prediction model, alerting a user or administrator of the server (Qadri paragraph 0006, a maintenance alert; Bell Figs. 5, 6, and 7 step 740, using an interface to alert a user); and
providing a recommendation to the user or administrator for preventing the failure predicted by the server failure prediction model (Qadri paragraph 0033, a predictive maintenance recommendation; Bell column 4 lines 13 – 27, recommendations for mitigation actions are included in failure predictions).
Regarding claim 13, Qadri in view of Bell teaches the method of claim 12, further comprising:
providing the user or administrator with an opportunity to follow the recommendation (Qadri paragraph 0054, the recommendation is presented to the user); and
in response to receiving an input from the user or administrator to follow the recommendation, automatically reconfiguring the server based on the received input (Qadri paragraph 0055, the recommendation may be “configured” to automatically perform the maintenance recommendation; Bell column 13 lines 53/54, a button may be provided to execute a recommended action).
Regarding claim 21, Qadri in view of Bell teaches the method of claim 21, wherein the faulty component is restarted before the calculated timing of the failure (Qadri paragraph 0006, the issues are resolved before they cause downtime or impact critical applications).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Qadri in view of Bell as applied to claim 1 above, and further in view of Yanacek (NPL, cited in previous action).
Qadri in view of Bell teaches the method of claim 1.
Qadri in view of Siebel does not explicitly teach limiting a number of client devices connected to the server to prevent the failure (While Bell and Qadri teach frameworks for selecting mitigation actions, they do not focus on particular mitigation actions).
Yanacek teaches limiting a number of client devices connected to a server as a method to prevent a failure (Page 6, a failure can occur from excessive load; Page 11, limiting connections prevents such a failure).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention that the mitigation actions of Qadri in view of Bell would include limiting a number of client devices connected to a server as taught by Yanacek. Bell teaches redirecting traffic away from a server as a mitigation action (Fig. 9), which follows the same principle as the action taught by Yanacek of reducing the load on a server that is predicted to fail. Qadri teaches that the behavior of clients affects the operating conditions of the server (Paragraph 0040). Furthermore, Qadri and Bell teach that any suitable type of mitigation action and operating condition information can be used in their frameworks (Bell column 15 lines 18 – 30, Qadri paragraph 0049). It is well-known in the art that a server’s capacity to maintain client connections is finite, and that excessive connections have an adverse effect on the server (Yanacek pages 3 - 5). It would be clear to one of ordinary skill in the art to try limiting the amount of connections to prevent adverse effects related to the capacity of the server.
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 BRYAN PAI SONG HUANG whose telephone number is (571)272-0510. The examiner can normally be reached Monday - Friday 11:30 AM - 8:30 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, ASHISH THOMAS can be reached at (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.
/B.P.H./Examiner, Art Unit 2114
/ASHISH THOMAS/Supervisory Patent Examiner, Art Unit 2114