DETAILED ACTION
This Final rejection is response to the RCE amendment to the claims filed 2/5/2026. Claims 1, 3, 5, 7-11, 13, 15, 17-25 are pending. Claims 1, 11, and 20 are independent claims.
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 .
Claim Rejections - 35 USC § 112
The rejection of claims 1, 3, 5, 7-11, 13, 15, and 17-25 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description, and enablement requirements, have been withdrawn. The Applicant states that the specification supports “the prediction utilizes at least one statistical machine learning model comprising a plurality of hidden states”. The following statement is persuasive, and hence the rejection is withdrawn “page 7, lines 1-22: A Markov chain is a stochastic model describing a sequence of possible events in which the probability of each event depends only on the state attained in the previous event. A Hidden Markov Model (HMM) is a statistical Markov model in which the system being modeled is assumed to be a Markov process, call it S, with unobservable/hidden states. It assumes that there is another process O whose behavior depends on S. The goal is to learn about S by observing O. Turning now to FIG. 5, an example of a transition state diagram 500 for a data center is depicted. As shown, Si and S2 are data center states and Oi, 02, 03 are observations/device(s) state. In an HMM, there are typically two matrices, one being referred to as a transition matrix A which determines probabilities of transitions from one hidden state to another one (the next one)…”.
The rejection of claims 11, and 20 and respective dependent claims which contain similar limitation to claim 1, are likewise withdrawn.
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, 3, 5, 7-11, 13, 15, and 17-25 are rejected under 35 U.S.C. 103 as being unpatentable over Majumder et al., “Fault Detection Engine in Intelligent Predictive Analytics Platform for DCIM” (hereinafter Majumder), in view of Patel et al., “FTAB: Fault Tolerance Approach by Using HMM with BAUM-WELCH Algorithm in MCC” (hereinafter Patel), in view of Chien US 20200050510 A1, and further in view of Naor et al, hereinafter Naor, US 20190069797 A1.
Regarding claim 1, Majumder teaches:
An apparatus comprising: at least one processing device comprising a processor coupled to a memory; the at least one processing device being configured to: predict an impact to a data center comprising a plurality of devices based on an issue associated with a given device of the plurality of devices within the data center, wherein the prediction utilizes statistical machine learning model (Majumder: "The Markov Failure module predicts the severity of a failure along with survival probability of a device at any given instances." –Abstract, p.1) (Majumder: "The model of a computing unit, Fault Engine, which leverages the log-data from all concerned devices available in the device chain and employs a Markov Process based Failure Model to predict whether the failure is permanent or transient hence raising alarm with proper severity. It also indicates the recovery probability at any given time stamp after the failure has occurred. " –Section II, p.2) (Note: These citations show the system uses a Markov‐based (machine‐learning / probabilistic) model to predict how a device failure (issue) may affect the data center i.e., “the severity” or “impact.”)
Automatically cause one or more actions to be taken based on a result of the prediction. (Majumder: "The Root Cause Analysis model indicates probable devices as potential root cause employing Bayesian probability assignment and topological sort. Finally, a community detection algorithm produces correlated clusters of device in terms of failure probability which will further narrow down the search space of finding route cause." –Abstract, p.1)
(Majumder: "In an instance of failure, several devices can raise alarms ... Our goal of this module to allow the Fault Engine to know about the probability of a device to be actually faulty. ... The engine further assigns the conditional probability ... The order given by this module narrows down the search space of devices to a collection of probable root cause." –Section IV.B, p.5-7) (Majumder: "The interactive platform will save human time and labor by making all the predictions automatic. It will significantly reduce the human error because of the leads to probable correct outputs. " –Section VII, p.14, II) (Note: Here, once the Markov-based model forecasts the severity/state, the system “causes” further actions such as root-cause analysis, correlated cluster detection, and refined alarms. These are follow-up actions taken in response to the prediction’s outcome.)
In addition, Majumder teaches "A data center consists of several devices, mostly IP Protocol enabled, i.e. remotely accessible. Starting from the power station, all the devices create an acyclic chain or directed dependency graph where each device is a node and there is an edge between two nodes if they are physically/electrically connected. ... We assume the whole graph is acyclic i.e. there is no directed cycle in the graph. Also, in practical it is possible to have devices which is connected to dummy power supply to reduce possible link failure of its parent..." –Section IV.B, p.6) (Note: This excerpt demonstrates that the Fault Engine constructs or uses a directed dependency graph to track which devices are “connected” to any given device.)--the prediction comprising: identifying any devices of the plurality of devices that are connected to the given device based on operational data of the given device of the plurality of devices within the data center.
Majumder teaches "The fault engine conceptualizes a Markov Model ... which assumes three state for each device. Three states are Active (A), Transient Failure (T) and Permanent Failure (P) (Figure 1)." –Section IV.A, p.3, p.2) (Majumder: "This module works in a local manner where device level probability has been calculated to detect the nature of failure ..." –Section IV.A, p.5) (Majumder: "A data center consists of several devices ... If one device fails, all of its dependent devices will eventually fail ..." –Section IV.B, p.6) (Note: The above citations confirm that the Fault Engine uses a Markov‐based approach to determine the states of individual devices (Active, Transient, or Permanent) and also addresses how failures propagate to connected devices, thereby determining transition states across the data center as a whole.). In addition, to determining the states of the individual devices, failures of dependent devices, clustering is made of the data center, devices, and probable root cause of failure using colors, and different sizes (fig. 6-7 -- determining first transition states of the data center, second transition states of the given device, and third transition states of any devices that are connected to the given device.
Majumder fails to explicitly teach the operational data comprising at least network switch device current state data, server current state data and storage current state data. However, Chien teaches predicting faults in a server, storage server, and switch server (24). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Majumder, and Chien. One of ordinary skill in the art would have been motivated to make such a combination because Chien teaches reducing downtime and maintain service of the servers (24).
Majumder fails to explicitly teach comprising a plurality of hidden states. However, Patel discloses"The proposed monitoring technique is dealing with the unpredictability of mobile devices by using the past pattern for predicting the type of future operation states." –Introduction, p.1) (Note: These citations from Patel confirm that the invention employs the Baum-Welch (Forward–Backward) algorithm to compute the marginal probabilities of individual resource states. By training the HMM with past state patterns, the system determines the hidden states of the mobile cloud (i.e., data center) environment based on observed resource state transitions from the given device and its connected peers.
Majumder does not teach training the statistical machine learning model using a forward-backward algorithm with the respectively determined first, second, and third transition states of the data center, the given device, and any devices that are connected to the given device and with data center functionalities of the data center. However, Patel discloses "Baum-welch (Forward-Backward) gives marginal probability for each individual state." –Section IV, HMM Monitoring, p.3) (Patel: "The proposed monitoring technique is dealing with the unpredictability of mobile devices by using the past pattern for predicting the type of future operation states." –Introduction, p.1) (Note: These citations from Patel confirm that the invention employs the Baum-Welch (Forward–Backward) algorithm to compute the marginal probabilities of individual resource states. By training the HMM with past state patterns, the system determines the hidden states of the mobile cloud (i.e., data center) environment based on observed resource state transitions from the given device and its connected peers. This directly supports Claim 7’s requirement that the machine learning model be trained using a Baum–Welch algorithm applied to the transition states and functionalities of the data center.) --
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Majumder (which discloses a Fault Engine that leverages device log‐ data to predict failure severity and recovery probabilities through a Markov Failure model) with those of Patel (which clearly teaches the use of the Baum-Welch algorithm to train a Hidden Markov Model by analyzing past state patterns in mobile cloud computing). One of ordinary skill in the art would have been motivated to make such a combination because Patel emphasizes “The proposed monitoring technique is dealing with the unpredictability of mobile devices by using the past pattern for predicting the type of future operation states. This information is used for fault tolerance and improving the reliability and performance of the system.” This teaching would enhance failure prediction accuracy in data center environments by training a machine learning model using transition states (see Patel, Introduction, p.1).
Majumder does not teach to determine and tune parameters of the statistical machine learning model comprising the plurality of hidden states, wherein the parameters include a transition matrix, an emission matrix, and an initial state distribution. However, Naor discloses tuning model parameters, i.e., transition matrix, emission matrix, and initial state probability values (383). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Majumder, Patel, Chien, and Naor, because Naor teaches minimizing error, and reaching convergence (383).
Majumder does not teach wherein the data center functionalities of the data center comprise at least request functionalities, data collection functionalities and support functionalities. However, Patel discloses predicting future states of mobile devices having problems communicating and connecting to a network providing mobile applications, and services. The devices communicate and receive information and messages between a client and server devices (introduction, section II, parag.1, section III, A-B). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Majumder, Patel, Chien, and Naor, because Patel teaches improving reliability and performance of the system (page1, col.2, parag.3).
Regarding claim 3, Majumder teaches:
The apparatus of claim 1, wherein identifying any devices of the plurality of devices that are connected to the given device further comprises:
collecting operational data from the data center; (Majumder: "DCIM software is usually capable of raising real time alarms on critical health devices ... The Fault Engine deploys the middleware in polling and trapping from all standard IP protocol (e.g. SNMP/MODBUS) enabled devices in every time instance set by the user ..." –Section IV.B, p.5-6) (Note: This describes how the system obtains device‐level data—i.e., “collecting information” via polling/trap from the data center.)
generating a network topology diagram of the data center based on at least a portion of the operational data; and (Majumder: "A data center consists of several devices ... Starting from the power station, all the devices create an acyclic chain or directed dependency graph where each device is a node and there is an edge between two nodes if they are physically/electrically connected with a direction towards the power/information flow." –Section IV.B, p.6) (Note: This describes they construct a “directed dependency graph” of physically/electrically connected devices, which corresponds to a “network topology diagram.”)
identifying any connected devices based on the network topology diagram. (Majumder: "If one device fails, all of its dependent devices will eventually fail (except dummy parent cases)." –Section IV.B, p.6) (Majumder: "Hence, the Fault Engine is able to sort all the
devices topologically from the acyclic directed dependency graph which gives a decreasing order of importance of devices." –Section IV.B, p.7) (Note: Once the “graph” is built, the system knows which devices are connected and how failures propagate, so these citations confirm the step of “identifying connected devices based on the topology.”)
Regarding claim 5, Majumder teaches:
The apparatus of claim 1, wherein determining first transition states of the data center, second transition states of the given device, and third transition states of any devices that are connected to the given device further comprises:
collecting historic support ticket information from the data center; and (Majumder:
generating transition state diagrams for the data center, the given device, and any devices that are connected to the given device using a Markov chain and at least a portion of the historic support ticket information. (Majumder: "The fault engine conceptualizes a Markov Model ... which assumes three state for each device. Three states are Active (A), Transient Failure (T), and Permanent Failure (P)..." –Section IV.A, p.3) (Majumder: "This module works in a local manner where device level probability has been calculated to detect the nature of failure ..." –Section IV.A, p.5, Section IV.B, p.6, fig. 6-7) (Note: By applying the Markov chain to each device and connecting them via a directed graph, Majumder’s approach effectively generates transition diagrams that capture possible state transitions for each device, and thereby also provides a comprehensive view of failure dynamics across the entire data center based on historical failure data. In addition, to determining the states of the individual devices, failures of dependent devices, clustering is made of the data center, devices, and probable root cause of failure using colors, and different sizes)
Regarding claim 7, Majumder teaches the apparatus of claim 1.
Majumder does not teach but Patel teaches:
wherein training the statistical machine learning model comprising the plurality of hidden states using the respective first, second, and third transition states of the data center, the given device, and any devices that are connected to the given device further comprises using a Baum-Welch algorithm with the respective first, second, and third transition states and the data center functionalities of the data center to determine possible hidden states of the data center based on state data of the given device and any devices that are connected to the given device. (Patel: "Baum-welch (Forward-Backward) gives marginal probability for each individual state." –Section IV, HMM Monitoring, p.3, 6, fig.6-7) (Patel: "The proposed monitoring technique is dealing with the unpredictability of mobile devices by using the past pattern for predicting the type of future operation states." –Introduction, p.1) (Note: These citations from Patel confirm that the invention employs the Baum-Welch (Forward–Backward) algorithm to compute the marginal probabilities of individual resource states. By training the HMM with past state patterns, the system determines the hidden states of the mobile cloud (i.e., data center) environment based on observed resource state transitions from the given device and its connected peers. This directly supports Claim 7’s requirement that the machine learning model be trained using a Baum–Welch algorithm applied to the transition states and functionalities of the data center.)
Majumder and Patel are analogous to the present invention because they both address fault monitoring in cloud or mobile computing environments, focusing on predicting failure severity and recovery probabilities using Markov‐based models. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Majumder (which discloses a Fault Engine that leverages device log‐ data to predict failure severity and recovery probabilities through a Markov Failure model) with those of Patel (which clearly teaches the use of the Baum-Welch algorithm to train a Hidden Markov Model by analyzing past state patterns in mobile cloud computing). One of ordinary skill in the art would have been motivated to make such a combination because Patel emphasizes “The proposed monitoring technique is dealing with the unpredictability of mobile devices by using the past pattern for predicting the type of future operation states. This information is used for fault tolerance and improving the reliability and performance of the system.” This teaching would enhance failure prediction accuracy in data center environments by training a machine learning model using transition states (see Patel, Introduction, p.1).
Furthermore, Majumder fails to explicitly teach based on the network switch device current state data, the server current state data and the storage current state data. However, Chien teaches predicting faults in a server, storage server, and switch server (24). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Majumder, and Chien. One of ordinary skill in the art would have been motivated to make such a combination because Chien teaches reducing downtime and maintain service of the servers (24).
Regarding claim 8, Majumder teaches the apparatus of claim 7. Majumder does not teach but Patel teaches:
wherein predicting the impact to the data center based on the issue associated with the given device within the data center further comprises using a Viterbi algorithm to compute most probable hidden states of the data center. (Patel: "Viterbi gives probability of the most likely sequence of states. In order to improve the accuracy of prediction, the most probable value and the optimal status path is extracted and the prediction of state transition is calculated using Viterbi algorithm." –Section IV, HMM Monitoring, p.3) (Note: This citation confirms that Patel employs the Viterbi algorithm to derive the optimal (i.e., most probable) sequence of hidden states from observed data. This directly supports Claim 8’s limitation requiring the use of a Viterbi algorithm to compute the most probable hidden states of the data center based on the transition states of the given device and its connected devices.)
Regarding claim 9, Majumder in view of Patel teaches the apparatus of claim 8,
Majumder does not teach but Patel teaches:
wherein predicting the impact to the data center based on the issue associated with the given device within the data center further comprises, based on results of the Viterbi algorithm, predicting next states of the data center based on the next states of the given device and any devices that are connected to the given device. (Patel: "In order to improve the accuracy of prediction, the most probable value and the optimal status path is extracted and the prediction of state transition is calculated using Viterbi algorithm. The probability of all the paths on a predicted state can be calculated by multiplying forward calculation (FT) and backward calculation (BT)." –Section IV, HMM Monitoring, p.3) (Note: This citation shows that Patel employs the Viterbi algorithm to extract the optimal sequence of states and to calculate state transitions. By leveraging these results, the system can predict the next states of the data center based on the subsequent states of the given device and its connected devices, thereby satisfying Claim 9’s requirement.)
Regarding claim 10, Majumder teaches the apparatus of claim 1. Majumder does not teach but Patel teaches:
wherein the statistical machine learning model comprises a Hidden Markov Model. (Patel: In this paper we have proposed a fault monitoring technique which is based on Hidden Markov Model (HMM) and Baum-Welch algorithm for analyzing and predicting the future resource state." –Abstract, p.1) (Patel: "In this paper, we have proposed the monitoring techniques based on Hidden Markov Model (HMM), which analyzes the resource states information more precisely for solving the fault…" – Section IV, HMM Monitoring, p.3) (Note: These citations from Patel clearly show that the invention employs a Hidden Markov Model as the machine learning model, directly satisfying Claim 10’s requirement.)
Claims 11, 13, 15, 17-19 are directed towards a method claim that corresponds directly to apparatus claims 1, 3, 5, 7-9 respectively and are rejected for the same reasons.
Claims 20-25 is a computer program product claim that corresponds directly to apparatus claims 1, 3, 5, 7-9 respectively and are likewise rejected.
Response to Arguments
The rejection of claims 1, 3, 5, 7-11, 13, 15, and 17-25 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description, and enablement requirements, have been withdrawn as necessitated by the persuasive arguments as outlined above.
In addition, Applicant’s indicates that “Applicant submits that the present Office Action, at page 7, cites Majumder as teaching determining transition states of the data center, the given device, and any devices that are connected to the given device. However, Majumder clearly only discloses Active, Transient, and Permanent states with respect to a given device. Nowhere does Majumder teach or suggest determining specific transition states for a data center. The present Office Action attempts to summarily conclude, without any support from Majumder, that Majumder determines transition states of the data center because it determines transition states for a given device. This is a legally deficient mischaracterization of Majumder.”. The examiner disagrees, because Majumder teaches "A data center consists of several devices ... If one device fails, all of its dependent devices will eventually fail ..." –Section IV.B, p.6) (Note: The above citations confirm that the Fault Engine uses a Markov‐based approach to determine the states of individual devices (Active, Transient, or Permanent) and also addresses how failures propagate to connected devices, thereby determining transition states across the data center as a whole.). In addition, to determining the states of the individual devices, failures of dependent devices, clustering is made of the data center, devices, and probable root cause of failure using colors, and different sizes (fig. 6-7 -- determining first transition states of the data center, second transition states of the given device, and third transition states of any devices that are connected to the given device.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Preece US 9400731 B1, which teaches accurately predicting device failures by implementing Bayesian methods to calculate the probability of a failure given a prior probability and update the prior probability with data to yield a posterior probability.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CESAR PAULA whose telephone number is (571)272-4128. The examiner can normally be reached Monday - Friday, 6.30am- 4:30 pm ET.
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, David Wiley can be reached at (571)272-3923. 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.
/CESAR B PAULA/Supervisory Patent Examiner, Art Unit 2145
Prosecution Insights