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 Application filed on 4/27/2023. Claims 1-20 are pending in the case. Claims 1, 7, 12, and 17 are independent claims.
Claim Objections
Claims 2, 5, and 11 are objected to because of the following informalities:
Claim 2 recites “further comprising performing” where “wherein the one or more processors further perform” was apparently intended.
Claims 5 and 11 recite “results is” where “results in” was apparently intended.
Claim 11 recites “wherein first” where “wherein the first” was apparently intended.
Appropriate correction is required.
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 is 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 first rule set results is 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 comprising performing 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 2024/0211798 A1 disclosing machine learning prediction of diminished performance of monitored entities
Applicant is required under 37 C.F.R. § 1.111(c) to consider these references fully when responding to this action.
It is noted that any citation to specific pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. In re Heck, 699 F.2d 1331, 1332-33, 216 U.S.P.Q. 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 U.S.P.Q. 275, 277 (C.C.P.A. 1968)).
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