DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to the Amendment filed on 6/22/2026. Claims 1-20 are pending in the case. Claims 1, 7, 12, and 17 are independent claims.
Response to Arguments
Applicant’s amendments regarding the objections are persuasive. These objections are respectfully withdrawn.
Applicant’s prior art arguments have been fully considered but they are not persuasive.
Applicant argues that “Davis does not disclose distributing rule sets that define which metrics are to be collected from receiving entities” (page 8). Examiner respectfully disagrees:
The previously cited “initial parameters” are detailed in the immediately preceding paragraph as “Before the service is activated for the first time for a given fleet of managed devices, various initial parameters of the service may be identified in the depicted embodiment (element 801). The parameters may include the number of layers of the rule processing unit hierarchy, the fan-out at the different layers of the hierarchy, and the metadata formatting methodology to be used at the RPUs. In addition, the set of events, metrics and devices to be managed, the acceptable ranges of metrics values according to an initial set of rules, and the overall resource management goals may be identified in various embodiments” (column 16 lines 9-20, emphases added). The previously cited “initial parameters” clearly define which metrics are to be managed from receiving entities and they are distributed as rule sets.
Said metric management includes collecting and reporting the metrics (“metadata may be generated and transmitted to the repository”, column 9 lines 39-40). Therefore the previously cited “initial parameters” define which metrics are to be collected and reported.
Applicant argues that “modifying corrective-action rules is not equivalent to generating a second set of metrics [sic] corresponding to operation of receiving entities, as recited in the independent claims” (page 9). Examiner respectfully disagrees:
As noted above, Davis’ rules include collecting and reporting the metrics. The claims do not require the second rule set to be generated from scratch without reference to the first rule set. A modified set is a second set. The claims do not require the second rule set to be distributed whole without reference to the first rule set previously distributed. A delta update is an update. Therefore modifying corrective-action rules is generating a second set of rules.
Only claim 7 recites any variation of “generating,” therefore it is not clear whether or how this argument might apply to the other independent claims.
Applicant argues that “Davis merely discloses using machine learning models to evaluate historical event-action metadata and recommend modifications to corrective-action rules” (page 9). Examiner respectfully disagrees with the term “merely.” Davis discloses both this and, as noted above, rules that define which metrics are to be collected and reported.
Applicant argues that “instantiating RPUs to respond to metrics/events is not equivalent to distributing a rule set that indicates a set of metrics to be collected” (page 9). Examiner respectfully notes that the full citation in the Office action includes the “initial parameters” which, as noted above, are rules which include collecting and reporting the metrics.
Applicant argues that “modifying the number of RPUs is not equivalent to dynamically changing telemetry collection from differing numbers of receiving entities based on differing machine-learning-generated metric collection rule sets” (page 10). Examiner respectfully disagrees:
Instantiating a new RPU dynamically increases telemetry collection by however many targeted devices the new RPU is assigned to monitor. The full citation in the Office action specifies this is “based on the results of the machine learning models,” column 5 lines 50-51).
Decommissioning an existing RPU dynamically decreases telemetry collection by however many targeted devices the RPU was monitoring. The full citation in the Office action specifies this is “based on the results of the machine learning models,” column 5 lines 50-51).
Applicant argues that “the cited portions of Davis do not disclose evaluating a trigger condition indicating a change in operational conditions using machine learning techniques” (page 10). Examiner respectfully disagrees:
As previously cited, Davis discloses “During a particular iteration of the execution of rule set 450, an initial value of the metric may be obtained, and the first rule of the set (rule #1) may be applied to the initial value. For example, if the metric does not meet one or more acceptance criteria, an action A1 may be initiated. If, after the application of rule #1, the metric value returns to a stable or acceptable range (as detected in element 402), the rule set execution iteration may be exited as indicated in element 490. Otherwise, rule #2 may be triggered, which may result in another action A2” (column 13 lines 13-22). This is evaluating a trigger condition indicating a change in operational conditions.
As previously cited, Davis uses machine learning to analyze the metrics (“an input data set comprising metadata generated by one or more RPUs during some time interval may be identified for a machine learning model by an event-action analyzer,” column 5 lines 43-46).
Applicant argues that “Davis’s disclosure relating to escalation messages does not disclose transmitting indications of trigger conditions as recited in claims 16 and 20. Rather, Davis transmits escalation messages after determining that corrective actions failed to satisfy success criteria” (pages 10-11). Examiner respectfully disagrees. Applicant admits that Davis sometimes transmits indications of trigger conditions, which is a disclosure of transmitting indications of trigger conditions.
Applicant argues that “The Office Action then cites Gregorio for predicting future infrastructure health scores using machine learning techniques” (page 11). Examiner respectfully disagrees. The Office action cites Gregorio for the general concept of predicting diminished performance before it actually happens. This simple, abstract idea is embodied in a wide variety of machine learning applications and is a straightforward modification of Davis.
Applicant argues that “the Office Action effectively extracts corrective-action rule optimization from Davis, and predictive analytics from Gregorio, and then reconstructs Applicant’s claimed adaptive telemetry collection framework using Applicant’s own disclosure as a roadmap. Such reasoning is improper hindsight reconstruction” (page 12). Examiner respectfully disagrees. As described above, the Office action cites the adaptive telemetry collection portions of Davis and applies the common and straightforward concept of prediction.
Applicant argues that “Neither reference is directed to adaptive telemetry acquisition or machine-learning-driven modification of metric collection policies” (page 12). Examiner respectfully disagrees. As described above, Davis is directed to adaptive telemetry acquisition and machine-learning-driven modification of metric collection policies.
Applicant argues that “the claims specifically recite dynamically generating and distributing rule sets that define which metrics are collected from receiving entities based on machine-learning analysis of previously collected metric data. Neither Davis nor Gregorio discloses or suggests this functionality” (page 12. Examiner respectfully disagrees:
As described above, Davis is directed to dynamically generating and distributing rule sets that define which metrics are collected from receiving entities based on machine-learning analysis of previously collected metric data.
Only claim 7 recites any variation of “dynamically” or “generating,” therefore it is not clear whether or how this argument might apply to the other independent claims.
Applicant argues that “The Office Action further fails to provide an articulated rationale explaining why a person of ordinary skill in the art would have modified the corrective-action escalation framework of Davis using the infrastructure-health prediction techniques of Gregorio in order to arrive at Applicant’s claimed adaptive metric collection architecture” (page 12). This appears to be a reference to MPEP § 2143(I)(G). Examiner respectfully notes that § 2143(I) recites several independent rationales and example (G) is not the only option. Examiner further notes that each obviousness rejection expressly cites example (A).
Applicant argues that “the Office Action suggests incorporating predictive analysis into Davis. However, even if such modification were made, the resulting system would still merely predict infrastructure conditions within the remediation framework of Davis. It still would not generate revised metric-selection rule sets or dynamically adapt telemetry collection behavior as claimed” (page 12). Examiner respectfully disagrees. As described above, Davis alone teaches revised metric-selection rule sets and dynamically adapting telemetry collection behavior as claimed.
Therefore, Examiner respectfully asserts that the cited art sufficiently teaches the limitations recited in the amended claims.
Claim Rejections - 35 U.S.C. § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 3-7, and 9-20 are rejected under 35 U.S.C. § 102(a)(2) as being anticipated by Davis et al. (US 11,855,849 B1, hereinafter Davis).
As to independent claim 1, Davis discloses a management node in a distributed storage system (“The RPUs of the RMS 243 may be distributed among the devices of various other services, such as the VCS 203, storage/database services 223 and so on,” column 11 lines 13-16), the management node comprising:
a memory system (“computing device 9000 includes one or more processors 9010 coupled to a system memory 9020,” column 19 lines 59-60); and
one or more processors coupled with the memory system (“computing device 9000 includes one or more processors 9010 coupled to a system memory 9020,” column 19 lines 59-60), the one or more processors to:
distribute a first rule set that indicates to receiving entities within the distributed storage system a first set of one or more metrics corresponding to operation of elements of the receiving entities (“After the initial parameters are identified, a collection of RPUs may be instantiated to respond to the metrics/events at targeted devices (element 804),” column 16 lines 33-35),
receive (“metadata may be generated and transmitted to the repository not only when events occur (such as when new values of metrics are obtained at leaf-level RPUs),” column 9 lines 39-42) metric data from the receiving entities based on the first rule set (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52),
distribute a second rule set in response to the received metric data, wherein the second rule set indicates to receiving entities within the distributed storage system a second set of one or more metrics corresponding to operation of elements of the receiving entities, and wherein the metrics of the second rule set are determined utilizing machine learning techniques and based received metric data corresponding to the first rule set (figure 8 steps 810-819; “an input data set comprising metadata generated by one or more RPUs during some time interval may be identified for a machine learning model by an event-action analyzer. The output produced by the machine learning models may be used to determine one or more rule modification recommendations for a set of RPUs, which may be then be propagated to the RPUs,” column 5 lines 43-50), and
receive (“metadata may be generated and transmitted to the repository not only when events occur (such as when new values of metrics are obtained at leaf-level RPUs),” column 9 lines 39-42) metric data from the receiving entities based on the second rule set (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52).
As to dependent claim 3, Davis further discloses a system wherein the first rule set has a first set of reporting (“metadata may be generated and transmitted to the repository not only when events occur (such as when new values of metrics are obtained at leaf-level RPUs),” column 9 lines 39-42) frequencies for metric data collected according to the first rule set and the second rule set has a second set of reporting frequencies for metric data collected according to the second rule set (“Any of a number of different types of corrective actions may be attempted in different embodiments, such as for example changing the maximum rate at which work requests of a specified type are to be accepted at the MSDs, restarting a process or thread, restarting a host, increasing/decreasing memory allocated for a certain type of task, increasing/decreasing minimum wait times between certain types of operations, and so on. In some embodiments, a rule may trigger an action which increases (or decreases) the level of detail of monitoring (locally or globally) a set of metrics, e.g., based on one or more leading indicators. This may be considered an optimization of the core monitoring functionality of the service—in effect, implementing such a rule may represent monitoring a metric relatively crudely until the metric gets close enough to a threshold that closer scrutiny is required. The level of detail may be changed, for example, by changing the frequency at which the metric is collected, by changing the precision of numeric values that are collected, by using a different tool or sensor to collect the metric, and so on.,” column 7 line 62 to column 8 line 15).
As to dependent claim 4, Davis further discloses a system wherein the first rule set has a first set of collection frequencies for metric data collected according to the first rule set and the second rule set has a second set of collection frequencies for metric data collected according to the second rule set (“Any of a number of different types of corrective actions may be attempted in different embodiments, such as for example changing the maximum rate at which work requests of a specified type are to be accepted at the MSDs, restarting a process or thread, restarting a host, increasing/decreasing memory allocated for a certain type of task, increasing/decreasing minimum wait times between certain types of operations, and so on. In some embodiments, a rule may trigger an action which increases (or decreases) the level of detail of monitoring (locally or globally) a set of metrics, e.g., based on one or more leading indicators. This may be considered an optimization of the core monitoring functionality of the service—in effect, implementing such a rule may represent monitoring a metric relatively crudely until the metric gets close enough to a threshold that closer scrutiny is required. The level of detail may be changed, for example, by changing the frequency at which the metric is collected, by changing the precision of numeric values that are collected, by using a different tool or sensor to collect the metric, and so on.,” column 7 line 62 to column 8 line 15).
As to dependent claim 5, Davis further discloses a system wherein the first rule set results in collection of metric data from a first number of receiving entities and the second rule set results in collection of metric data from a second number of receiving entities (“based on the results of the machine learning models, one or more new RPUs may be instantiated, existing RPUs may be decommissioned, the allowed pathways of communication among groups of RPUs may be modified, and so on.,” column 5 lines 50-54).
As to dependent claim 6, Davis further discloses a system wherein the one or more processors are further configured to distribute a third rule set in response to the received metric data, wherein the third rule set indicates to receiving entities within the distributed storage system a third set of one or more metrics corresponding to operation of elements of the receiving entities (“After the initial parameters are identified, a collection of RPUs may be instantiated to respond to the metrics/events at targeted devices (element 804),” column 16 lines 33-35), and wherein the metrics of the third rule set are determined utilizing machine learning techniques and based received metric data corresponding to the first rule set and received metric data corresponding to the second rule set (figure 8 steps 810-819; “an input data set comprising metadata generated by one or more RPUs during some time interval may be identified for a machine learning model by an event-action analyzer. The output produced by the machine learning models may be used to determine one or more rule modification recommendations for a set of RPUs, which may be then be propagated to the RPUs,” column 5 lines 43-50).
As to independent claim 7, Davis discloses a non-transitory computer readable storage medium having stored thereon instructions that, when executed by one or more processors (“computing device 9000 includes one or more processors 9010 coupled to a system memory 9020,” column 19 lines 59-60), cause the one or more processors to:
distribute to receiving entities within the distributed storage system (“The RPUs of the RMS 243 may be distributed among the devices of various other services, such as the VCS 203, storage/database services 223 and so on,” column 11 lines 13-16) an indication of a first set of one or more metrics corresponding to operation of elements of the receiving entities (“After the initial parameters are identified, a collection of RPUs may be instantiated to respond to the metrics/events at targeted devices (element 804),” column 16 lines 33-35);
receive (“metadata may be generated and transmitted to the repository not only when events occur (such as when new values of metrics are obtained at leaf-level RPUs),” column 9 lines 39-42) metric data from the receiving entities based on the first set of one or more metrics (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52);
generate, dynamically with machine learning techniques, an indication of a second set of one or more metrics corresponding to operation of elements of the receiving entities in response to a condition change in at least one of the receiving entities (figure 8 steps 810-819; “an input data set comprising metadata generated by one or more RPUs during some time interval may be identified for a machine learning model by an event-action analyzer. The output produced by the machine learning models may be used to determine one or more rule modification recommendations for a set of RPUs, which may be then be propagated to the RPUs,” column 5 lines 43-50);
distribute the indication of the second set of metrics to the receiving entities (figure 8 steps 810-819; “an input data set comprising metadata generated by one or more RPUs during some time interval may be identified for a machine learning model by an event-action analyzer. The output produced by the machine learning models may be used to determine one or more rule modification recommendations for a set of RPUs, which may be then be propagated to the RPUs,” column 5 lines 43-50); and
receive (“metadata may be generated and transmitted to the repository not only when events occur (such as when new values of metrics are obtained at leaf-level RPUs),” column 9 lines 39-42) metric data from the receiving entities based on the second set of one or more metrics (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52).
As to dependent claim 9, Davis further discloses a medium wherein the first rule set has a first set of reporting (“metadata may be generated and transmitted to the repository not only when events occur (such as when new values of metrics are obtained at leaf-level RPUs),” column 9 lines 39-42) frequencies for metric data collected according to the first rule set and the second rule set has a second set of reporting frequencies for metric data collected according to the second rule set (“Any of a number of different types of corrective actions may be attempted in different embodiments, such as for example changing the maximum rate at which work requests of a specified type are to be accepted at the MSDs, restarting a process or thread, restarting a host, increasing/decreasing memory allocated for a certain type of task, increasing/decreasing minimum wait times between certain types of operations, and so on. In some embodiments, a rule may trigger an action which increases (or decreases) the level of detail of monitoring (locally or globally) a set of metrics, e.g., based on one or more leading indicators. This may be considered an optimization of the core monitoring functionality of the service—in effect, implementing such a rule may represent monitoring a metric relatively crudely until the metric gets close enough to a threshold that closer scrutiny is required. The level of detail may be changed, for example, by changing the frequency at which the metric is collected, by changing the precision of numeric values that are collected, by using a different tool or sensor to collect the metric, and so on.,” column 7 line 62 to column 8 line 15).
As to dependent claim 10, Davis further discloses a medium wherein the first rule set has a first set of collection frequencies for metric data collected according to the first rule set and the second rule set has a second set of collection frequencies for metric data collected according to the second rule set (“Any of a number of different types of corrective actions may be attempted in different embodiments, such as for example changing the maximum rate at which work requests of a specified type are to be accepted at the MSDs, restarting a process or thread, restarting a host, increasing/decreasing memory allocated for a certain type of task, increasing/decreasing minimum wait times between certain types of operations, and so on. In some embodiments, a rule may trigger an action which increases (or decreases) the level of detail of monitoring (locally or globally) a set of metrics, e.g., based on one or more leading indicators. This may be considered an optimization of the core monitoring functionality of the service—in effect, implementing such a rule may represent monitoring a metric relatively crudely until the metric gets close enough to a threshold that closer scrutiny is required. The level of detail may be changed, for example, by changing the frequency at which the metric is collected, by changing the precision of numeric values that are collected, by using a different tool or sensor to collect the metric, and so on.,” column 7 line 62 to column 8 line 15).
As to dependent claim 11, Davis further discloses a medium wherein the first rule set results in collection of metric data from a first number of receiving entities and the second rule set results in collection of metric data from a second number of receiving entities (“based on the results of the machine learning models, one or more new RPUs may be instantiated, existing RPUs may be decommissioned, the allowed pathways of communication among groups of RPUs may be modified, and so on.,” column 5 lines 50-54).
As to independent claim 12, Davis discloses a node in a distributed storage system (“The RPUs of the RMS 243 may be distributed among the devices of various other services, such as the VCS 203, storage/database services 223 and so on,” column 11 lines 13-16) comprising:
a memory system (“computing device 9000 includes one or more processors 9010 coupled to a system memory 9020,” column 19 lines 59-60); and
one or more processors coupled with the memory system (“computing device 9000 includes one or more processors 9010 coupled to a system memory 9020,” column 19 lines 59-60), the one or more processors to:
collect data according to a first rule set (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52), wherein the rules in the first rule set indicate a first set of one or more metrics corresponding to operation of elements of the node (“After the initial parameters are identified, a collection of RPUs may be instantiated to respond to the metrics/events at targeted devices (element 804),” column 16 lines 33-35),
transmit (“metadata may be generated and transmitted to the repository not only when events occur (such as when new values of metrics are obtained at leaf-level RPUs),” column 9 lines 39-42) collected data corresponding to the first rule set to at least a management node in the distributed storage system (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52), wherein the transmission frequency is determined by the first rule set (“Any of a number of different types of corrective actions may be attempted in different embodiments, such as for example changing the maximum rate at which work requests of a specified type are to be accepted at the MSDs, restarting a process or thread, restarting a host, increasing/decreasing memory allocated for a certain type of task, increasing/decreasing minimum wait times between certain types of operations, and so on. In some embodiments, a rule may trigger an action which increases (or decreases) the level of detail of monitoring (locally or globally) a set of metrics, e.g., based on one or more leading indicators. This may be considered an optimization of the core monitoring functionality of the service—in effect, implementing such a rule may represent monitoring a metric relatively crudely until the metric gets close enough to a threshold that closer scrutiny is required. The level of detail may be changed, for example, by changing the frequency at which the metric is collected, by changing the precision of numeric values that are collected, by using a different tool or sensor to collect the metric, and so on.,” column 7 line 62 to column 8 line 15),
receive a second rule set, wherein the rules in the second rule set indicate a first set of one or more metrics corresponding to operation of elements of the node (figure 8 steps 810-819; “an input data set comprising metadata generated by one or more RPUs during some time interval may be identified for a machine learning model by an event-action analyzer. The output produced by the machine learning models may be used to determine one or more rule modification recommendations for a set of RPUs, which may be then be propagated to the RPUs,” column 5 lines 43-50),
collect data according to the second rule set (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52), and
transmit (“metadata may be generated and transmitted to the repository not only when events occur (such as when new values of metrics are obtained at leaf-level RPUs),” column 9 lines 39-42) collected data corresponding to the second rule set to the management node (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52), wherein the transmission frequency is determined by the second rule set and is different than the transmission frequency for the first rule set (“Any of a number of different types of corrective actions may be attempted in different embodiments, such as for example changing the maximum rate at which work requests of a specified type are to be accepted at the MSDs, restarting a process or thread, restarting a host, increasing/decreasing memory allocated for a certain type of task, increasing/decreasing minimum wait times between certain types of operations, and so on. In some embodiments, a rule may trigger an action which increases (or decreases) the level of detail of monitoring (locally or globally) a set of metrics, e.g., based on one or more leading indicators. This may be considered an optimization of the core monitoring functionality of the service—in effect, implementing such a rule may represent monitoring a metric relatively crudely until the metric gets close enough to a threshold that closer scrutiny is required. The level of detail may be changed, for example, by changing the frequency at which the metric is collected, by changing the precision of numeric values that are collected, by using a different tool or sensor to collect the metric, and so on.,” column 7 line 62 to column 8 line 15).
As to dependent claim 13, Davis further discloses a system wherein the first rule set has a first set of collection frequencies for metric data collected according to the first rule set and the second rule set has a second set of collection frequencies for metric data collected according to the second rule set (“Any of a number of different types of corrective actions may be attempted in different embodiments, such as for example changing the maximum rate at which work requests of a specified type are to be accepted at the MSDs, restarting a process or thread, restarting a host, increasing/decreasing memory allocated for a certain type of task, increasing/decreasing minimum wait times between certain types of operations, and so on. In some embodiments, a rule may trigger an action which increases (or decreases) the level of detail of monitoring (locally or globally) a set of metrics, e.g., based on one or more leading indicators. This may be considered an optimization of the core monitoring functionality of the service—in effect, implementing such a rule may represent monitoring a metric relatively crudely until the metric gets close enough to a threshold that closer scrutiny is required. The level of detail may be changed, for example, by changing the frequency at which the metric is collected, by changing the precision of numeric values that are collected, by using a different tool or sensor to collect the metric, and so on.,” column 7 line 62 to column 8 line 15).
As to dependent claim 14, Davis further discloses a system wherein the one or more processors are further configured to monitor the node for a trigger condition indicating a change in operational conditions based on the metrics corresponding to the first rule set (“During a particular iteration of the execution of rule set 450, an initial value of the metric may be obtained, and the first rule of the set (rule #1) may be applied to the initial value. For example, if the metric does not meet one or more acceptance criteria, an action A1 may be initiated. If, after the application of rule #1, the metric value returns to a stable or acceptable range (as detected in element 402), the rule set execution iteration may be exited as indicated in element 490. Otherwise, rule #2 may be triggered, which may result in another action A2,” column 13 lines 13-22).
As to dependent claim 15, Davis further discloses a system wherein the trigger condition indicating the change in operational conditions is evaluated (“During a particular iteration of the execution of rule set 450, an initial value of the metric may be obtained, and the first rule of the set (rule #1) may be applied to the initial value. For example, if the metric does not meet one or more acceptance criteria, an action A1 may be initiated. If, after the application of rule #1, the metric value returns to a stable or acceptable range (as detected in element 402), the rule set execution iteration may be exited as indicated in element 490. Otherwise, rule #2 may be triggered, which may result in another action A2,” column 13 lines 13-22) using machine learning techniques (figure 8 steps 810-819; “an input data set comprising metadata generated by one or more RPUs during some time interval may be identified for a machine learning model by an event-action analyzer. The output produced by the machine learning models may be used to determine one or more rule modification recommendations for a set of RPUs, which may be then be propagated to the RPUs,” column 5 lines 43-50 – note the breadth of claim language “using”).
As to dependent claim 16, Davis further discloses a system wherein the one or more processors are further configured to transmit to the management node an indication of the trigger condition (“If A3 succeeds in stabilizing the metric value (as detected in element 406), the rule set iteration may be considered complete; otherwise, an escalation message may be transmitted to a higher-level RPU as indicated in element 408 before the iteration is completed,” column 13 lines 26-31).
As to independent claim 17, Davis discloses a non-transitory computer readable storage medium having stored thereon instructions that, when executed by one or more processors (“computing device 9000 includes one or more processors 9010 coupled to a system memory 9020,” column 19 lines 59-60), cause the one or more processors to:
collect data according to a first rule set (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52), wherein the rules in the first rule set indicate a first set of one or more metrics corresponding to operation of elements of the node (“After the initial parameters are identified, a collection of RPUs may be instantiated to respond to the metrics/events at targeted devices (element 804),” column 16 lines 33-35),
transmit (“metadata may be generated and transmitted to the repository not only when events occur (such as when new values of metrics are obtained at leaf-level RPUs),” column 9 lines 39-42) collected data corresponding to the first rule set to at least a management node (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52) in the distributed storage system (“The RPUs of the RMS 243 may be distributed among the devices of various other services, such as the VCS 203, storage/database services 223 and so on,” column 11 lines 13-16), wherein the transmission frequency is determined by the first rule set (“Any of a number of different types of corrective actions may be attempted in different embodiments, such as for example changing the maximum rate at which work requests of a specified type are to be accepted at the MSDs, restarting a process or thread, restarting a host, increasing/decreasing memory allocated for a certain type of task, increasing/decreasing minimum wait times between certain types of operations, and so on. In some embodiments, a rule may trigger an action which increases (or decreases) the level of detail of monitoring (locally or globally) a set of metrics, e.g., based on one or more leading indicators. This may be considered an optimization of the core monitoring functionality of the service—in effect, implementing such a rule may represent monitoring a metric relatively crudely until the metric gets close enough to a threshold that closer scrutiny is required. The level of detail may be changed, for example, by changing the frequency at which the metric is collected, by changing the precision of numeric values that are collected, by using a different tool or sensor to collect the metric, and so on.,” column 7 line 62 to column 8 line 15),
receive a second rule set, wherein the rules in the second rule set indicate a first set of one or more metrics corresponding to operation of elements of the node (figure 8 steps 810-819; “an input data set comprising metadata generated by one or more RPUs during some time interval may be identified for a machine learning model by an event-action analyzer. The output produced by the machine learning models may be used to determine one or more rule modification recommendations for a set of RPUs, which may be then be propagated to the RPUs,” column 5 lines 43-50),
collect data according to the second rule set (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52), and
transmit (“metadata may be generated and transmitted to the repository not only when events occur (such as when new values of metrics are obtained at leaf-level RPUs),” column 9 lines 39-42) collected data corresponding to the second rule set to the management node (“In a given iteration, event-action metadata may be collected for some time period, and the progress made towards the overall resource management goals since the last iteration may be quantified (element 807),” column 16 lines 48-52), wherein the transmission frequency is determined by the second rule set and is different than the transmission frequency for the first rule set (“Any of a number of different types of corrective actions may be attempted in different embodiments, such as for example changing the maximum rate at which work requests of a specified type are to be accepted at the MSDs, restarting a process or thread, restarting a host, increasing/decreasing memory allocated for a certain type of task, increasing/decreasing minimum wait times between certain types of operations, and so on. In some embodiments, a rule may trigger an action which increases (or decreases) the level of detail of monitoring (locally or globally) a set of metrics, e.g., based on one or more leading indicators. This may be considered an optimization of the core monitoring functionality of the service—in effect, implementing such a rule may represent monitoring a metric relatively crudely until the metric gets close enough to a threshold that closer scrutiny is required. The level of detail may be changed, for example, by changing the frequency at which the metric is collected, by changing the precision of numeric values that are collected, by using a different tool or sensor to collect the metric, and so on.,” column 7 line 62 to column 8 line 15).
As to dependent claim 18, Davis further discloses a medium wherein the first rule set has a first set of collection frequencies for metric data collected according to the first rule set and the second rule set has a second set of collection frequencies for metric data collected according to the second rule set (“Any of a number of different types of corrective actions may be attempted in different embodiments, such as for example changing the maximum rate at which work requests of a specified type are to be accepted at the MSDs, restarting a process or thread, restarting a host, increasing/decreasing memory allocated for a certain type of task, increasing/decreasing minimum wait times between certain types of operations, and so on. In some embodiments, a rule may trigger an action which increases (or decreases) the level of detail of monitoring (locally or globally) a set of metrics, e.g., based on one or more leading indicators. This may be considered an optimization of the core monitoring functionality of the service—in effect, implementing such a rule may represent monitoring a metric relatively crudely until the metric gets close enough to a threshold that closer scrutiny is required. The level of detail may be changed, for example, by changing the frequency at which the metric is collected, by changing the precision of numeric values that are collected, by using a different tool or sensor to collect the metric, and so on.,” column 7 line 62 to column 8 line 15).
As to dependent claim 19, Davis further discloses a medium wherein the instructions, when executed by the one or more processors, cause the one or more processors to monitor the node for a trigger condition indicating a change in operational conditions based on the metrics corresponding to the first rule set (“During a particular iteration of the execution of rule set 450, an initial value of the metric may be obtained, and the first rule of the set (rule #1) may be applied to the initial value. For example, if the metric does not meet one or more acceptance criteria, an action A1 may be initiated. If, after the application of rule #1, the metric value returns to a stable or acceptable range (as detected in element 402), the rule set execution iteration may be exited as indicated in element 490. Otherwise, rule #2 may be triggered, which may result in another action A2,” column 13 lines 13-22).
As to dependent claim 20, Davis further discloses a medium wherein the trigger condition indicating the change in operational conditions is evaluated (“During a particular iteration of the execution of rule set 450, an initial value of the metric may be obtained, and the first rule of the set (rule #1) may be applied to the initial value. For example, if the metric does not meet one or more acceptance criteria, an action A1 may be initiated. If, after the application of rule #1, the metric value returns to a stable or acceptable range (as detected in element 402), the rule set execution iteration may be exited as indicated in element 490. Otherwise, rule #2 may be triggered, which may result in another action A2,” column 13 lines 13-22) using machine learning techniques (figure 8 steps 810-819; “an input data set comprising metadata generated by one or more RPUs during some time interval may be identified for a machine learning model by an event-action analyzer. The output produced by the machine learning models may be used to determine one or more rule modification recommendations for a set of RPUs, which may be then be propagated to the RPUs,” column 5 lines 43-50 – note the breadth of claim language “using”).
Claim Rejections - 35 U.S.C. § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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 2 and 8 are rejected under 35 U.S.C. § 103 as being unpatentable over Davis in view of Gregorio et al. (US 11,977,466 B1, hereinafter Gregorio-de Souza).
As to dependent claim 2, the rejection of claim 1 is incorporated. Davis further teaches a system wherein the one or more processors further perform operational analysis on the received metric data corresponding to the first rule set to [detect] diminished performance of at least one of the receiving entities (“If A3 succeeds in stabilizing the metric value (as detected in element 406), the rule set iteration may be considered complete; otherwise, an escalation message may be transmitted to a higher-level RPU as indicated in element 408 before the iteration is completed,” column 13 lines 26-31).
Davis does not appear to expressly teach a system wherein the detection of diminished performance is a prediction of diminished performance.
Gregorio teaches a system wherein the detection of diminished performance is a prediction of diminished performance (“Once ML training 214 completes, the resulting trained model 216 may be used to perform predictions. Specifically, the same data processing (at 206) and metric mapping (at 208) path that was used for generating the training data may be used to preprocess (at 206) and map (at 208) live telemetry data 204. The resulting metric data 222 may be provided as input to the trained model 216, which may generate predicted scores 218,” column 6 lines 17-24).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the detection of Davis to comprise the prediction of Gregorio. (1) The Examiner finds that the prior art included each claim element listed above, although not necessarily in a single prior art reference, with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. (2) The Examiner finds that one of ordinary skill in the art could have combined the elements as claimed by known development methods, and that in combination, each element merely performs the same function as it does separately. (3) The Examiner finds that one of ordinary skill in the art would have recognized that the results of the combination were predictable, namely predicting diminished performance (“Once ML training 214 completes, the resulting trained model 216 may be used to perform predictions. Specifically, the same data processing (at 206) and metric mapping (at 208) path that was used for generating the training data may be used to preprocess (at 206) and map (at 208) live telemetry data 204. The resulting metric data 222 may be provided as input to the trained model 216, which may generate predicted scores 218,” Gregorio column 6 lines 17-24). Therefore, the rationale to support a conclusion that the claim would have been obvious is that the combining prior art elements according to known methods to yield predictable results to one of ordinary skill in the art. See MPEP § 2143(I)(A).
As to dependent claim 8, the rejection of claim 7 is incorporated. Davis further teaches a medium comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform operational analysis on the received metric data corresponding to the first rule set to [detect] diminished performance of at least one of the receiving entities (“If A3 succeeds in stabilizing the metric value (as detected in element 406), the rule set iteration may be considered complete; otherwise, an escalation message may be transmitted to a higher-level RPU as indicated in element 408 before the iteration is completed,” column 13 lines 26-31).
Davis does not appear to expressly teach a medium wherein the detection of diminished performance is a prediction of diminished performance.
Gregorio teaches a medium wherein the detection of diminished performance is a prediction of diminished performance (“Once ML training 214 completes, the resulting trained model 216 may be used to perform predictions. Specifically, the same data processing (at 206) and metric mapping (at 208) path that was used for generating the training data may be used to preprocess (at 206) and map (at 208) live telemetry data 204. The resulting metric data 222 may be provided as input to the trained model 216, which may generate predicted scores 218,” column 6 lines 17-24).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the detection of Davis to comprise the prediction of Gregorio. (1) The Examiner finds that the prior art included each claim element listed above, although not necessarily in a single prior art reference, with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. (2) The Examiner finds that one of ordinary skill in the art could have combined the elements as claimed by known development methods, and that in combination, each element merely performs the same function as it does separately. (3) The Examiner finds that one of ordinary skill in the art would have recognized that the results of the combination were predictable, namely predicting diminished performance (“Once ML training 214 completes, the resulting trained model 216 may be used to perform predictions. Specifically, the same data processing (at 206) and metric mapping (at 208) path that was used for generating the training data may be used to preprocess (at 206) and map (at 208) live telemetry data 204. The resulting metric data 222 may be provided as input to the trained model 216, which may generate predicted scores 218,” Gregorio column 6 lines 17-24). Therefore, the rationale to support a conclusion that the claim would have been obvious is that the combining prior art elements according to known methods to yield predictable results to one of ordinary skill in the art. See MPEP § 2143(I)(A).
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure:
US 2005/0021306 A1 disclosing distributed data gathering and aggregation
Applicant is required under 37 C.F.R. § 1.111(c) to consider these references fully when responding to this action.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 C.F.R. § 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 C.F.R. § 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
In the interests of compact prosecution, Applicant is invited to contact the examiner via electronic media pursuant to USPTO policy outlined MPEP § 502.03. All electronic communication must be authorized in writing. Applicant may wish to file an Internet Communications Authorization Form PTO/SB/439. Applicant may wish to request an interview using the Interview Practice website: http://www.uspto.gov/patent/laws-and-regulations/interview-practice.
Applicant is reminded Internet e-mail may not be used for communication for matters under 35 U.S.C. § 132 or which otherwise require a signature. A reply to an Office action may NOT be communicated by Applicant to the USPTO via Internet e-mail. If such a reply is submitted by Applicant via Internet e-mail, a paper copy will be placed in the appropriate patent application file with an indication that the reply is NOT ENTERED. See MPEP § 502.03(II).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ryan Barrett whose telephone number is 571 270 3311. The examiner can normally be reached 9:00am to 5:30pm.
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 Michelle Bechtold can be reached at 571 431 0762. 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.
/Ryan Barrett/
Primary Examiner, Art Unit 2148
Prosecution Insights