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 .
Claims 1-20 are pending for examination. Claims 1, 7, and 15 are independent claims. This Office Action is Non-Final.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office Action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 03/02/2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 9 and 13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 9 and 13 “the one or more software programs” lacks antecedent basis. Appropriate correction is required.
Claim Rejections - 35 USC § 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 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(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-20 are rejected under 35 U.S.C. 102(a)(1) and 35 U.S.C. 102(a)(2) as being anticipated by Wouhaybi et al. (U.S. Publ. No. 2022/0012112 A1), hereinafter Wou.
Regarding claim 1, Wou teaches:
A processor (Wou, Abstract teaches processor, Fig. 1 Robustness score engine 120 includes processor 128, see paragraph 0055), comprising:
one or more circuits to: (Wou, paragraph 0055 teaches processors 112, 128 “Processor 128 may include any suitable combination of characteristics described herein with respect to processor 112”. Paragraph 0025 teaches “physical processor … typically refers to an integrated circuit”)
cause one or more first software programs (Wou, Abstract, Fig. 1, Robustness Scoring Engine 120 [i.e. first software programs], paragraph 0055, 0088 “ a pre-trained robustness scoring system could run”. Figs. 6-8 teaches first software programs) to generate a score of past performance of one or more computing resources (Wou, Abstract “generate … a first robustness score for the first hardware component representing a health state of the first hardware component.” Fig. 1, Robustness Scoring Engine 120 paragraph 0055 includes Event History 125. Paragraph 0060 teaches “As the computing infrastructure continues to be used, additional telemetry data, event history data, and updated metadata can be collected for the nodes and hardware components. This additional data can be used by robustness score adjuster 126 to retrain the robustness score model 124.” See also paragraphs 0067, 0125, 0081 feedback mechanism for previous performance in scoring system. Paragraph 0067 teaches “event history 125 can also include an indication of a robustness score corresponding to a hardware component when a particular [previous] event occurred [for that hardware component], to enable learning from previous robustness scores that were generated.” Paragraph 125 “advising which action should be taken for which hardware component…an action that is taken may be recorded as an event in the event history 125, which can be used for retraining the robustness score model.” [i.e. score of past performance]. Paragraph 0127 teaches unhealthy robustness score [i.e. caused by past performance] leads to recalculation of the robustness score of individual nodes in cluster and individual hardware components in each of the nodes.) based, at least in part, on a decay function applied over a period of time to a time series of events associated with the past performance of the one or more computing resources (Examiner under BRI interprets “decay function” as weighted average of scores that reduces a value as recited in paragraph 0084 of Applicant’s originally filed specification. See MPEP 2111.01(V). Wou, Fig. 5, weights 522, paragraph 0093-0095 teaches “Inputs 510 can further include one or more telemetry data inputs 514(1)-514(y) corresponding to telemetry data of hardware component 504 and its associated interface 506 and node 502, which has been previously described herein….Weights 522 may be learnable parameters that can be used to give a more or less influence to a particular input when generating a robustness score.” See also paragraphs 0107, 0112. Paragraphs 0042, 0089 teaches “Each robustness score engine 320(1)-320(m) collects real time system data such as metadata 364, 374, 384, telemetry data 366, 376, 386, and event data 368, 378, 388.” [i.e. time series of events]. Paragraph 0045 teaches “Further telemetry data could include … the total duration of utilization over the life [i.e. past performance] of a device (e.g., CPU, GPU, VPU, FPGA, ASIC, network processor, switch, hub, router, SSD, HDD, RAM, ROM, NIC, etc.).” Paragraph 0048 teaches “telemetry data can be an indicator of the health state of the system and can be used to generate a robustness score for a selected portion of the infrastructure.” Paragraph 0060 teaches “ additional telemetry data, event history data, and updated metadata can be collected for the nodes and hardware components. This additional data can be used by robustness score adjuster 126 to retrain the robustness score model 124.”As taught in paragraphs above, the telemetry data, event history data and metadata includes past performance of computing resources to which decay function weights are applied (as shown in Fig. 5.)) such that in the generation of the score more recent events are weighted more heavily than less recent events in the time series according to the decay function (As described in claim mapping above, Examiner under BRI interprets “decay function” as weighted average of scores that reduces a value as recited in paragraph 0084 of Applicant’s originally filed specification. Wou, paragraph 0094 teaches “Weights 522 …can be used to give a more or less influence to a particular input when generating a robustness score.” Paragraph 0095 teaches “A heavier weighting could help offset the influence of other feature inputs…” Paragraph 0042 “a critical event such as an overloaded resource (e.g., core) or an excessive temperature may be reported prior to the normal interval for reporting telemetry data (e.g., a notification may be sent immediately upon detection)….obtain real-time or most recently collected telemetry data, which can then be provided to robustness scoring engine 120….” Thus, Wou teaches in above paragraphs critical events are more recent events because occurred recently and reported immediately and they are given more weight as critical events with less weight given to noncritical events that are less recent [i.e. weighting given according to the decay function]); and
cause, based at least in part on the generated score, one or more second software programs (Wou, Fig. 1, Workloads 140, paragraph 0039 “applications, services, microservices”, paragraph 0070. Generation of scores of computing resources are explained in the claim mappings given above. Fig. 9, paragraph 0123 teaches performing second software program on computing resources nodes selected based on robustness score) to be performed using the one or more computing resources (Wou, Fig. 1, Computing infrastructure 110 that includes processor 112, accelerator 113, memory device 114, storage device 115 (i.e. computing resources) and so on described in paragraph 0024 and 0036 “an element of system 100 (e.g., orchestrator 130) may communicate through a network with external computing devices requesting the performance of processing operations (e.g., workloads) to be performed by computing infrastructure 110.” Performance of programs on computing resources is taught in paragraphs 0018, 0027 “accelerator … capable of accelerating certain workloads … accelerators that may be … graphics processing units (GPUs).” See also paragraph 0070 “orchestrator 130 is further configured to manage placement of workloads onto the logical machines, i.e., to select a logical machine on which to place a respective workload and to manage logical machine sharing by a plurality of workloads.” Fig. 9, paragraph 0123 teaches performing second software program on computing resources nodes selected based on robustness score).
Regarding dependent claim 2, Wou teaches wherein the one or more computing resources are categorized using a fitness score band (Wou, paragraph 0022 “notice of the health state of a selected portion of a computing infrastructure … that has a robustness score corresponding to a minimum reliability threshold, or reduced reliability threshold, or other similar threshold.” Each threshold creates a fitness score band, if resource above that threshold in one band, above next lower threshold in second band and so on. See also paragraphs 0072, 0079 “appropriate thresholds”, 0117 “Examples of reliability thresholds could potentially include a maximum reliability threshold, a reduced reliability threshold, and a minimum reliability threshold.”) of a plurality of fitness score bands (Wou, paragraphs 0022, 0072, 0079, 0117, each threshold creates a fitness score band for a plurality of bands), wherein each fitness score band of the plurality of fitness score bands comprises a threshold value that is configurable (Wou, paragraphs 0022, 0072, 0079, 0117, teaches thresholds. Paragraphs 0073, 0075, 0080 teaches appropriate threshold for a node, hardware component, cluster so threshold is configured and changes based on hardware type. Paragraph 0116 “the reliability thresholds may be specific to the hardware component (if the selected portion is a hardware component), to the node (if the selected portion is a node), or specific to the cluster of nodes (if the selected portion is a cluster of nodes)”).
Regarding dependent claim 3, Wou teaches wherein the past performance of the one or more computing resources is generated based, at least in part, on a ratio of a sample rate to a period in time (Wou, paragraphs 0060, 0067 frequency of errors which is sample of errors over a time period, 0125, 0081) .
Regarding dependent claim 4, Wou teaches wherein the one or more circuits cause the one or more second software programs to be performed on the one or more computing resources based, at least in part, on a label assigned to the one or more computing resources (Wou, paragraphs 0117-0119, 0123, 0127 score using reliability thresholds places label of “unhealthy” or “healthy” on selection computing (e.g. component, node, cluster …). Paragraph 0073 teaches migrating workloads to “healthy” node, see also 0078, 0123).
Regarding dependent claim 5, Wou teaches wherein the one or more first software programs score past performance based, at least in part, on one or more events stored in a time series database system (Wou, Fig. 1, paragraphs 0023, 0047-0048, 0089, 0099 Error Log 170 stores telemetry data including error information in any suitable storage system that is used to generate score (Abstract, paragraph 0047)).
Regarding dependent claim 6, Wou teaches wherein the one or more circuits cause the one or more second software programs to be performed on the one or more computing resources based, at least in part, on one or more attribute values of the one or more computing resources exceeding a threshold value (Examiner under BRI interprets “attribute values” as recited in Applicant’s originally filed specification in paragraph 0063 as fitness values or health values. Wou, paragraph 0021 “a robustness scoring engine can be configured to generate a robustness score as a measure of the health state of a selected portion of a computing infrastructure”; paragraph 0022 “notice of the health state of a selected portion of a computing infrastructure … that has a robustness score corresponding to a minimum reliability threshold, or reduced reliability threshold, or other similar threshold.” See also paragraphs 0072, 0079 “appropriate thresholds”, 0117 “Examples of reliability thresholds could potentially include a maximum reliability threshold, a reduced reliability threshold, and a minimum reliability threshold.” Paragraph 0117 if robustness score meets high reliability threshold, then selected portion is healthy and also exceeds the reduced reliability threshold and minimum reliability threshold. Workloads including software programs, applications, services are scheduled as shown in Fig. 10, blocks 1014-1018, paragraph 0130).
Regarding claim 7, Wou teaches:
A system, (Wou, Abstract and Figure 1 teach system 100 that includes computing infrastructure 110, robustness scoring engine 120, orchestrator 130, a telemetry engine 150, metadata 160, an error log 170, and a plurality of workloads 140 ) comprising:
one or more processors to: (Wou, Abstract teaches processor, Fig. 1 Robustness score engine 120 includes processor 128, see paragraph 0055)
cause one or more first software programs (Wou, Abstract, Fig. 1, Robustness Scoring Engine 120 [i.e. first software programs], paragraph 0055, 0088 “ a pre-trained robustness scoring system could run”. Figs. 6-8 teaches first software programs) to generate a score of past performance of one or more computing resources (Wou, Abstract “generate … a first robustness score for the first hardware component representing a health state of the first hardware component.” Fig. 1, Robustness Scoring Engine 120 paragraph 0055 includes Event History 125. Paragraph 0060 teaches “As the computing infrastructure continues to be used, additional telemetry data, event history data, and updated metadata can be collected for the nodes and hardware components. This additional data can be used by robustness score adjuster 126 to retrain the robustness score model 124.” See also paragraphs 0067, 0125, 0081 feedback mechanism for previous performance in scoring system. Paragraph 0067 teaches “event history 125 can also include an indication of a robustness score corresponding to a hardware component when a particular [previous] event occurred [for that hardware component], to enable learning from previous robustness scores that were generated.” Paragraph 125 “advising which action should be taken for which hardware component…an action that is taken may be recorded as an event in the event history 125, which can be used for retraining the robustness score model.” [i.e. score of past performance]. Paragraph 0127 teaches unhealthy robustness score [i.e. caused by past performance] leads to recalculation of the robustness score of individual nodes in cluster and individual hardware components in each of the nodes.) based, at least in part, on a decay function applied over a period of time to a time series of events associated with the past performance of the one or more computing resources (Examiner under BRI interprets “decay function” as weighted average of scores that reduces a value as recited in paragraph 0084 of Applicant’s originally filed specification. See MPEP 2111.01(V). Wou, Fig. 5, weights 522, paragraph 0093-0095 teaches “Inputs 510 can further include one or more telemetry data inputs 514(1)-514(y) corresponding to telemetry data of hardware component 504 and its associated interface 506 and node 502, which has been previously described herein….Weights 522 may be learnable parameters that can be used to give a more or less influence to a particular input when generating a robustness score.” See also paragraphs 0107, 0112. Paragraphs 0042, 0089 teaches “Each robustness score engine 320(1)-320(m) collects real time system data such as metadata 364, 374, 384, telemetry data 366, 376, 386, and event data 368, 378, 388.” [i.e. time series of events]. Paragraph 0045 teaches “Further telemetry data could include … the total duration of utilization over the life [i.e. past performance] of a device (e.g., CPU, GPU, VPU, FPGA, ASIC, network processor, switch, hub, router, SSD, HDD, RAM, ROM, NIC, etc.).” Paragraph 0048 teaches “telemetry data can be an indicator of the health state of the system and can be used to generate a robustness score for a selected portion of the infrastructure.” Paragraph 0060 teaches “ additional telemetry data, event history data, and updated metadata can be collected for the nodes and hardware components. This additional data can be used by robustness score adjuster 126 to retrain the robustness score model 124.”As taught in paragraphs above, the telemetry data, event history data and metadata includes past performance of computing resources to which decay function weights are applied (as shown in Fig. 5.)) such that in the generation of the score more recent events are weighted more heavily than less recent events in the time series according to the decay function (As described in claim mapping above, Examiner under BRI interprets “decay function” as weighted average of scores that reduces a value as recited in paragraph 0084 of Applicant’s originally filed specification. Wou, paragraph 0094 teaches “Weights 522 …can be used to give a more or less influence to a particular input when generating a robustness score.” Paragraph 0095 teaches “A heavier weighting could help offset the influence of other feature inputs…” Paragraph 0042 “a critical event such as an overloaded resource (e.g., core) or an excessive temperature may be reported prior to the normal interval for reporting telemetry data (e.g., a notification may be sent immediately upon detection)….obtain real-time or most recently collected telemetry data, which can then be provided to robustness scoring engine 120….” Thus, Wou teaches in above paragraphs critical events are more recent events because occurred recently and reported immediately and they are given more weight as critical events with less weight given to noncritical events that are less recent [i.e. weighting given according to the decay function]); and
cause, based at least in part on the generated score, one or more second software programs (Wou, Fig. 1, Workloads 140, paragraph 0039 “applications, services, microservices”, paragraph 0070. Generation of scores of computing resources are explained in the claim mappings given above. Fig. 9, paragraph 0123 teaches performing second software program on computing resources nodes selected based on robustness score) to be performed using the one or more computing resources (Wou, Fig. 1, Computing infrastructure 110 that includes processor 112, accelerator 113, memory device 114, storage device 115 (i.e. computing resources) and so on described in paragraph 0024 and 0036 “an element of system 100 (e.g., orchestrator 130) may communicate through a network with external computing devices requesting the performance of processing operations (e.g., workloads) to be performed by computing infrastructure 110.” Performance of programs on computing resources is taught in paragraphs 0018, 0027 “accelerator … capable of accelerating certain workloads … accelerators that may be … graphics processing units (GPUs).” See also paragraph 0070 “orchestrator 130 is further configured to manage placement of workloads onto the logical machines, i.e., to select a logical machine on which to place a respective workload and to manage logical machine sharing by a plurality of workloads.” Fig. 9, paragraph 0123 teaches performing second software program on computing resources nodes selected based on robustness score).
Regarding dependent claim 8, Wou teaches wherein the one or more first software programs score past performance of the one or more computing resources based, at least in part, on aggregating one or more events of the one or more computing resources (Wou, Abstract “obtain first telemetry data associated with a selected portion of a computing infrastructure, and the selected portion includes a first node and a first hardware component. …input one or more telemetry inputs corresponding to the first telemetry data into a machine learning model, input one or more metadata inputs corresponding to the first metadata into the machine learning model, and generate, from the machine learning model”. Paragraph 0042 teaches “a critical event such as an overloaded resource”. Paragraph 0067 teaches event history is collected (i.e. aggregated) by scoring engine 120 and fed into adjuster 126.) over periods of time (Wou, paragraph 0042, 0051 teaches “normal interval for reporting telemetry data” and 0044 “power information (e.g., power consumed during designated time periods)” See also paragraph 0056).
Regarding dependent claim 9, Wou teaches wherein the one or more first software programs score past performance of the one or more computing resources based, at least in part, on a weighted average of events over a time period (Wou, paragraph 0059 “ the robustness scores for nodes and for clusters of nodes can be calculated using weighted averages.” Fig. 5, paragraph 0094 teaches weights 522. Paragraph 0042, 0051 teaches “normal interval for reporting telemetry data” and 0044 “power information (e.g., power consumed during designated time periods)” Paragraphs 0051 teaches telemetry data is reported over a normal interval.) and a ratio of a rate of the one or more software programs to be performed without interruption to one or more failures per the one or more computing resources (Wou, paragraph 0078 “moving mission critical workloads from hardware with lowered robustness score due to age, utilization, and failure rates.” Paragraph 0047 “Error information can include, for example, the type of error and the frequency of errors for the component and/or node.” Fig. 5 shows robustness score model calculation and paragraph 0092 teaches “ robustness score model 520 includes one or more formulas and/or functions 526 that receive inputs 510, make a prediction on the inputs 510, and produce an output 530 that represents the prediction.” See also paragraph 0067 “Nonlimiting examples of event history can include one or more of failure data, error data, conditions associated with a failure event or error event, frequency of errors, and corrective actions (if any) related to a hardware component and/or a node containing the hardware component.”).
Regarding dependent claim 10, Wou teaches wherein the past performance is scored based, at least in part, on the decay function applied to one or more events of the one or more computing resources (Examiner under BRI interprets “decay function” as weighted average of scores that reduces a value as recited in paragraph 0084 of Applicant’s originally filed specification. See MPEP 2111.01(V). Wou, Fig. 5, weights 522, paragraph 0094-0095 teaches “Weights 522 may be learnable parameters that can be used to give a … less influence to a particular input when generating a robustness score.” See also paragraphs 0107, 0112) for a predetermined window of time in the time series (Wou, paragraph 0042, 0051 teaches “normal interval for reporting telemetry data” and 0044 “power information (e.g., power consumed during designated time periods)” Paragraphs 0051 teaches telemetry data is reported over a normal interval.).
Regarding dependent claim 11, Wou teaches wherein the past performance is based, at least in part, on transient failures (Wou, paragraph 0067 teaches event history includes failure data, corrective actions that indicates failure has occurred and is being corrected (i.e. transient failure)).
Regarding dependent claim 12, Wou teaches wherein the past performance is scored based, at least in part, on one or more severity scores of events (Examiner under BRI interprets “severity scores of events” as giving more weight or influence to particular event of a component. Wou, Fig. 5, paragraphs 0093-0094 teaches giving more weight/influence to an input for particular metadata or telemetry data for node/hardware event).
Regarding dependent claim 13, Wou teaches wherein to cause the one or more second software programs to be performed includes to schedule the one or more second software programs on the one or more computing resources (Wou, paragraph 0002 “An orchestrator is often used to schedule workloads on compute hosts in the infrastructure.” See also paragraph 0098 performing assessments of hardware at scheduled times to collect data as shown in Fig. 6), wherein the one or more computing resources include one or more nodes (Wou, Fig. 2, computing infrastructure 210 includes accelerator nodes 223(1), 223(2), memory node 224, network node 227 and compute node 222), and wherein the one or more nodes include one or more graphics processing units (GPUs) to perform at least part of the one or more software programs (Wou, Fig. 2 computing infrastructure 210 includes accelerator node 223(1) that comprises GPUs 213).
Regarding dependent claim 14, Wou teaches wherein the one or more of the computer resources with past performance scores that exceed a threshold value are prioritized to perform the one or more second software programs (Wou, paragraph 0021 “a robustness scoring engine can be configured to generate a robustness score as a measure of the health state of a selected portion of a computing infrastructure”; paragraph 0022 “notice of the health state of a selected portion of a computing infrastructure … that has a robustness score corresponding to a minimum reliability threshold, or reduced reliability threshold, or other similar threshold.” See also paragraphs 0072, 0079 “appropriate thresholds”, 0117 “Examples of reliability thresholds could potentially include a maximum reliability threshold, a reduced reliability threshold, and a minimum reliability threshold.” Paragraph 0117 if robustness score meets high reliability threshold, then selected portion is healthy and also exceeds the reduced reliability threshold and minimum reliability threshold. Paragraph 0117 “If the robustness score of a selected portion meets the high reliability threshold, this could indicate that the selected portion of the computing infrastructure is healthy and can run at maximum capacity with any appropriate workloads, storage, and/or network needs for the selected portion.” Workloads including software programs, applications, services are scheduled as shown in Fig. 10, blocks 1014-1018, paragraph 0130) and the one or more of computing resources with past performance scores that are below the threshold value are deprioritized (Wou, paragraph 0117 “If the robustness score meets the minimum reliability threshold, this could indicate that the selected portion is unhealthy and needs preventive action before a failure occurs.” If robustness score meets minimum reliability score, than this robustness score is below maximum reliability score (i.e. below the threshold). Workloads including software programs, applications, services are scheduled as shown in Fig. 10, blocks 1014-1018, paragraph 0130).
Regarding claim 15, Wou teaches:
A method, comprising:
causing one or more first software programs (Wou, Abstract, Fig. 1, Robustness Scoring Engine 120 [i.e. first software programs], paragraph 0055, 0088 “ a pre-trained robustness scoring system could run”. Figs. 6-8 teaches first software programs) to generate a score of past performance of one or more computing resources (Wou, Abstract “generate … a first robustness score for the first hardware component representing a health state of the first hardware component.” Fig. 1, Robustness Scoring Engine 120 paragraph 0055 includes Event History 125. Paragraph 0060 teaches “As the computing infrastructure continues to be used, additional telemetry data, event history data, and updated metadata can be collected for the nodes and hardware components. This additional data can be used by robustness score adjuster 126 to retrain the robustness score model 124.” See also paragraphs 0067, 0125, 0081 feedback mechanism for previous performance in scoring system. Paragraph 0067 teaches “event history 125 can also include an indication of a robustness score corresponding to a hardware component when a particular [previous] event occurred [for that hardware component], to enable learning from previous robustness scores that were generated.” Paragraph 125 “advising which action should be taken for which hardware component…an action that is taken may be recorded as an event in the event history 125, which can be used for retraining the robustness score model.” [i.e. score of past performance]. Paragraph 0127 teaches unhealthy robustness score [i.e. caused by past performance] leads to recalculation of the robustness score of individual nodes in cluster and individual hardware components in each of the nodes.) based, at least in part, on a decay function applied over a period of time to a time series of events associated with the past performance of the one or more computing resources (Examiner under BRI interprets “decay function” as weighted average of scores that reduces a value as recited in paragraph 0084 of Applicant’s originally filed specification. See MPEP 2111.01(V). Wou, Fig. 5, weights 522, paragraph 0093-0095 teaches “Inputs 510 can further include one or more telemetry data inputs 514(1)-514(y) corresponding to telemetry data of hardware component 504 and its associated interface 506 and node 502, which has been previously described herein….Weights 522 may be learnable parameters that can be used to give a more or less influence to a particular input when generating a robustness score.” See also paragraphs 0107, 0112. Paragraphs 0042, 0089 teaches “Each robustness score engine 320(1)-320(m) collects real time system data such as metadata 364, 374, 384, telemetry data 366, 376, 386, and event data 368, 378, 388.” [i.e. time series of events]. Paragraph 0045 teaches “Further telemetry data could include … the total duration of utilization over the life [i.e. past performance] of a device (e.g., CPU, GPU, VPU, FPGA, ASIC, network processor, switch, hub, router, SSD, HDD, RAM, ROM, NIC, etc.).” Paragraph 0048 teaches “telemetry data can be an indicator of the health state of the system and can be used to generate a robustness score for a selected portion of the infrastructure.” Paragraph 0060 teaches “ additional telemetry data, event history data, and updated metadata can be collected for the nodes and hardware components. This additional data can be used by robustness score adjuster 126 to retrain the robustness score model 124.”As taught in paragraphs above, the telemetry data, event history data and metadata includes past performance of computing resources to which decay function weights are applied (as shown in Fig. 5.)) such that in the generation of the score more recent events are weighted more heavily than less recent events in the time series according to the decay function (As described in claim mapping above, Examiner under BRI interprets “decay function” as weighted average of scores that reduces a value as recited in paragraph 0084 of Applicant’s originally filed specification. Wou, paragraph 0094 teaches “Weights 522 …can be used to give a more or less influence to a particular input when generating a robustness score.” Paragraph 0095 teaches “A heavier weighting could help offset the influence of other feature inputs…” Paragraph 0042 “a critical event such as an overloaded resource (e.g., core) or an excessive temperature may be reported prior to the normal interval for reporting telemetry data (e.g., a notification may be sent immediately upon detection)….obtain real-time or most recently collected telemetry data, which can then be provided to robustness scoring engine 120….” Thus, Wou teaches in above paragraphs critical events are more recent events because occurred recently and reported immediately and they are given more weight as critical events with less weight given to noncritical events that are less recent [i.e. weighting given according to the decay function]); and
causing, based at least in part on the generated score, one or more second software programs (Wou, Fig. 1, Workloads 140, paragraph 0039 “applications, services, microservices”, paragraph 0070. Generation of scores of computing resources are explained in the claim mappings given above. Fig. 9, paragraph 0123 teaches performing second software program on computing resources nodes selected based on robustness score) to be performed using the one or more computing resources (Wou, Fig. 1, Computing infrastructure 110 that includes processor 112, accelerator 113, memory device 114, storage device 115 (i.e. computing resources) and so on described in paragraph 0024 and 0036 “an element of system 100 (e.g., orchestrator 130) may communicate through a network with external computing devices requesting the performance of processing operations (e.g., workloads) to be performed by computing infrastructure 110.” Performance of programs on computing resources is taught in paragraphs 0018, 0027 “accelerator … capable of accelerating certain workloads … accelerators that may be … graphics processing units (GPUs).” See also paragraph 0070 “orchestrator 130 is further configured to manage placement of workloads onto the logical machines, i.e., to select a logical machine on which to place a respective workload and to manage logical machine sharing by a plurality of workloads.” Fig. 9, paragraph 0123 teaches performing second software program on computing resources nodes selected based on robustness score).
Regarding dependent claim 16, Wou teaches wherein the one or more first software programs score past performance of the one or more computing resources based, at least in part, on a weighted average of one or more attribute values of the one or more computing resources over periods of time (Examiner under BRI interprets “attribute values” as recited in Applicant’s originally filed specification in paragraph 0063 as fitness values or health values. Wou, paragraph 0021 “a robustness scoring engine can be configured to generate a robustness score as a measure of the health state of a selected portion of a computing infrastructure”. Paragraph 0059 teaches “the robustness scores for nodes and for clusters of nodes can be calculated using weighted averages.” Fig. 5, paragraph 0094 teaches weights 522. Paragraph 0042, 0051 teaches “normal interval for reporting telemetry data” and 0044 “power information (e.g., power consumed during designated time periods)”).
Regarding dependent claim 17, Wou teaches wherein the past performance of the one or more computing resources are based, at least in part, on an aggregation of one or more events (Wou, Abstract “input one or more telemetry inputs corresponding to the first telemetry data into a machine learning model, input one or more metadata inputs corresponding to the first metadata into the machine learning model, and generate, from the machine learning model”. Paragraph 0042 teaches “a critical event such as an overloaded resource”. Paragraph 0067 teaches event history is collected (i.e. aggregated) by scoring engine 120 and fed into adjuster 126.) stored in a time series database system (Fig. 1, paragraphs 0023, 0047-0048, 0099 Error Log 170 stores telemetry data including error information in any suitable storage system that is used to generate score (Abstract, paragraph 0047)).
Regarding dependent claim 18, Wou teaches further comprising:
performing the one or more second software programs based, at least in part, on the past performance of the one or more computing resources (Wou, Abstract “generate … a first robustness score for the first hardware component representing a health state of the first hardware component.” Fig. 1, Robustness Scoring Engine 120 paragraph 0055 includes Event History 125. Paragraph 0060 teaches “As the computing infrastructure continues to be used, additional telemetry data, event history data, and updated metadata can be collected for the nodes and hardware components. This additional data can be used by robustness score adjuster 126 to retrain the robustness score model 124.” See also paragraphs 0067, 0125, 0081 feedback mechanism for previous performance in scoring system).
Regarding dependent claim 19, Wou teaches wherein the past performance of the one or more computing resources are based, at least in part, on severity of one or more errors of the one or more computing resources (Examiner under BRI interprets “severity of …errors” as giving more weight or influence to particular error events. Wou, Fig. 5, paragraphs 0093-0095 teaches giving more weight/influence to an input for particular metadata or telemetry data for node/hardware error event based on severity or type of component).
Regarding dependent claim 20, Wou teaches wherein the past performance of the one or more computing resources are based, at least in part, on the decay function applied to one or more errors that are detected on the one or more computing resources (Examiner under BRI interprets “decay function” as weighted average of scores that reduces a value as recited in paragraph 0084 of Applicant’s originally filed specification. See MPEP 2111.01(V). Wou, Fig. 5, weights 522, paragraph 0094-0095 teaches “Weights 522 may be learnable parameters that can be used to give a … less influence to a particular input when generating a robustness score.” See also paragraphs 0107, 0112. Paragraphs 0042, 0044, 0089, 0099 teaches metadata and telemetry data are system data including event data that can include errors) for a predetermined window of time in the time series (Wou, paragraph 0042, 0051 teaches “normal interval for reporting telemetry data” and 0044 “power information (e.g., power consumed during designated time periods)” Paragraphs 0051 teaches telemetry data is reported over a normal interval.).
Response to Arguments
With regards to the 35 U.S.C. 102 rejection of claims 1-20, Applicant’s claim amendments and arguments have been considered but are moot because of the new claim mappings and the new grounds of rejection caused by the amendments to the claims.
With regards to the 35 U.S.C. 102 rejection of claims 1-20, Applicant on page 6 middle paragraph, cites to Wou paragraph 0089 and 0092 that describes a robustness score model is based on current telemetry data and real time system data. Applicant argues:
Real time data is current data. Wou does not describe that the robustness score is in any determined for a time series of events associated with the past performance of the one or more computing resources. As explicitly stated in Wou, Wou's robustness score is based on "current telemetry data and metadata." Id.
The Examiner respectfully disagrees with Applicants’ characterization of these portions of the Wou reference. The last sentence of paragraph 0092 in Wou recites “The robustness score can represent a health state of the component, which may be related to the remaining lifetime of the component based on its current telemetry data and metadata.” (Italicization added by Examiner) Thus, in this sentence “current telemetry and metadata” describes “the remaining lifetime of the component” and not the robustness score directly. Paragraph 0042 teaches that the telemetry engine 150 communicates telemetry data to robustness scoring engine 120 and paragraph 0044 teaches the telemetry data is used in robustness score calculations. Paragraph 0045 teaches that “telemetry data may include processor cache usage …number of memory accesses per unit of time …and/or total duration of utilization over the life of a device”, such telemetry data shows past performance of computing resources. Thus, this argument is not persuasive and the rejection is maintained.
Applicant argues on the top of page 7 “Accordingly, Wou does not teach that the robustness score is in any determined for a time series of events associated with the past performance of the one or more computing resources.” However, paragraph 0047 teaches “error information may be logged in error log 170, which may be accessed in any suitable manner to obtain the relevant error information … to be used by robustness scoring engine when calculating a robustness score.” Thus, the error log includes past error information and events. Thus, this argument is not persuasive and the rejection is maintained.
Applicant argues in the middle of page 7:
However, the weights or weighted average in Wou is in regard weighting different components of metadata or telemetry data differently, or weighting scores for different hardware components or nodes differently. See Wou [0094], [0107], and [0112]. The weights or weighted average in Wou do not represent any "decay function applied over a period of time to a time series of events,…”
The Examiner respectfully disagrees with Applicant’s assertion that Wou does not teach the “decay function applied over a period of time to a time series of events”. The Examiner in his claim mapping above interprets “decay function” in light of the specification as defined in paragraph 0084 of Applicant’s originally filed specification as a weighted average of scores that reduces a value and provides the claim mapping as given above. Applicant in their arguments on page 7 do not appear to take into account the Examiner’s BRI of the claim terms for this claim element. The Examiner respectfully suggests that the teachings of Wou in Fig. 5, paragraphs 0093-0095 describe the “decay function applied over a period of time to a time series of events”. Applicant uses similar arguments for the next claim 1 element “more recent events are weighted more heavily than less recent events” that the Examiner interprets under the same BRI for “decay function” that is taught by Wou in the claim mapping above. Thus, Applicant’s arguments are not persuasive and the 35 U.S.C. 102 rejection of claims 1-20 is maintained.
Applicant does not provide any further arguments for independent claims 1, 7, and 15 or the dependent claims and thus the rejection of these claims are respectfully maintained.
With regards to the 35 U.S.C. 101 non-statutory subject matter eligibility rejections of claims 1-20, Applicant’s arguments and claim amendments have been fully considered and they are persuasive. The Examiner respectfully withdraws the 35 U.S.C. 101 non-statutory subject matter eligibility rejections of claim 1-20.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicants’ disclosure. Applicants are 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, Applicants are invited to contact the examiner via electronic media pursuant to USPTO policy outlined MPEP § 502.03. All electronic communication must be authorized in writing. Applicants may wish to file an Internet Communications Authorization Form PTO/SB/439. Applicants may wish to request an interview using the Interview Practice website: http://www.uspto.gov/patent/laws-and-regulations/interview-practice.
Applicants are 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 Applicants to the USPTO via Internet e-mail. If such a reply is submitted by Applicants 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 INDRANIL CHOWDHURY whose telephone number is (571)272-0446. The examiner can normally be reached Mon.-Fri. 9:30-7:00 CST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Matt Kim can be reached on (571) 272-4182. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/INDRANIL CHOWDHURY/Examiner, Art Unit 2114
/ASHISH THOMAS/Supervisory Patent Examiner, Art Unit 2114
Prosecution Insights