DETAILED ACTION
Claims 1-25 are pending. Claims 1, 9, and 19 are in independent form.
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 .
Examiner Notes
The Examiner would like to note:
Claim 2, 10, and 20 the Examiner interpreted a graphical user interface broadly as something as simple as a drawn image done by a person with the aide of pen and paper.
Claim Objections
Claim 14 is objected to because of the following informalities:
“The method of claim97” is recited in claim 14; however, the Examiner is interpreting this as “The method of claim 9” in attempts to maintain compact prosecution. Appropriate correction is required.
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 5 is 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 5 recites the limitation "the second risk" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Claims 1-9 recite a computer program product with a processor and a non-transitory machine readable medium. Thus, these claims are directed to a product of manufacture, which is one of the statutory categories of invention. Claims 10-15 recite a method that includes specific steps. Thus, these claims are directed to a method, which is one of the statutory categories of invention. Claims 16-20 recite a system with processing resources. Thus, these claims are directed to a system, which is one of the statutory categories of invention.
Next, the claims are evaluated to determine whether the claims recite a judicial exception.
Step 2A Prong 1
Claim 1 recites:
A non-transitory machine readable medium storing instructions, which when executed by one or more processors of a data storage system, cause an auto-heal service running on the data storage system to:
monitor for a trigger event potentially indicative of a risk to which the data storage system is exposed by subscribing to a pub/sub bus for a notification regarding the trigger event;
after receiving the notification, determine existence of the risk by:
mapping the trigger event to a set of one or more rules defining one or more conditions that are indicative of a root cause of the risk, wherein the one or more rules are derived at least in part based on telemetry data received by a vendor of the data storage system from data storage systems of the vendor that are of a same or similar class and type of the data storage system; and
evaluating the set of one or more rules with respect to one or more of historical data and a current state of the data storage system; and
based on the set of one or more rules, identify availability of a remediation associated with the risk that addresses or mitigates the risk.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 9 recites:
A method comprising:
receiving, by an auto-heal service running on a data storage system, a notification regarding an event representing a trigger event or a scheduled risk check, wherein the trigger event is indicative of a first risk to which the data storage system is potentially exposed and wherein the scheduled risk check indicates a periodic check is to be performed for a second risk to which the data storage system is potentially exposed;
after receiving the notification, determine existence of the first risk or the second risk by:
identifying a set of one or more rules defining one or more conditions that are indicative of a root cause of the first risk or the second risk, wherein the one or more rules are derived at least in part based on telemetry data received by a vendor of the data storage system from data storage systems of the vendor that are of a same or similar class and type of the data storage system; and
evaluating the set of one or more rules with respect to one or more of historical data and a current state of the data storage system; and
based on the set of one or more rules, identify availability of a remediation that addresses or mitigates the first risk or the second risk.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 19 recites:
A data storage system comprising:
one or more processors; and
instructions that when executed by the one or more processors cause the data storage system to:
monitor for a trigger event potentially indicative of a risk to which the data storage system is exposed by subscribing to a pub/sub bus for a notification regarding the trigger event;
after receiving the notification, determine existence of the risk by:
mapping the trigger event to a set of one or more rules defining one or more conditions that are indicative of a root cause of the risk, wherein the one or more rules are derived at least in part based on telemetry data received by a vendor of the data storage system from data storage systems of the vendor that are of a same or similar class and type of the data storage system; and
evaluating the set of one or more rules with respect to one or more of historical data and a current state of the data storage system; and
based on the set of one or more rules, identify availability of a remediation associated with the risk that addresses or mitigates the risk.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 2, representative claim for claim 20, recites:
cause an administrative user of the data storage system to be notified of the risk and the remediation via a graphical user interface associated with the data storage system; and
after receiving an indication the remediation is authorized by the administrative user, execute one or more remediation actions that implement the remediation.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 3, representative claim for claim 11, recites:
wherein the instructions further cause the auto-heal service to automatically execute one or more remediation actions that implement the remediation.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 4, representative claim for claim 21, recites:
determine existence of a second risk to which the data storage system is potentially exposed by evaluating a second set of one or more rules on a periodic schedule;
based on the second set of one or more rules, identify availability of a second remediation associated with the second risk that addresses or mitigates the second risk;
determine the second remediation is authorized for automated performance without requiring authorization by the administrative user;
execute one or more remediation actions that implement the second remediation.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 5, representative claim for claims 12 and 22, recites:
wherein the second risk represents a misconfiguration of the data storage system, an issue associated with an environment in which the data storage system operates that might impact the data storage system, a security issue relating to the data storage system, a performance issue relating to the data storage system, a compliance issue relating to the data storage system, or a capacity issue relating to the data storage system.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 6, representative claim for claims 16 and 23, recites:
wherein the instructions further cause the auto-heal service to update a rule set of which the set of one or more rules are a part, wherein the update is delivered to the data storage system out-of-cycle with a release schedule for software of the data storage system.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 7, representative claim for claims 17 and 24, recites:
wherein the instructions further cause the auto-heal service to update to a remediation set of which the remediation is a part, wherein the update is delivered out-of-cycle with a release schedule for software of the data storage system.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 8, representative claim for claims 18 and 25, recites:
wherein the remediation set is derived at least in part based on the telemetry data.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 10 recites:
causing an administrative user of the data storage system to be notified of the first risk or the second risk and the remediation via a graphical user interface associated with the data storage system; and
after receiving an indication the remediation is authorized by the administrative user, executing one or more remediation actions that implement the remediation.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 13 recites:
prior to said receiving subscribing to a pub/sub bus for the notification regarding the trigger event.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 14 recites:
wherein a schedule for the periodic check is associated with the set of one or more rules.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Claim 15 recites:
wherein the data storage system comprises a distributed storage system in a form of a cluster of a plurality of nodes and wherein the auto-heal service runs on a primary node of the plurality of nodes.
The examiner submits that the foregoing italicized/bolded/underlined limitations comprise a mental process because this subject matter can be completed by a person with merely the aid of a pen and paper.
Next, the claims are evaluated to determine whether the claim as a whole integrates the abstract idea into a practical application of the exception.
Step 2A Prong 2
The claims includes the following additional limitations: “A non-transitory machine readable medium storing instructions, which when executed by one or more processors of a data storage system, cause an auto-heal service running on the data storage system to”, “subscribing to a pub/sub bus for a notification regarding the trigger event”, “after receiving the notification”, “subscribing to a pub/sub bus for the notification regarding the trigger event”, “wherein the data storage system comprises a distributed storage system in a form of a cluster of a plurality of nodes and wherein the auto-heal service runs on a primary node of the plurality of nodes”, “A data storage system”, “one or more processors”, “instructions that when executed by the one or more processors cause the data storage system to”, “received by a vendor of the data storage system from data storage systems of the vendor that are of a same or similar class and type of the data storage system”, “after receiving an indication the remediation is authorized by the administrative user”, “wherein the update is delivered to the data storage system out-of-cycle with a release schedule for software of the data storage system”, “wherein the update is delivered out-of-cycle with a release schedule for software of the data storage system”, “receiving, by an auto-heal service running on a data storage system, a notification regarding an event representing a trigger event or a scheduled risk check, wherein the trigger event is indicative of a first risk to which the data storage system is potentially exposed and wherein the scheduled risk check indicates a periodic check is to be performed for a second risk to which the data storage system is potentially exposed”, and “automatically execute one or more remediation actions that implement the remediation”.
Regarding “A non-transitory machine readable medium storing instructions, which when executed by one or more processors of a data storage system, cause an auto-heal service running on the data storage system to”, “subscribing to a pub/sub bus for a notification regarding the trigger event”, “after receiving the notification”, “subscribing to a pub/sub bus for the notification regarding the trigger event”, “wherein the data storage system comprises a distributed storage system in a form of a cluster of a plurality of nodes and wherein the auto-heal service runs on a primary node of the plurality of nodes”, “A data storage system”, “one or more processors”, and “instructions that when executed by the one or more processors cause the data storage system to” the examiner submits that these additional limitations are referencing generic computer components and merely includes instructions to implement the abstract idea on a computer, or merely uses a computer as a tool to perform the abstract idea.
Regarding “received by a vendor of the data storage system from data storage systems of the vendor that are of a same or similar class and type of the data storage system”, “after receiving an indication the remediation is authorized by the administrative user”, “wherein the update is delivered to the data storage system out-of-cycle with a release schedule for software of the data storage system”, “wherein the update is delivered out-of-cycle with a release schedule for software of the data storage system”, and “receiving, by an auto-heal service running on a data storage system, a notification regarding an event representing a trigger event or a scheduled risk check, wherein the trigger event is indicative of a first risk to which the data storage system is potentially exposed and wherein the scheduled risk check indicates a periodic check is to be performed for a second risk to which the data storage system is potentially exposed”, the examiner submits that these additional limitations could simply refer to as merely storing or retrieving data information in memory. Additionally, some of these elements are merely further specifying the type of data that is received or stored. Therefore, in support of this conclusion, see MPEP 2106.05(d)(II) which states that courts have recognized storing and retrieving information in memory are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity.
Regarding “automatically execute one or more remediation actions that implement the remediation”, the examiner submits that this additional limitation is viewed as insignificant extra-solution activity in line with MPEP 2106.05(g), “cutting hair after first determining the hair style”, wherein the mental process decides what to do and this is merely the end step of the mental process using generic hardware which was addressed above.
Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application of the exception.
Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. For example, there is no indication that the combination of elements improves the functioning of a computer or improves any other technology.
Next, the claims as a whole are analyzed to determine whether any element, or combination of elements, is sufficient to ensure that the claims amount to significantly more than the exception.
Step 2B
Regarding “A non-transitory machine readable medium storing instructions, which when executed by one or more processors of a data storage system, cause an auto-heal service running on the data storage system to”, “subscribing to a pub/sub bus for a notification regarding the trigger event”, “after receiving the notification”, “subscribing to a pub/sub bus for the notification regarding the trigger event”, “wherein the data storage system comprises a distributed storage system in a form of a cluster of a plurality of nodes and wherein the auto-heal service runs on a primary node of the plurality of nodes”, “A data storage system”, “one or more processors”, and “instructions that when executed by the one or more processors cause the data storage system to” the examiner submits that these additional limitations are referencing generic computer components and merely includes instructions to implement the abstract idea on a computer, or merely uses a computer as a tool to perform the abstract idea.
Regarding “received by a vendor of the data storage system from data storage systems of the vendor that are of a same or similar class and type of the data storage system”, “after receiving an indication the remediation is authorized by the administrative user”, “wherein the update is delivered to the data storage system out-of-cycle with a release schedule for software of the data storage system”, “wherein the update is delivered out-of-cycle with a release schedule for software of the data storage system”, and “receiving, by an auto-heal service running on a data storage system, a notification regarding an event representing a trigger event or a scheduled risk check, wherein the trigger event is indicative of a first risk to which the data storage system is potentially exposed and wherein the scheduled risk check indicates a periodic check is to be performed for a second risk to which the data storage system is potentially exposed”, the examiner submits that these additional limitations could simply refer to as merely storing or retrieving data information in memory. Additionally, some of these elements are merely further specifying the type of data that is received or stored. Therefore, in support of this conclusion, see MPEP 2106.05(d)(II) which states that courts have recognized storing and retrieving information in memory are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity.
Regarding “automatically execute one or more remediation actions that implement the remediation”, the examiner submits that this additional limitation is viewed as insignificant extra-solution activity in line with MPEP 2106.05(g), “cutting hair after first determining the hair style”, wherein the mental process decides what to do and this is merely the end step of the mental process using generic hardware which was addressed above.
Thus, taken alone, the additional elements do not amount to significantly more than the exception.
Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. For example, there is no indication that the combination of elements improves the functioning of a computer or improves any other technology.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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-3, 5-13, 15-20, and 22-25 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication No. 2009/0113248 to Bock et al. (“Bock”) in view of U.S. Patent No. 12,197,418 to Vijayvargiya et al. ("Vijayvargiya").
Regarding claim 1, Bock teaches:
A non-transitory machine readable medium storing instructions, which when executed by one or more processors of a data storage system, cause an auto-heal service running on the data storage system to:
mapping the trigger event to a set of one or more rules defining one or more conditions that are indicative of a root cause of the risk (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”), wherein the one or more rules are derived at least in part based on telemetry data received by a vendor of the data storage system from data storage systems of the vendor that are of a same or similar class and type of the data storage system (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”; and Paragraph [0026], “Additionally, FTA data store 125 may include any other data which may be used in troubleshooting a fault event, for example user notations, static documentation, historical records of previous fault events, and the like”; wherein the claims do not specify that the historical data used does not need to be from a different data storage system and therefore historical data from the same data storage system will be of the same class and type); and
evaluating the set of one or more rules with respect to one or more of historical data and a current state of the data storage system (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”; wherein the group of historical or current state data only needs to comprise one and the current state is used); and
based on the set of one or more rules, identify availability of a remediation associated with the risk that addresses or mitigates the risk (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action”).
However, Bock does not appear to explicitly teach:
monitor for a trigger event potentially indicative of a risk to which the data storage system is exposed by subscribing to a pub/sub bus for a notification regarding the trigger event;
after receiving the notification, determine existence of the risk by:
However, in the same field of endeavor, Vijayvargiya teaches:
monitor for a trigger event potentially indicative of a risk to which the data storage system is exposed by subscribing to a pub/sub bus for a notification regarding the trigger event (Vijayvargiya: Col. 14, lines 59-64, “At time point 12, an alarm action can be triggered such as publishing a notification to a messaging channel of notification and event service 160. The messaging channel can be associated with a user or a set of users of provider network 100. A subscriber to the messaging channel can receive the published notification and take various actions”; wherein a pub/sub bus is interpreted as any communication channel that has subscribing and publishing mechanism);
after receiving the notification, determine existence of the risk (Vijayvargiya: Col. 15, lines 8-18, “The user receiving the notification can take various additional actions. For example, if the user is responsible for operating or administering anomaly detection service 150, the user can investigate potential causes of the regression. For example, the user might determine that an upgrade, change, or reconfiguration was made to one or more of anomaly detection algorithms 152 or one or more anomaly detection models 153 between time points 9 and 10. In this case, the user can reverse (roll back) the upgrade, change, or reconfiguration to the previous version(s) of the algorithm(s) or model(s)”) by:
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Bock by receiving a notification from a pub/sub bus regarding a potential risk, as taught by Vijayvargiya. One of ordinary skill in the art would have been motivated to use the methods of Vijayvargiya because it would improve the ability to precisely detect anomalies in the software efficiently. (Vijayvargiya: Col. 1, lines 12-27).
Regarding claim 2, the Bock/Vijayvargiya teaches all of the elements of claim 1 and further teaches:
cause an administrative user of the data storage system to be notified of the risk and the remediation via a graphical user interface associated with the data storage system (Bock: Paragraph [0045], “For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470. However, if an automated corrective action is not available, then at step 455, the user may be presented with the root cause identified at step 430, as well as any possible corrective actions specified in FTA data. For example, the user may use the troubleshooting console 136 to view a root cause and corrective actions parsed from the FTA metadata 124 by FTA parser 134”); and
after receiving an indication the remediation is authorized by the administrative user, execute one or more remediation actions that implement the remediation (Bock: Paragraph [0043], “At step 465, the user may receive an indication of the appropriate user commands or actions for performing corrective actions in order to resolve the fault condition. For example, the user may select user command 334 in troubleshooting console 136, as shown in FIG. 3. At step 470, any corrective actions may be performed. The corrective actions performed at step 470 may include actions selected by the user at step 465”).
Regarding claim 3, the Bock/Vijayvargiya teaches all of the elements of claim 1 and further teaches:
wherein the instructions further cause the auto-heal service to automatically execute one or more remediation actions that implement the remediation (Bock: Paragraph [0045], “For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470”).
Regarding claim 5, the Bock/Vijayvargiya teaches all of the elements of claim 1 and further teaches:
wherein the second risk represents a misconfiguration of the data storage system, an issue associated with an environment in which the data storage system operates that might impact the data storage system, a security issue relating to the data storage system, a performance issue relating to the data storage system (Bock: Fig. 3, #322; and Paragraph [0034], “Illustratively, navigation section 320 includes a tree view 322, which may be configured according to the FTA data files. That is, the various levels of tree view 320 may correspond to the levels of a fault tree (i.e., top events, intermediate events, and root causes) included in the FTA data files. In this example, the user has selected a root cause 325 in tree view 320, labeled “MAX CONNECTIONS EXCEEDED.” As a result, instructions section 330 displays instructions describing symptoms, diagnosis, and corrective actions for the selected root cause 325”), a compliance issue relating to the data storage system, or a capacity issue relating to the data storage system.
Regarding claim 6, the Bock/Vijayvargiya teaches all of the elements of claim 1 and further teaches:
wherein the instructions further cause the auto-heal service to update a rule set of which the set of one or more rules are a part, wherein the update is delivered to the data storage system out-of-cycle with a release schedule for software of the data storage system (Bock: Paragraph [0043], “At step 480, the corrective actions performed at step 470 may be recorded in FTA data. For example, corrective actions may be stored in FTA data store 125. Such records of corrective actions may be used, e.g., in determining corrective actions for future fault events. Optionally, corrective actions may also be stored in a community FTA data store 150, so as to assist other members of the community in determining corrective actions to similar fault events”).
Regarding claim 7, the Bock/Vijayvargiya teaches all of the elements of claim 1 and further teaches:
wherein the instructions further cause the auto-heal service to update to a remediation set of which the remediation is a part, wherein the update is delivered out-of-cycle with a release schedule for software of the data storage system (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”).
Regarding claim 8, the Bock/Vijayvargiya teaches all of the elements of claim 7 and further teaches:
wherein the remediation set is derived at least in part based on the telemetry data (Bock: Paragraph [0042], “On the other hand, if it is determined at step 430 that a root cause can be identified, then at step 450, where it is determined whether an automated corrective action is available. For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470. However, if an automated corrective action is not available, then at step 455, the user may be presented with the root cause identified at step 430, as well as any possible corrective actions specified in FTA data”).
Regarding claim 9, Bock teaches:
A method comprising:
identifying a set of one or more rules defining one or more conditions that are indicative of a root cause of the first risk (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”) or the second risk, wherein the one or more rules are derived at least in part based on telemetry data received by a vendor of the data storage system from data storage systems of the vendor that are of a same or similar class and type of the data storage system (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”; and Paragraph [0026], “Additionally, FTA data store 125 may include any other data which may be used in troubleshooting a fault event, for example user notations, static documentation, historical records of previous fault events, and the like”; wherein the claims do not specify that the historical data used does not need to be from a different data storage system and therefore historical data from the same data storage system will be of the same class and type); and
evaluating the set of one or more rules with respect to one or more of historical data and a current state of the data storage system (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”; wherein the group of historical or current state data only needs to comprise one and the current state is used); and
based on the set of one or more rules, identify availability of a remediation that addresses or mitigates the first risk (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action”) or the second risk.
However, Bock does not appear to explicitly teach:
receiving, by an auto-heal service running on a data storage system, a notification regarding an event representing a trigger event or a scheduled risk check, wherein the trigger event is indicative of a first risk to which the data storage system is potentially exposed and wherein the scheduled risk check indicates a periodic check is to be performed for a second risk to which the data storage system is potentially exposed;
after receiving the notification, determine existence of the first risk or the second risk by:
However, in the same field of endeavor, Vijayvargiya teaches:
receiving, by an auto-heal service running on a data storage system, a notification regarding an event representing a trigger event or a scheduled risk check, wherein the trigger event is indicative of a first risk to which the data storage system is potentially exposed (Vijayvargiya: Col. 14, lines 59-64, “At time point 12, an alarm action can be triggered such as publishing a notification to a messaging channel of notification and event service 160. The messaging channel can be associated with a user or a set of users of provider network 100. A subscriber to the messaging channel can receive the published notification and take various actions”; wherein a pub/sub bus is interpreted as any communication channel that has subscribing and publishing mechanism) and wherein the scheduled risk check indicates a periodic check is to be performed for a second risk to which the data storage system is potentially exposed;
after receiving the notification, determine existence of the first risk (Vijayvargiya: Col. 15, lines 8-18, “The user receiving the notification can take various additional actions. For example, if the user is responsible for operating or administering anomaly detection service 150, the user can investigate potential causes of the regression. For example, the user might determine that an upgrade, change, or reconfiguration was made to one or more of anomaly detection algorithms 152 or one or more anomaly detection models 153 between time points 9 and 10. In this case, the user can reverse (roll back) the upgrade, change, or reconfiguration to the previous version(s) of the algorithm(s) or model(s)”) or the second risk by:
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Bock by receiving a notification regarding a potential risk, as taught by Vijayvargiya. One of ordinary skill in the art would have been motivated to use the methods of Vijayvargiya because it would improve the ability to precisely detect anomalies in the software efficiently. (Vijayvargiya: Col. 1, lines 12-27).
Regarding claim 10, the Bock/Vijayvargiya teaches all of the elements of claim 9 and further teaches:
causing an administrative user of the data storage system to be notified of the first risk or the second risk and the remediation via a graphical user interface associated with the data storage system (Bock: Paragraph [0045], “For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470. However, if an automated corrective action is not available, then at step 455, the user may be presented with the root cause identified at step 430, as well as any possible corrective actions specified in FTA data. For example, the user may use the troubleshooting console 136 to view a root cause and corrective actions parsed from the FTA metadata 124 by FTA parser 134”); and
after receiving an indication the remediation is authorized by the administrative user, executing one or more remediation actions that implement the remediation (Bock: Paragraph [0043], “At step 465, the user may receive an indication of the appropriate user commands or actions for performing corrective actions in order to resolve the fault condition. For example, the user may select user command 334 in troubleshooting console 136, as shown in FIG. 3. At step 470, any corrective actions may be performed. The corrective actions performed at step 470 may include actions selected by the user at step 465”).
Regarding claim 11, the Bock/Vijayvargiya teaches all of the elements of claim 9 and further teaches:
automatically executing one or more remediation actions that implement the remediation (Bock: Paragraph [0045], “For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470”).
Regarding claim 12, the Bock/Vijayvargiya teaches all of the elements of claim 9 and further teaches:
wherein the second risk represents a misconfiguration of the data storage system, an issue associated with an environment in which the data storage system operates that might impact the data storage system, a security issue relating to the data storage system, a performance issue relating to the data storage system (Bock: Fig. 3, #322; and Paragraph [0034], “Illustratively, navigation section 320 includes a tree view 322, which may be configured according to the FTA data files. That is, the various levels of tree view 320 may correspond to the levels of a fault tree (i.e., top events, intermediate events, and root causes) included in the FTA data files. In this example, the user has selected a root cause 325 in tree view 320, labeled “MAX CONNECTIONS EXCEEDED.” As a result, instructions section 330 displays instructions describing symptoms, diagnosis, and corrective actions for the selected root cause 325”), a compliance issue relating to the data storage system, or a capacity issue relating to the data storage system.
Regarding claim 13, the Bock/Vijayvargiya teaches all of the elements of claim 9 and further teaches:
further comprising prior to said receiving subscribing to a pub/sub bus for the notification regarding the trigger event (Vijayvargiya: Col. 14, lines 59-64, “At time point 12, an alarm action can be triggered such as publishing a notification to a messaging channel of notification and event service 160. The messaging channel can be associated with a user or a set of users of provider network 100. A subscriber to the messaging channel can receive the published notification and take various actions”; wherein a pub/sub bus is interpreted as any communication channel that has subscribing and publishing mechanism).
Regarding claim 15, the Bock/Vijayvargiya teaches all of the elements of claim 9 and further teaches:
wherein the data storage system comprises a distributed storage system in a form of a cluster of a plurality of nodes and wherein the auto-heal service runs on a primary node of the plurality of nodes (Bock: Paragraph [0023], “In one embodiment, management server 120 may be configured to detect faults occurring in application servers 110. More specifically, management server 120 may receive (or send) data signals from (or to) application servers 110 over the network 115, and may use those data signals (or responses) to detect a fault in application server 110. Management server 120 may also be configured to enable users to troubleshoot any faults detected in application server 110. As shown, management server 120 includes a CPU 122, which obtains instructions and data via a bus 121 from storage 123 and memory 130”; wherein each application service is a node and there are a plurality of them as well as a management server for handling the “auto-healing” service which can be identified as a primary node in the system).
Regarding claim 16, the Bock/Vijayvargiya teaches all of the elements of claim 9 and further teaches:
further comprising applying an update to a rule set of which the set of one or more rules are a part, wherein the update is delivered to the data storage system out-of-cycle with a release schedule for software of the data storage system (Bock: Paragraph [0043], “At step 480, the corrective actions performed at step 470 may be recorded in FTA data. For example, corrective actions may be stored in FTA data store 125. Such records of corrective actions may be used, e.g., in determining corrective actions for future fault events. Optionally, corrective actions may also be stored in a community FTA data store 150, so as to assist other members of the community in determining corrective actions to similar fault events”).
Regarding claim 17, the Bock/Vijayvargiya teaches all of the elements of claim 9 and further teaches:
further comprising applying an update to a remediation set of which the remediation is a part, wherein the update is delivered out-of-cycle with a release schedule for software of the data storage system (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”).
Regarding claim 18, the Bock/Vijayvargiya teaches all of the elements of claim 17 and further teaches:
wherein the remediation set is derived at least in part based on the telemetry data (Bock: Paragraph [0042], “On the other hand, if it is determined at step 430 that a root cause can be identified, then at step 450, where it is determined whether an automated corrective action is available. For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470. However, if an automated corrective action is not available, then at step 455, the user may be presented with the root cause identified at step 430, as well as any possible corrective actions specified in FTA data”).
Regarding claim 19, Bock teaches:
A data storage system comprising:
one or more processors; and
instructions that when executed by the one or more processors cause the data storage system to:
mapping the trigger event to a set of one or more rules defining one or more conditions that are indicative of a root cause of the risk (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”), wherein the one or more rules are derived at least in part based on telemetry data received by a vendor of the data storage system from data storage systems of the vendor that are of a same or similar class and type of the data storage system (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”; and Paragraph [0026], “Additionally, FTA data store 125 may include any other data which may be used in troubleshooting a fault event, for example user notations, static documentation, historical records of previous fault events, and the like”; wherein the claims do not specify that the historical data used does not need to be from a different data storage system and therefore historical data from the same data storage system will be of the same class and type); and
evaluating the set of one or more rules with respect to one or more of historical data and a current state of the data storage system (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”; wherein the group of historical or current state data only needs to comprise one and the current state is used); and
based on the set of one or more rules, identify availability of a remediation associated with the risk that addresses or mitigates the risk (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action”).
However, Bock does not appear to explicitly teach:
monitor for a trigger event potentially indicative of a risk to which the data storage system is exposed by subscribing to a pub/sub bus for a notification regarding the trigger event;
after receiving the notification, determine existence of the risk by:
However, in the same field of endeavor, Vijayvargiya teaches:
monitor for a trigger event potentially indicative of a risk to which the data storage system is exposed by subscribing to a pub/sub bus for a notification regarding the trigger event (Vijayvargiya: Col. 14, lines 59-64, “At time point 12, an alarm action can be triggered such as publishing a notification to a messaging channel of notification and event service 160. The messaging channel can be associated with a user or a set of users of provider network 100. A subscriber to the messaging channel can receive the published notification and take various actions”; wherein a pub/sub bus is interpreted as any communication channel that has subscribing and publishing mechanism);
after receiving the notification, determine existence of the risk (Vijayvargiya: Col. 15, lines 8-18, “The user receiving the notification can take various additional actions. For example, if the user is responsible for operating or administering anomaly detection service 150, the user can investigate potential causes of the regression. For example, the user might determine that an upgrade, change, or reconfiguration was made to one or more of anomaly detection algorithms 152 or one or more anomaly detection models 153 between time points 9 and 10. In this case, the user can reverse (roll back) the upgrade, change, or reconfiguration to the previous version(s) of the algorithm(s) or model(s)”) by:
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Bock by receiving a notification from a pub/sub bus regarding a potential risk, as taught by Vijayvargiya. One of ordinary skill in the art would have been motivated to use the methods of Vijayvargiya because it would improve the ability to precisely detect anomalies in the software efficiently. (Vijayvargiya: Col. 1, lines 12-27).
Regarding claim 20, the Bock/Vijayvargiya teaches all of the elements of claim 19 and further teaches:
wherein the instructions further cause the data storage system to:
cause an administrative user of the data storage system to be notified of the risk and the remediation via a graphical user interface associated with the data storage system (Bock: Paragraph [0045], “For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470. However, if an automated corrective action is not available, then at step 455, the user may be presented with the root cause identified at step 430, as well as any possible corrective actions specified in FTA data. For example, the user may use the troubleshooting console 136 to view a root cause and corrective actions parsed from the FTA metadata 124 by FTA parser 134”); and
after receiving an indication the remediation is authorized by the administrative user, execute one or more remediation actions that implement the remediation (Bock: Paragraph [0043], “At step 465, the user may receive an indication of the appropriate user commands or actions for performing corrective actions in order to resolve the fault condition. For example, the user may select user command 334 in troubleshooting console 136, as shown in FIG. 3. At step 470, any corrective actions may be performed. The corrective actions performed at step 470 may include actions selected by the user at step 465”).
Regarding claim 22, the Bock/Vijayvargiya teaches all of the elements of claim 19 and further teaches:
wherein the second risk represents a misconfiguration of the data storage system, an issue associated with an environment in which the data storage system operates that might impact the data storage system, a security issue relating to the data storage system, a performance issue relating to the data storage system (Bock: Fig. 3, #322; and Paragraph [0034], “Illustratively, navigation section 320 includes a tree view 322, which may be configured according to the FTA data files. That is, the various levels of tree view 320 may correspond to the levels of a fault tree (i.e., top events, intermediate events, and root causes) included in the FTA data files. In this example, the user has selected a root cause 325 in tree view 320, labeled “MAX CONNECTIONS EXCEEDED.” As a result, instructions section 330 displays instructions describing symptoms, diagnosis, and corrective actions for the selected root cause 325”), a compliance issue relating to the data storage system, or a capacity issue relating to the data storage system.
Regarding claim 23, the Bock/Vijayvargiya teaches all of the elements of claim 19 and further teaches:
wherein the instructions further cause the data storage system to update a rule set of which the set of one or more rules are a part, wherein the update is delivered to the data storage system out-of-cycle with a release schedule for software of the data storage system (Bock: Paragraph [0043], “At step 480, the corrective actions performed at step 470 may be recorded in FTA data. For example, corrective actions may be stored in FTA data store 125. Such records of corrective actions may be used, e.g., in determining corrective actions for future fault events. Optionally, corrective actions may also be stored in a community FTA data store 150, so as to assist other members of the community in determining corrective actions to similar fault events”).
Regarding claim 24, the Bock/Vijayvargiya teaches all of the elements of claim 19 and further teaches:
wherein the instructions further cause the data storage system to update to a remediation set of which the remediation is a part, wherein the update is delivered out-of-cycle with a release schedule for software of the data storage system (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action. Alternatively, if a root cause cannot be determined, the user may be presented with additional FTA metadata and any relevant data parameters in the troubleshooting console, to assist the user in determining the root cause of the fault event. The FTA metadata may be generated by a supplier of software included in the computer system, by an organization owning the computer system, or by a community of users sharing FTA information”).
Regarding claim 25, the Bock/Vijayvargiya teaches all of the elements of claim 24 and further teaches:
wherein the remediation set is derived at least in part based on the telemetry data (Bock: Paragraph [0042], “On the other hand, if it is determined at step 430 that a root cause can be identified, then at step 450, where it is determined whether an automated corrective action is available. For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470. However, if an automated corrective action is not available, then at step 455, the user may be presented with the root cause identified at step 430, as well as any possible corrective actions specified in FTA data”).
Claims 4, 14, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Bock in view of Vijayvargiya and further in view of U.S. Publication No. 2021/0268265 to Eder et al. (“Eder”).
Regarding claim 4, the Bock/Vijayvargiya combination teaches all of the elements of claim 1 and further teaches:
based on the second set of one or more rules, identify availability of a second remediation associated with the second risk that addresses or mitigates the second risk (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action”; and Paragraph [0045], “For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470. However, if an automated corrective action is not available, then at step 455, the user may be presented with the root cause identified at step 430, as well as any possible corrective actions specified in FTA data. For example, the user may use the troubleshooting console 136 to view a root cause and corrective actions parsed from the FTA metadata 124 by FTA parser 134”);
determine the second remediation is authorized for automated performance without requiring authorization by the administrative user (Bock: Paragraph [0045], “For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470”);
However, the Bock/Vijayvargiya combination does not appear to explicitly teach:
determine existence of a second risk to which the data storage system is potentially exposed by evaluating a second set of one or more rules on a periodic schedule;
However, in the same field of endeavor, Eder teaches:
determine existence of a second risk to which the data storage system is potentially exposed by evaluating a second set of one or more rules on a periodic schedule (Eder: Paragraph [0048], “Another example of a safety critical fault that could be detected by these diagnostic safety mechanisms is a condition in which memory of the implantable component has experienced a hard fault/error (e.g., determined by periodical reading back blocks of program memory after it has been loaded from NVM and performing a CRC on the read back blocks of program memory)”);
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Bock/Vijayvargiya combination by determining a risk based on evaluating rules on a periodic schedule, as taught by Eder. One of ordinary skill in the art would have been motivated to use the methods of Eder because it would allow the system to detect safety critical faults therefore assisting with reliability. (Eder: Paragraph [0048]).
Regarding claim 14, the Bock/Vijayvargiya combination teaches all of the elements of claim 9. However, the Bock/Vijayvargiya combination does not appear to explicitly teach:
wherein a schedule for the periodic check is associated with the set of one or more rules.
However, in the same field of endeavor, Eder teaches:
wherein a schedule for the periodic check is associated with the set of one or more rules (Eder: Paragraph [0048], “Another example of a safety critical fault that could be detected by these diagnostic safety mechanisms is a condition in which memory of the implantable component has experienced a hard fault/error (e.g., determined by periodical reading back blocks of program memory after it has been loaded from NVM and performing a CRC on the read back blocks of program memory)”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Bock/Vijayvargiya combination by determining a risk based on evaluating rules on a periodic schedule, as taught by Eder. One of ordinary skill in the art would have been motivated to use the methods of Eder because it would allow the system to detect safety critical faults therefore assisting with reliability. (Eder: Paragraph [0048]).
Regarding claim 21, the Bock/Vijayvargiya combination teaches all of the elements of claim 19 and further teaches:
based on the second set of one or more rules, identify availability of a second remediation associated with the second risk that addresses or mitigates the second risk (Bock: Paragraph [0016], “Embodiments of the invention provide techniques for troubleshooting of computer systems using FTA. In one embodiment, data parameters describing a status of a system may be monitored to determine the existence of a fault. In the event of a fault, FTA metadata may be evaluated to attempt to determine a root cause of the fault. If a root cause can be determined, such cause may be presented to a user in a troubleshooting console, or may be used to trigger an automated corrective action”; and Paragraph [0045], “For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470. However, if an automated corrective action is not available, then at step 455, the user may be presented with the root cause identified at step 430, as well as any possible corrective actions specified in FTA data. For example, the user may use the troubleshooting console 136 to view a root cause and corrective actions parsed from the FTA metadata 124 by FTA parser 134”);
determine the second remediation is authorized for automated performance without requiring authorization by the administrative user (Bock: Paragraph [0045], “For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470”);
execute one or more remediation actions that implement the second remediation (Bock: Paragraph [0045], “For example, the fault monitor 132 may determine whether a corrective action is specified in the fault tree based on the detected fault condition and the appropriate monitored parameters. Further, fault monitor 132 may determine whether the corrective action can be performed automatically (i.e., without user intervention). If an automated corrective action is available, such corrective auction may be performed at step 470”).
However, the Bock/Vijayvargiya combination does not appear to explicitly teach:
determine existence of a second risk to which the data storage system is potentially exposed by evaluating a second set of one or more rules on a periodic schedule;
However, in the same field of endeavor, Eder teaches:
determine existence of a second risk to which the data storage system is potentially exposed by evaluating a second set of one or more rules on a periodic schedule (Eder: Paragraph [0048], “Another example of a safety critical fault that could be detected by these diagnostic safety mechanisms is a condition in which memory of the implantable component has experienced a hard fault/error (e.g., determined by periodical reading back blocks of program memory after it has been loaded from NVM and performing a CRC on the read back blocks of program memory)”);
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Bock/Vijayvargiya combination by determining a risk based on evaluating rules on a periodic schedule, as taught by Eder. One of ordinary skill in the art would have been motivated to use the methods of Eder because it would allow the system to detect safety critical faults therefore assisting with reliability. (Eder: Paragraph [0048]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. (). The following statement is a brief summary of very pertinent art that was not relied upon:
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Matthew N Putaraksa whose telephone number is (303)297-4365. The examiner can normally be reached on Monday-Thursday 7:00am-5:00pm MT.
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, Matt Kim can be reached on 571-272-4182. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MATTHEW N PUTARAKSA/Examiner, Art Unit 2114
Prosecution Insights