GENERATING AND STORING AGGREGATED METRICS FOR DIFFERENT AGGREGATION GRANULARITIES FOR DIFFERENT PERIODS OF TIME FOR MONITORING OF NETWORK ELEMENTS OF A SOFTWARE-DEFINED NETWORK

Application No. 18/378,476

• Filed: Oct 10, 2023
• Examiner: ROTARU, OCTAVIAN
• Art Unit: 3624
• Tech Center: 3600 — Transportation & Electronic Commerce
• Assignee: VMware, Inc.
• OA Round: 1 (Non-Final)

Office Action

Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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.

DETAILED ACTION
The following NON-FINAL Office action is in response to application 18378476 filed 10/10/2023
Status of Claims
Claims 1-20 are currently pending and have been rejected as follows.
Priority
Receipt is acknowledged of papers submitted under 35 U.S.C. 119(a)-(d), which papers have been placed of record in the file.
Making the record clear - Claim Interpretation under MPEP 2181
Claim 16 recites “A non-transitory machine readable medium storing a program for execution by at least one processing unit” etc. Aside from the fact that claim 16 is an article claim, not a system, the Examiner also notes that the Original Specification ¶ [0001] refers to the central processing units as CPUs. Hence, it is clear that the term “at least one processing unit” at claim 16 refers to hardware structure and thus, fail the prong one of the MPEP 2181 test, and as such should not be interpreted as generic placeholders. Based on such preponderance of evidence, Examiner finds that Claims 16-20 do not invoke 112(f).

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 1-20 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.
Claim 1,16 are independent and each recite, among others:
receiving a first request to view metric data for a first time period prior to a current time;
receiving a second request to view metric data for a second time period prior to the current time;
Claims 1,16 are thus rendered vague and indefinite because it is unclear if:
- “view metric data” as subsequently recited at second “receiving” limitation, relates back to
- “view metric data” as antecedently recited at first “receiving” limitation.
Examiner recommends that Applicant amend Claim 1,16 to recite as an example only:
receiving a first request to view first metric data for a first time period prior to a current time;
receiving a second request to view second metric data for a second time period prior to the current time;
As another example Examiner recommends Applicant amend Claims 1,16 to recite among others
receiving a first request to view metric data for a first time period prior to a current time;
receiving a second request to view the metric data for a second time period prior to the current time;
Examiner recommends similar correction for “the metric data” at dependent Claims 2,17
Claims 2-15 are dependent and rejected based on rejected parent independent Claim 1.
Claims 17-20 are dependent and rejected based on rejected parent Claim 16.
Clarification and/or correction is required.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.

Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea, here abstract idea) without significantly more. The claim(s) recite(s) describe or set forth the abstract “presenting” [of] “operational data” as summarized at preamble of independent Claims 1,16 and detailed throughout the body of Claims 1-20. Such “operational data” is “collected from” “network elements in a software-defined network (SDN)” (preamble of Claims 1,16) such as from “a particular edge device” (dependent Claim 12), tested per MPEP 2106.04(A)(2) III C #2, to represent computer environment(s) upon which the abstract receiving and presenting are implemented, and associated with the first and second requests to view metric data for a first and a second time period prior to a current time (Claims 1,16). These receiving or collect[ion] of data (Claims 1,8-12,14,16) and the associated presenting of aggregated metrics (Claims 1, 3-5, 8,16-18) are not meaningfully different than the combination of collecting information, analyzing it, and displaying certain results of the collection and analysis, which according to MPEP 2106.04(a)(2) III A, 5th bullet point1, recite, describe or set forth the abstract mental processes. Here, the certain or narrowing results of the collection and analysis, are represented by recitation of: “wherein the first plurality of sets of aggregated metrics has at least one aggregated metric set that is at a different aggregation granularity than all other sets of aggregated metrics in the second plurality of sets of aggregated metrics” at last limitation of independent Claims 1,16. Yet, MPEP 2106.04 I ¶32 is clear that narrow laws that may have limited applications were still held ineligible.
It then follows that here, narrowing the abstract receiving or collecting to “wherein the first and second requests are received successively, and the first and second time periods are defined by reference to current times at which the first and second requests are received” (dependent Claims 6,19), “wherein: the first and second requests are received within one hour of each other, the first time period specifies a one month period from the current time at which the first request is received, and the second time period specifies a one week period from the current time at which the second request is received” (dependent Claim 7), “wherein at least a subset of the raw metric data is collected periodically such that for a first metric type for a particular network element, a new raw metric of the first metric type is collected” “for the particular network element at regular intervals” (dependent Claim 10), “a new raw metric of the second metric type each time the second metric type for the particular network element changes in value” (dependent Claim 11), would not preclude said claims from reciting, describing or setting forth the abstract exception.
It then also follow that here, narrowing the abstract presenting to “different granularity (independent Claims 1,16), “time period for which the user requests to view the metric data” (dependent Claims 2, 17), “presenting the first plurality of sets of aggregated metrics after the user specifies the first” (dependent Claim 3) or “second” (dependent Claim 4) “time period using the set of time controls” (dependent Claims 3,4), would not also preclude said claims from reciting, describing or setting forth the abstract exception.
Examiner again points to MPEP 2106.04(A)(2) III C to stress that performing a mental process such as that of evaluation or analysis in a computer environment (MPEP 2106.04(A)(2) III C #2) and using a computer as a tool to perform a mental process (MPEP 2106.04(A)(2) III C #3) do not preclude the claims from reciting, describing or setting forth the abstract exception. It then follows that here, the “software-defined networked (SDN)” of Claims 1,16, and its associated “collectors” of Claims 9-12, “operational data aggregator” of Claims 1,8,16, “user interface (UI)” of Claims 2,17, “time controls” of Claims 2-3, 17,18 and “selectable controls” (Claim 5) and the “query server” and “metrics managers” of dependent Claim 8 and the time-series databases TSDBs of Claims 13-15, 20 etc., could be argued to analogously represent tools for performing the abstract exception (MPEP 2106.04(a)(2) III C #3) or a computer environment (MPEP 2106.04(a)(2) III C#2) upon which the abstract idea is being performed. Thus, by such test, they would not preclude the claims from reciting the abstract exception. Step 2A prong one.
This judicial exception is not integrated into a practical application because per Step 2A prong two, because the individual or combination of additional, computer-based elements are/is found to merely apply the already recited abstract exception, as tested per MPEP 2106.05(f), and/or narrow it to a technological environment or field of use, as tested per MPEP 2106.05(h), neither of which integrates said abstract exception into a practical application. Here, the degree of automation or computerization represented by “software-defined networked (SDN)” of Claims 1,16, and its associated “collectors” of Claims 9-12, “operational data aggregator” of Claims 1,8,16, “user interface (UI)” of Claims 2,17, “time controls” of Claims 2-3, 17,18 and “selectable controls” (Claim 5) and possibly “query server” and “metrics managers” of dependent Claim 8 and the time-series databases TSDBs of Claims 13-15, 20, were found at the prior step not to preclude the claims from reciting, describing or setting forth the abstract exception.
Now, even when more granularly tested as additional, computer-based elements at Step 2A prong two, such computer components represent mere invocation of machinery to perform tasks to receive, store, and transmit data, which per MPEP 2106.05(f)(2) ¶1, does not integrate the abstract idea into a practical application. Also, when tested per MPEP 2106.05(f)(2)(iii),(v) such additional computer elements do merely monitor of audit log data [here metrics] executed on a computer [MPEP 2106.05(f)(2)(iii)], and represent use of software [“user interface”, “time controls”, “selectable controls”, “metrics managers”, “operational data aggregator”] to tailor information and provide it to user on a computer. Such level of automation or computerization as recited throughout Claims 1-20, when equally tested per MPEP 2106.05(h) vi., can also be argued as a narrowing of the abstract exception to a field of use or technological environment such as narrowing the combination of collecting information, analyzing it, and displaying certain results of collection and analysis, to data related to a technological environment. characterized here by the “software-defined networked (SDN)” of Claims 1,16, and its associated “collectors” of Claims 9-12, “operational data aggregator” of Claims 1,8,16, “user interface (UI)” of Claims 2,17, “time controls” of Claims 2-3, 17,18 and “selectable controls” (Claim 5) and possibly the “query server” and “metrics managers” of dependent Claim 8 and the time-series databases TSDBs of Claims 13-15, 20. According to MPEP 2106.05(h) such narrowing of the abstract idea to a field of use or technological environment does not integrate the abstract idea into a practical application.
Thus, Examiner provided a preponderance of legal evidence showing that the automation or computerization elements above do not integrate the abstract idea into a practical application.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because Examiner follows MPEP 2106.05(d) II guidelines and carries over the above findings at MPEP 2106.05 (f) and/or (h) to submit that as shown above, the additional elements, merely apply the already recited abstract idea [MPEP 2106.05(f)] and/or narrow it to a field of use or technological environment [MPEP 2106.05(h)]. For these same reasons, said computer-based additional elements also do not provide significantly more than the abstract idea itself, in light of MPEP 2106.05(f) and/or (h) as sufficient option(s) for evidence without having to rely on the well understood routine and conventional test of MPEP 2106.05(d). Based on such legal evidence conferred by the MPEP 2106.05(f),(h) tests above, the Examiner submits that the additional computer-based elements do not provide significantly more without having to rely on the well understood routine and conventional test of MPEP 2106.05(d).
Yet, assuming arguendo, that further evidence would be required to demonstrate conventionality of the additional, computer-based elements, the Examiner would further point to MPEP 2106.05(d) to demonstrate that said additional elements remain well-understood, routine, conventional. In such case, Examiner would rely on the Original Specification as follows:
- Original Specification ¶ [0001] reciting, at high level of generality: “An edge gateway segregates an internal network from an external network. Edge gateways are often implemented as hardware appliances using application specific integrated circuits (ASICs) or as software appliances executing on computers with commodity central processing units (CPUs). As the edge gateway serves as the ingress and egress node of a network to let traffic in and out of the network, monitoring the edge gateway's health is critical. For instance, it is critical to monitor the CPU usage of an edge gateway to ensure that the edge gateway does not get overloaded with traffic (which can lead to the edge gateway dropping traffic).
- Original Specification ¶ [00201] 3rd-4th sentences reciting, at high level of generality: “The processes 2335 include metrics collectors operating on one or more host computers and/or hardware physical forwarding elements (e.g., edge devices) in the SDN. In some embodiments, a metrics collector is deployed as a plugin on each host computer and/or each hardware physical forwarding element (e.g., an edge device) in the SDN to collect metrics for the host computer or edge device on which it is deployed”.
- Original Specification ¶ [00218] 3rd sentence, reciting at high level of generality: “As discussed previously, a metrics collector may be deployed as a plugin on each host computer and/or each hardware physical forwarding element (e.g., an edge device) in the SDN to collect metrics for the host computer or edge device on which it is deployed”
- Original Specification ¶ [00278] reciting at high level of generality: Finally, as shown in Figure 34, bus 3405 also couples computer system 3400 to a network 3465 through a network adapter (not shown). In this manner, the computer can be a part of a network of computers (such as a local area network ("LAN"), a wide area network ("WAN"), or an Intranet, or a network of networks, such as the Internet. Any or all components of computer system 3400 may be used in conjunction with the invention.
- Original Specification ¶ [00279] reciting, at high level of generality: “Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer- readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra-density optical discs, and any other optical or magnetic media. The computer-readable media may store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter”.
- Original Specification ¶ [00280] reciting, at high level of generality: “While the above discussion primarily refers to microprocessor or multi-core processors that execute software, some embodiments are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions that are stored on the circuit itself”.
- Original Specification ¶ [00281] reciting, at high level of generality: “As used in this specification, the terms "computer", "server", "processor", and "memory" all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification, the terms "computer readable medium," "computer readable media," and "machine readable medium" are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral or transitory signals”.
- Original Specification ¶ [00282] 5th sentence, reciting at high level of generality: “Thus, one of ordinary skill in the art would understand that the invention is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims”.
All of this preponderance of factual and/or legal evidence demonstrate that the additional computer-based elements fail to provide anything significantly more. Thus Claims 1-20, although directed to statutory categories (here “method” or process at Claims 1-15 and “non-transitory medium” or computer product at Claims 16-20) they still recite, or at least set forth the abstract idea (Step 2A prong one), with their additional, computer-based elements not integrating the abstract idea into a practical application (Step 2A prong two) or providing significantly more than abstract idea (Step 2B). Thus, Claims 1-20 are patent ineligible.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim Rejections - 35 USC § 102
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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,8-12 and 16 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by:
Yelahanka Raghuprasad et al US 20240039842 A1 hereinafter Yelahanka. As per
Claims 1,16 Yelahanka teaches “A method of presenting operational data collected from a plurality of network elements in a software-defined network (SDN), the method comprising: at an operational data aggregator of the SDN”: / “A non-transitory machine readable medium storing a program for execution by at least one processing unit for presenting operational data collected from a plurality of network elements in a software defined network (SDN), the program comprising sets of instructions for: at an operational data aggregator of the SDN”: (Yelahanka ¶ [0069] the techniques herein performed by hardware, software, and/or firmware in accordance with telemetry granularity control process 249, which include computer executable instructions executed by the processor 220 (or independent processor of interfaces 210) to perform functions relating to the techniques described herein. For example, at ¶ [0071] 3rd sentence: telemetry granularity control process 249 executed by a controller for a network (e.g., SDN controller 408 in Figs. 4A-4, a path computation element, etc.), a particular networking device in the network (e.g. router), another device or service in communication therewith, or the like. ¶ [0110] 3rd sentence: it is expressly contemplated that the components and/or elements described herein can be implemented as software being stored on non-transitory computer-readable medium having program instructions executing on a computer, hardware, firmware, or a combination thereof)

- “receiving a first request to view metric data for a first time period prior to a current time”; (Yelahanka ¶ [0065] 2nd-3rd sentences: noting an example where for a network path whose path metrics are seasonal in nature, input at minute-level granularity would be unnecessary, as the path does not exhibit any significant changes at high frequency. Given stability/predictability of the path metrics, a more appropriate granularity would be at hourly-level. ¶ [0068] 4th sentence: the techniques herein then translate the computed granularity and retention history for the path metrics into a telemetry collection policy for the network. In addition, the techniques herein may also be implemented in a dynamic manner such as by repeatedly monitoring the performance of the prediction model and adjusting the telemetry collection/reporting, accordingly (e.g., in the case of a detected network event or fluctuation in the performance of the model. ¶ [0076] timeseries feature extractor 504 may extract different path metric timeseries from the path metrics in path telemetry data 516. In addition, timeseries feature extractor 504 may also identify the features of the timeseries for the path metrics, such as occurrences of peaks, seasonality of peaks, the times for which seasonality is observed, the confidence of such determinations, etc. For example, at
Yelahanka ¶ [0093], ¶ [0085] 3rd sentences: system detect series of network event periods 802 (e.g., during which the timeseries exhibits peaks) that are seasonal and occur daily. Thus at
Yelahanka ¶ [0090] 3rd sentence: granularity & history estimator 508 configure granularity of 1 hour for this metric. Yet, per ¶ [0089] 2nd sentence: measuring the latency along a path at low measurement frequency/coarse granularity (e.g., every hour) will provide less information about the true performance of the path than at higher measurement frequency/fine granularity (e.g. every 10 minutes) as detailed later). Lat but not least ¶ [0102] 4th sentence: granularity announcer 514 may also control the granularity and history duration indirectly, as well, such as by announcing them to another system that oversees the collection and reporting of path telemetry data 516).

- “presenting a first plurality of sets of aggregated metrics created for the first time period;
(Yelahanka ¶ [0013] Figs.9A-B illustrate example plots contrasting path metric timeseries at different measurement granularities. ¶ [0090] 1st-2nd sentences: Fig.9A [below] illustrates an example plot 900 comparing the results of measuring timeseries of SLA violation path metric at granularity / measurement frequency of every 10 minutes to that of a granularity/measurement frequency of every 1 hour. At coarser granularity of 1 hr measurement intervals, information about the detected peaks is preserved. Yet, per ¶ [0089] 1st sentence: the coarser the granularity of a given path metric, the lower the amount of information it provides about the timeseries. Indeed, measuring the latency along a path at a relatively low measurement frequency/coarse granularity (e.g., every hour) will provide less information about the true performance of the path than at a higher measurement frequency/fine granularity (e.g., every 10 minutes).
- “receiving a second request to view metric data for a second time period prior to the current time”; (Yelahanka ¶ [0064] 4th-5th sentences: Testing has revealed that the granularity and length of history for the input can often be too small or too large based on the timeseries characteristics of the network path. Here, the granularity of a path metric refers to the frequency at which the path metric is measured and/or used as input to the prediction model. ¶ [0068] 4th sentence: the techniques herein then translate the computed granularity and retention history for the path metrics into a telemetry collection policy for the network. In addition, the techniques herein may also be implemented in a dynamic manner such as by repeatedly monitoring the performance of the prediction model and adjusting the telemetry collection/reporting, accordingly (e.g., in the case of a detected network event or fluctuation in the performance of the model. ¶ [0076] timeseries feature extractor 504 extract different path metric timeseries from path metrics in path telemetry data 516. In addition, timeseries feature extractor 504 also identify features of the timeseries for the path metrics, such as occurrences of peaks, seasonality of peaks, the times for which seasonality is observed, the confidence of such determinations, etc. For example,
Yelahanka ¶ [0089] 2nd-4th sentences measuring latency along a path at low measurement frequency /coarse granularity (every 1 hour) will provide less info about true performance of the path than at higher measurement frequency/fine granularity (every 10 minutes). Thus, it is important for any higher granularity of the path metrics to preserve the info on network events and early signs that were observed at finer granularity. Thus, granularity and history estimator 508 may determine the maxim possible granularity (i.e., lowest measurement frequency) such that all or most info in the raw timeseries is preserved. For example, at ¶ [0066] 2nd sentence: the system require input telemetry at finest available granularity. This is because at ¶ [0091]: using granularity of 1 hour in Fig.9A significantly reduce the amount of info obtained about the probability of SLA violation path metric. Indeed, at granularity of 10 minutes at Fig.9B, the system may be able to identify 5 multiple peaks/events over the course of a day, some of which also exhibit early signs).

- “presenting a second plurality of sets of aggregated metrics created for the second time period, wherein the first plurality of sets of aggregated metrics has at least one aggregated metric set that is at a different aggregation granularity than all other sets of aggregated metrics in the second plurality of sets of aggregated metrics” (Yelahanka ¶ [0064] 4th-5th sentences: Testing has revealed that the granularity and length of history for the input can often be too small or too large based on the timeseries characteristics of the network path. Here, the granularity of a path metric refers to the frequency at which the path metric is measured and/or used as input to the prediction model. ¶ [0089] 3rd-4th sentences: it is important for any higher granularity of the path metrics to preserve the information on network events and early signs that were observed at a finer granularity. Thus, granularity and history estimator 508 determine the maxim possible granularity (i.e., lowest measurement frequency) such that all or most of the information in the raw timeseries is preserved).¶ [0013] Figs.9A-B illustrate example plots contrasting path metric timeseries at different measurement granularities. For example, at ¶ [0091]: using a granularity of 1 hour in Fig.9A significantly reduce the amount of info that can be obtained about the probability of SLA violation path metric. Indeed, at granularity of 10 minutes at Fig. 9B [below], the system may be able to identify 5 multiple peaks/events over the course of a day, some exhibiting early signs).

PNG
media_image1.png
630
882
media_image1.png
Greyscale

PNG
media_image2.png
636
878
media_image2.png
Greyscale

Yelahanka Figs. 9A-B in support of rejection arguments
Claim 8. Yelahanka teaches all the limitations in claim 1 above. Furthermore,
Yelahanka teaches, “wherein the operational data aggregator of the SDN comprises”
“(i) a metrics query server for receiving the first and second requests” (Yelahanka ¶ [0071] 2nd sentence: At core of architecture 500 is telemetry granularity control process 249 … executed by controller for…a server… ¶ [0072] 1st sentence As shown telemetry granularity control process 249 include any or all of… network event tagger 502, timeseries feature extractor 504, early signs estimator 506, granularity and history estimator 508, path bootstrapper 510, accuracy balancer 512, and/or granularity announcer 514. For example, at ¶ [0076] timeseries feature extractor 504 extract different path metric timeseries from the path metrics in path telemetry data 516. In addition, timeseries feature extractor 504 also identify the features of the timeseries for the path metrics, such as occurrences of peaks, seasonality of peaks, times for which seasonality is observed, confidence of such determinations etc.) “and presenting the first and second pluralities of sets of aggregated metrics” (Yelahanka ¶ [0013] Figs.9A-B illustrate example plots contrasting path metric timeseries at different measurement granularities. ¶ [0089] the coarser the granularity of a path metric, the lower amount of info it provides about the timeseries. Indeed, measuring latency along a path at relatively low measurement frequency/coarse granularity (every hour) will provide less info about true performance of the path than at higher measurement frequency/fine granularity (e.g. every 10 minutes). Thus, it is important for any higher granularity of the path metrics to preserve the information on network events and early signs that were observed at finer granularity. Accordingly, granularity and history estimator 508 may determine maximum possible granularity (i.e. lowest measurement frequency) such that all or most of the info in the raw timeseries is preserved. ¶ [0090] For example, Fig.9A illustrates plot 900 comparing results of measuring a timeseries of the probability of SLA violation path metric at granularity/measurement frequency of every 10 minutes to that of a granularity / measurement frequency of every hour. As can be seen, even at a coarser granularity of 1 hour measurement intervals, information about the detected peaks is preserved. In such a case, granularity and history estimator 508 may opt to configure a granularity of one hour for this metric. ¶ [0091] In contrast, in plot 910 in Fig.9B, using a granularity of 1 hour would significantly reduce the amount of info that can be obtained about the probability of SLA violation path metric. Indeed, at a granularity of 10 minutes, the system may be able to identify 5 multiple peaks/events over the course of a day, some of which also exhibit early signs. However, when a coarser granularity of 1 hour is used for same timeseries, the system may only be able to detect 2 such peaks/events, meaning that info about the other 3 are lost because of aggregation (average) and none of early signs are preserved. This most definitely would cause a decrease in the accuracy of the prediction model and visibility into the behavior of the path. In such a case, granularity and history estimator 508 may elect to use granularity/measurement frequency of 10 minutes for the path metric) “and”

“(ii) a set of one or more metrics managers for creating different sets of aggregated metrics based on each other and based on raw metric data collected for the plurality of network elements in the SDN”. (Yelahanka ¶ [0072] 1st sentence: telemetry granularity control process 249 may include any or all of the following components: … a granularity and history estimator 508, a path bootstrapper 510, accuracy balancer 512, and granularity announcer 514. ¶ [0089] 4th sentence: granularity and history estimator 508 determine maximum possible granularity (i.e. lowest measurement frequency) such that all or most of the info in the raw timeseries is preserved. Then
Yelahanka ¶ [0096] path bootstrapper 510 may, for every granularity gi, the time series of the path P is compared with every [or each] other path P′. In turn, path bootstrapper 510 may then compare the time series distance between P and P′, d(P, P′, gi), using an approach such as Dynamic Time Warping (DTW). Path bootstrapper 510 may then pick the nearest path P′ as most similar path which has the least distance for every granularity gi. ¶ [0099] 3rd sentence: a BGP route change event may trigger reevaluation of the model accuracy by accuracy balancer 512.
Yelahanka ¶ [0100] accuracy balancer 512 may also all of the information regarding the performance of the prediction model and the current configuration to a user interface for review by a network administrator. In some cases, accuracy balancer 512 may only trigger a configuration change in response to a request from the user interface to do so, potentially also presenting the proposed change(s) to the administrator, first. For instance, accuracy balancer 512 may indicate that the proposed granularity and history may have an impact on the accuracy of the predictions, but reduce the amount of telemetry data to be gathered and stored. Finally, at
Yelahanka ¶ [0102] telemetry granularity control process 249 also include granularity announcer 514, which is responsible for causing the determined granularity and history is duration to be used in the network for the path metrics of a given path. For instance, as shown, granularity announcer 514 may send granularity instruction 522 to router 110 that includes instructions to measure the latency of a given path by sending probes 518 along that path at a specified frequency. In addition, an instruction regarding the required history for such path metrics could also be sent such that the path telemetry data 516 consumed by the prediction model of predictive routing process 248 are limited to the determined span of time. Of course, granularity announcer 514 may also control the granularity and history duration indirectly, as well, such as by announcing them to another system that oversees the collection and reporting of path telemetry data 516).

Claim 9. Yelahanka teaches all the limitations in claim 8 above. Furthermore,
Yelahanka teaches “wherein the raw metric data is collected by a set of one or more metrics collectors operating on at least one of host computers and edge devices in the SDN”. (Yelahanka ¶ [0072] 1st sentence: telemetry granularity control process 249 include: network event tagger 502, a timeseries feature extractor 504, an early signs estimator 506, a granularity and history estimator 508, a path bootstrapper 510, an accuracy balancer 512, and/or a granularity announcer 514. ¶ [0074] 1st sentence: One mechanism to measure the path metrics may be for router 110 at the edge of the network to send out probes 518 (e.g. BFD probes, HTTP probes, etc.) along a given network path (e.g. SD-WAN tunnel, a direct Internet access path, etc.) at certain frequency, on demand and/or in response to detection of a certain event in network. Yelahanka ¶ [0076] In various embodiments, timeseries feature extractor 504 may extract different path metric timeseries from the path metrics in path telemetry data 516. In addition timeseries feature extractor 504 may also identify the features of the timeseries for the path metrics, such as occurrences of peaks, seasonality of peaks, times for which seasonality is observed, the confidence of such determinations, etc. ¶ [0102] 2nd sentence: as shown, granularity announcer 514 send granularity instruction 522 to router 110 that includes instructions to measure the latency of a given path by sending probes 518 along that path at a specified frequency.
Yelahanka ¶ [0083] feature extractor 504 may be executed in cloud, other embodiments provide for it to be executed locally on a networking device, such as router 110. If executed at the edge of the network, for instance, the edge device may send the extracted timeseries features along with the network events tagged by network event tagger 502 for analysis by the other components of telemetry granularity control process 249 shown.¶ [0089] 4th sentence: granularity and history estimator 508 may determine the maximum possible granularity (lowest measurement frequency) such that all or most of the information in the raw timeseries is preserved).

Claim 10. Yelahanka teaches all the limitations in claim 9 above. Furthermore,
Yelahanka teaches “wherein at least a subset of the raw metric data is collected periodically such that for a first metric type for a particular network element, a new raw metric of the first metric type is collected by a particular metrics collector for the particular network element at regular intervals” (Yelahanka ¶ [0068] 5th sentence: the techniques herein may also be implemented in dynamic manner such as by repeatedly monitoring the performance of the prediction model… ¶ [0074] 1st sentence: One mechanism to measure the path metrics may be for router 110 at edge of the network to send out probes 518 (e.g. BFD probes, HTTP probes, etc.) along a given network path (e.g. SD-WAN tunnel, direct Internet access path, etc.) at a certain frequency… ¶ [0084] 3rd-4th sentences: consider the case where the probability of an SLA violation goes from below 5% to above 10% (e.g., a network event). In such a case, early signs estimator 506 may identify the time period prior to this event in which the timeseries exhibited unusual fluctuations or other types of variations in the path metrics (or in another related set of path metrics), and tags that time period as an early sign of an impending peak or other network event exhibited by the time series. Also see ¶ [0085] 3rd-4th sentences: system detect a series of network event periods 802 (e.g. during which the timeseries exhibits peaks) that are seasonal and typically occur daily. In addition, preceding each of these network event periods 802 may be early sign time periods 804 during which probability of an SLA violation path metric begins to fluctuate. For example, at ¶ [0090] Fig.9A illustrates plot 900 comparing the results of measuring a timeseries of probability of SLA violation path metric at a granularity / measurement frequency of every 10 minutes to that of granularity / measurement frequency of 1 hour. As can be seen, even at coarser granularity of one 1 measurement intervals, information about the detected peaks is preserved. In such a case, granularity and history estimator 508 opt to configure a granularity of 1 hour for this metric. ¶ [0099] 1st, 4th sentences: Accuracy balancer 512 run periodically or under other circumstances, such as when there are fluctuations observed in the accuracy of the predictions. When the accuracy of the prediction model falls below an acceptable level, accuracy balancer 512 may notify the other components of telemetry granularity control process 249, so as to compute a new granularity and history duration for the path metrics).

Claim 11. Yelahanka teaches all the limitations in claim 10 above. Furthermore,
Yelahanka teaches: “wherein for a second metric type for the particular network element, the particular metrics collector receives a new raw metric of the second metric type each time the second metric type for the particular network element changes in value”
(Yelahanka ¶ [0068] 5th sentence: the techniques herein may also be implemented in dynamic manner such as by repeatedly monitoring the performance of the prediction model and adjusting the telemetry collection/reporting, accordingly (e.g. in case of a detected network event or fluctuation in the performance of the model. ¶ [0074] 1st sentence: One mechanism to measure the path metrics may be for router 110 at edge of the network to send out probes 518 (e.g. BFD probes, HTTP probes, etc.) along a given network path (e.g. SD-WAN tunnel, a direct Internet access path, etc.)…in response to the detection of a certain event in the network. For example at
Yelahanka ¶ [0084] 3rd-4th sentences: consider the case where probability of SLA violation goes from below 5% to above 10% (e.g. network event). In such a case, early signs estimator 506 identify the time period prior to this event in which timeseries exhibited unusual fluctuations or other types of variations in the path metrics (or in other related set of path metrics), and tags that time period as early sign of impending peak or other network event exhibited by time series.
Yelahanka ¶ [0085] 3rd-4th sentences: system detect a series of network event periods 802 (during which the timeseries exhibits peaks) that are seasonal and occur daily. In addition, preceding each of these network event periods 802 may be early sign time periods 804 during which probability of an SLA violation path metric begins to fluctuate. ¶ [0091] In contrast [to Fig. 9A], as shown in plot 910 in Fig. 9B, using a granularity of 1 hour would significantly reduce the amount of information that can be obtained about the probability of an SLA violation path metric. Indeed, at a granularity of 10 minutes, the system may be able to identify 5 multiple peaks/events over the course of a day, some of which also exhibit early signs. However, when a coarser granularity of 1 hour is used for the same timeseries, the system may only be able to detect 2 such peaks / events, meaning that information about the other 3 are lost because of aggregation (average) and none of the early signs are preserved. This most definitely would cause a decrease in the accuracy of the prediction model and visibility into the behavior of the path. In such a case, granularity and history estimator 508 may elect to use a granularity/measurement frequency of 10 minutes for the path metric. ¶ [0099] 1st, 4th sentences: Accuracy balancer 512 run periodically or under other circumstances, such as when [or each time] there are fluctuations observed in the accuracy of the predictions. When [or each time] the accuracy of the prediction model falls below an acceptable level, accuracy balancer 512 notify the other components of telemetry granularity control process 249, so as to compute a new granularity and history duration for the path metrics)

Claim 12. Yelahanka teaches all the limitations in claim 11 above. Furthermore,
Yelahanka teaches “wherein the particular network element is a particular edge device of the SDN, and the particular metrics collector operates on the particular edge device to collect the raw metric data associated with the particular edge device”. (Yelahanka ¶ [0074] 1st sentence: One mechanism to measure the path metrics may be for router 110 at the edge of the network to send out probes 518 (e.g. BFD probes, HTTP probes, etc.) along a given network path (e.g. an SD-WAN tunnel..etc) at certain frequency, on demand, and/or in response to detection of a certain event in the network. ¶ [0083]...feature extractor 504 may be executed …locally on a networking device, such as router 110. If executed at the edge of the network…the edge device may send the extracted timeseries features along with the network events tagged by network event tagger 502 for analysis by the other components of telemetry granularity control process 249 shown).

Rejections under 35 § U.S.C. 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.

Claims 2-4, 17 are rejected under 35 U.S.C. 103 as being unpatentable over
Yelahanka as applied to claims 1,16 above, in view of
Chen US 20170083585 A1 hereinafter Chen. As per:
Claims 2,17. Yelahanka teaches all the limitations in claims 1,16. Yelahanka does not recite:
- “wherein before the receiving and presentation operations, presenting a set of one or more time controls in a user interface (UI) to allow a user to specify a time period for which the user requests to view the metric data” as claimed.
Chen however in analogous monitoring network elements according to performance metrics, logs, tasks and events, and topology from hosts, virtual machines and virtual centers at various granular levels of operational visibility (Chen ¶ [0195]) and at various levels of aggregation (Chen ¶ [0174]-¶ [0176], ¶ [0231] last 2 sentences) teaches or suggests:
- “wherein before the receiving and presentation operations, presenting a set of one or more time controls in a user interface (UI) to allow a user to specify a time period for which the user requests to view the metric data” (Chen ¶ [0152] 2nd-6th sentences: Search screen 600 includes a search bar 602 that accepts user input as a search string. It also includes a time range picker 612 that enables the user to specify a time range for the search. For historical searches the user select a specific time range, or a relative time range, i.e. today, yesterday or last week. For real-time searches, the user can select the size of a preceding time window to search for real-time events. Search screen 600 also initially displays a data summary dialog as is illustrated in Fig.6B that enables the user to select different sources for the event data, such as by selecting specific hosts and log files. Similarly, Figs. 33A-B, 34-36, ¶ [0331], ¶ [0333] -¶ [0039], ¶ [0351]).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Yelahanka’s method/non-transitory medium to have included Chen’s teachings or suggestions in order to have provided a broader picture or cloud computing resources (Chen ¶ [0005] in view of MPEP 2143 C, D and/or G) and a more efficient search of operations (Chen ¶ [0145] in view of MPEP 2143 C, d and/or G). The predictability of such modification would have been corroborated by the broad level of skills of one of ordinary skills in the art as articulated by Yelahanka ¶ [0034] in view of Chen ¶ [0100], ¶ [0123], ¶ [0223], ¶ [0226].
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar monitoring network elements field of endeavor. In such combination, each element would have merely performed the same analytical and processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Yelahank in view of Chen, the to be combined elements would have fitted together, like pieces of a puzzle in a logical, complementary, technologically feasible and/or econocmailly desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).

Claim 3. Yelahanka / Chen teaches all the limitations in claim 2 above.
Yelahanka does not explicitly recite:
- “wherein presenting the first plurality of sets of aggregated metrics comprises presenting the first plurality of sets of aggregated metrics after the user specifies the first time period using the set of time controls” as claimed. However,
Chen in analogous monitoring network elements according to performance metrics, logs, tasks and events, and topology from hosts, virtual machines and virtual centers at various granular levels of operational visibility (Chen ¶ [0195]), and at various levels of aggregation (Chen ¶ [0174]-¶ [0176], ¶ [0231] last two sentences) teaches or at least suggests:
- “wherein presenting the first plurality of sets of aggregated metrics comprises presenting the first plurality of sets of aggregated metrics after the user specifies the first time period using the set of time controls” (Chen ¶ [0231] 6th sentence: aggregate KPIs defined to provide a measure of service performance calculated from a set of service aspect KPI values; this aggregate may even be taken across defined timeframes and/or across multiple services. For example, at
Chen ¶ [0152] 3rd-4th sentence: time range picker 612 enables user to specify a time range for the search. For historical searches the user selects a relative time range, such as last week
Chen ¶ [0318] Fig.29B, same interface 2900A display topology map 2902B, representing same collection of resources displayed in topology map 2902A of Fig.29A but at different point in time. For example, display of topology map 2902B occur few seconds after user starts a time-lapse display for topology map, or in response to user advancing the topology map display to a particular point in time using the time slider. Additional details at Fig. 34 ¶ [0333]-¶ [0339])
Rationales to have modified/combined Yelahanka / Chen are above and reincorporated.

Claim 4. Yelahanka / Chen teaches all the limitations in claim 2 above.
Yelahanka does not explicitly recite: “wherein presenting the second plurality of sets of aggregated metrics comprises presenting the second plurality of sets of aggregated metrics after the user specifies the second time period using the set of time controls”.
Chen however in analogous monitoring network elements according to performance metrics, logs, tasks and events, and topology from hosts, virtual machines and virtual centers at various granular levels of operational visibility (Chen ¶ [0195]), and at various levels of aggregation (Chen ¶ [0174]- ¶ [0176], ¶ [0231] last 2 sentences) teaches or at least suggests:
- “wherein presenting the first plurality of sets of aggregated metrics comprises presenting the first plurality of sets of aggregated metrics after the user specifies the first time period using the set of time controls” (Chen ¶ [0231] 6th sentence aggregate KPIs defined to provide a measure of service performance calculated from a set of service aspect KPI values; this aggregate may even be taken across defined timeframes and/or across multiple services. For example, at
Chen ¶ [0152] 3rd-4th sentence: time range picker 612 enables user to specify a time range for the search. For historical searches the user can select a relative time range, such as yesterday
Chen ¶ [0318] Fig.29B, same interface 2900A display topology map 2902B, representing same collection of resources displayed in topology map 2902A of Fig.29A but at different point in time. For example, display of topology map 2902B occur few seconds after user starts a time-lapse display for topology map, or in response to user advancing the topology map display to a particular point in time using the time slider. Additional details at Fig. 34 ¶ [0333]-¶ [0339]).
Rationales to have modified/combined Yelahanka / Chen are above and reincorporated.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 5,18 are rejected under 35 U.S.C. 103 as being unpatentable over
Yelahanka as applied to claims 1,16 above, in view of
Pelloin et al, US 20200356229 A1 hereinafter Pelloin. As per,
Claims 5,18 Yelahanka teaches all the limitations in claims 1,16 above.
Yelahanka does not “wherein presenting the first plurality of sets of aggregated metrics comprises first presenting one selectable control for each set of aggregated metrics in the first plurality of sets of aggregated metrics, wherein a user's selection of any particular selectable control for any particular set of aggregated metrics in the first plurality of sets of aggregated metrics results in presenting operational data for the particular set of aggregated metrics”.
Pelloin however in analogous monitoring network elements teaches or suggests: - “wherein presenting the first plurality of sets of aggregated metrics comprises first presenting one selectable control for each set of aggregated metrics in the first plurality of sets of aggregated metrics, wherein a user's selection of any particular selectable control for any particular set of aggregated metrics in the first plurality of sets of aggregated metrics results in presenting operational data for the particular set of aggregated metrics”
(Pelloin ¶ [0033] 4th sentence: data 110 may be obtained from, without limitation… a Software-Defined Networking (SDN) controller, an SDN application… ¶ [0088] Fig.5E illustrates a screenshot where the timeline 500 is displayed with additional summary tiles 540,542,544. The purpose of timeline 500 is to visualize events 502 and their duration, severity, and impact. The summary tiles 540, 542, 544 provide a summary view, such as networkwide in the telecom example. The summary tile 540 shows the services with their impacted subscribers. It shows the same information as the timeline 500 in an aggregated version. When a summary bar is selected by hovering a cursor 550 over it, all events 502A, 502B, 502D, 502E, 502F, 502G containing the hovered item are visually highlighted in the timeline below. In the example shown, the cursor 550 hovers over the idle mobility service, and all the idle mobility events 502A, 502B, 502D, 502E, 502F, 502G are highlighted with a green filling).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Yelahanka’s “method/non-transitory medium” to have included Pelloin’s teachings or suggestions in order to have simplified, identified and prioritize events, and have utilized the resources effectively (Pelloin ¶ [0003] last sentence in view of MPEP 2143 C, D and/or G). The predictability of such modification would have been corroborated by the broad level of skills of one of ordinary skills in the art as articulated by Yelahanka ¶ [0034] in view of Pelloin ¶ [0036], ¶ [0052], ¶ [0056], ¶ [0084], ¶ [0212]).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor dealing with monitoring network elements. In such combination each element merely would have performed same analytical and processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Yelahanka in view of Pelloin, the to be combined elements would have fitted together, like puzzle pieces in a logical, complementary, and/or technologically feasible manner. Thus, it would have been reasoned that, the results of combination would have been predictable (MPEP 2143 A).

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 6,7,19 are rejected under 35 U.S.C. 103 as being unpatentable over
Yelahanka as applied to claims 1,16 above, in view of
Nowak-Przygodzki et al US 20160078086 A1 hereinafter Nowak-Przygodzki
in further view of Reehil et al, US 20210133245 A1 hereinafter Reehil. As per,
Claims 6,19 Yelahanka teaches all the limitations in claims 1,16 above.
Yelahanka does not recite: “wherein the first and second requests are received successively, and the first and second time periods are defined by reference to current times at which the first and second requests are received” as explicitly claimed.
Nowak-Przygodzki in analogous monitoring queries in a computer system teaches:
“wherein the first and second requests are received successively” (Nowak-Przygodzki ¶ [0023] 3rd sentence: a session include queries submitted within a specified time range from an initial query, e.g., all queries submitted within one hour of a first query).
It would have been obvious to one skilled in the art before the effective filling date of the claimed invention, to have modified Yelahanka’s “method” / “non-transitory medium” to have included Nowak-Przygodzki’s teachings in order to have provided more relevant query results to the user (Nowak-Przygodzki ¶ [0011] in view of MPEP 2143 C, D and/or G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor that monitors queries in a computer system. In such combination each element would have merely performed same analytical and processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Yelahanka in view of Nowak-Przygodzki, the to be combined elements would have fitted together like pieces of a puzzle in a logical, complementary and technologically feasible manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
* Further still *
Reehil in analogous art of tracking in state version information teaches or suggests: ”and
the first and second time periods are defined by reference to current times at which the first and second requests are received”
(Reehil ¶ [0046] 3rd sentence: the truncation time may be one hour prior to the current time, one week prior to the current time, one month prior to the current time, six months prior to the current time, one year prior to the current time, and so forth).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have further modified Yelahanka / Nowak-Przygodzki to have included Reehil’s teachings to have better balanced the amount of information needed to be stored (e.g. if there would have been storage constraints, such as storage constraints based on cost of storage, based on how much the graph changes over time, and so forth) and a length of time for which the historical graph state information would have been needed (e.g. how far back in time it would have been necessary or desirable to look at historical graph state information for various management purposes) (Reehil ¶ [0046] 4th sentence in view of MPEP 2143 C, D and/or G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor, dealing with monitoring information of network elements. In such combination each element would have merely performed same analytical and processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Yelahanka / Nowak-Przygodzki in further view of Reehil, the to be combined elements would have fitted together, like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).

Claim 7 Yelahanka / Nowak-Przygodzki / Reehil teaches all the limitations in claim 6 above
Yelahanka does not teach “the first and second requests are received within one hour of each other, the first time period specifies a one month period from the current time at which the first request is received, and the second time period specifies a one week period from the current time at which the second request is received” as claimed. However
Nowak-Przygodzki in analogous monitoring queries through network teaches/suggests:
- “the first and second requests are received within one hour of each other”
(Nowak-Przygodzki ¶ [0023] 3rd sentence: a session can include queries submitted within a specified time range from initial query, e.g. all queries submitted within one hour of a first query).
Rationales to have modified/combined Yelahanka / Nowak-Przygodzki are above and reincorporated.
Reehil in analogous art of tracking in state version information further teaches or suggests:
- “the first time period specifies a one month period from the current time at which the first request is received” (Reehil ¶ [0019] network 105 includes software defined network SDN controller 155. In one example, the SDN controller 155 comprise a computing device or processing system (server), such as computing system 500 in Fig. 5, and configured to provide operations or functions in connection with examples of the present disclosure providing historical state management in graph databases. ¶ [0046] 3rd sentence: For example, the truncation time may be one hour prior to the current time… one month prior to the current time,…), “and”
- “the second time period specifies a one week period from the current time at which the second request is received” (Reehil ¶ [0019] network 105 includes software defined network SDN controller 155. In one example, the SDN controller 155 comprise a computing device or processing system (server), such as computing system 500 in Fig. 5, and configured to provide operations or functions in connection with examples of the present disclosure providing historical state management in graph databases. ¶ [0046] 3rd sentence: For example, the truncation time may be one hour prior to the current time, one week prior to the current time…),
Rationales to have further modified Yelahanka / Nowak-Przygodzki to have further included Reehil are above and have been reincorporated herein.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 13,14,20 are rejected under 35 U.S.C. 103 as being unpatentable over
Yelahanka as applied to claims 1,16 above, in view of
Huang et al, US 20220311680 A1 hereinafter Huang. As per,
Claims 13,20 Yelahanka teaches all the limitations in claims 1,16 above.
Yelahanka does not teach: “wherein the first and second pluralities of sets of aggregated metrics are stored in a time-series database (TSDB) such that different sets of aggregated metrics aggregated at different aggregation granularities are stored in the TSDB for different lengths of time according to their aggregation granularity”.
Huang however in analogous monitoring operational states of network elements teaches or suggests: “wherein the first and second pluralities of sets of aggregated metrics are stored in a time-series database (TSDB) such that different sets of aggregated metrics aggregated at different aggregation granularities are stored in the TSDB for different lengths of time according to their aggregation granularity” (Huang ¶ [0037] 1st sentence: a distributed pipeline is co-located with the data source such that each of the data gateways 110 a-n is a data pipeline that has… a local time series database (TSDB). ¶ [0052] 6th sentence: While in one example, the raw data 118 may remain in local TSDBs (the local TSDB 116) to reduce the amount of data exported to the TSDB 142, in other example, complexities of assurance monitoring task require data to be exported to TSDB 142. ¶ [0053] 4th-7th sentences: The rolled up raw data 144 is aggregated raw data from various data gateways 110a-n. The local TSDB 116 on data gateway 110a may be time limited (storage is limited to a few hours), while the assurance monitoring task may require a longer interval and/or aggregate data. It may be useful to capture some aggregate data collected over a fixed interval (for example, an hour) to the TSDB 142. With the TSDB 142, there are several data gateways 110a-n that dump their raw data 118 to the TSDB 142).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Yelahanka’s method/non-transitory medium to have included
Huang’s teachings in order to have effectively monitor the production network is a complex task (Huang ¶ [0003] 6th sentence. For example, Huang would have detected when the error rate goes below threshold, so that the system would have automatically turned off OpticsHealthy monitoring (disables monitoring resource) so that the system would have continued to monitor the large-scale network efficiently (Huang ¶ [0060] 5th sentence in view of MPEP 2143 C, D and/or G)
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor dealing with monitoring of network elements. In such combination each element would have merely performed the same analytical and processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Yelahanka in view of
Huang the to be combined elements would have fitted together, like pieces of a puzzle in a logical, complementary, and technologically feasible, manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).

Claim 14 Yelahanka / Huang teaches all the limitations in claim 13 above.
Yelahanka teaches or suggests “wherein at least a subset of the first and second sets of aggregated metrics is aggregated from collected raw metric data” (Yelahanka ¶ [0089] 3rd-4th sentences: it is important for any higher granularity [1st sets] of the path metrics to preserve the info on network events and early signs observed at finer granularity [2nd set]. Thus, granularity and history estimator 508 may determine maximum possible granularity (lowest measurement frequency) such that all or most of the information in the raw timeseries is preserved).

Yelahanka does not teach “the raw metric data is stored in a volatile memory separate from the TSDB” as explicitly claimed.

Huang however in analogous monitoring network elements teaches/suggests:
- “the raw metric data is stored in a volatile memory separate from the TSDB”.
(Huang ¶ [0052] last sentence: the raw data 118 may remain in local [or separate] TSDBs (the local TSDB 116) to reduce the amount of data exported to the [external] TSDB 142 [interpreted as the claimed TSDB]. ¶ [0053] 5th sentence: The local TSDB 116 on the data gateway 110 a may be time limited (storage is limited to a few hours) [thus volatile]…This is corroborated by ¶ [0100] 1st sentence: entities described herein may store data/information in volatile memory).
Rationales to have modified/ combined Yelahanka / Huang are above and reincorporated.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over
Yelahanka as applied to claim 1 above, in view of
Vazhenin et al, US 20200379991 A1 hereinafter Vazhenin. As per,
Claim 15 Yelahanka teaches all the limitations in claim 1 above.
Yelahanka does not explicitly recite: “wherein different sets of aggregated metrics in the first and second pluralities of sets of aggregated metrics are stored in different time-series databases (TSDBs) according to their aggregation granularity” as claimed.
Vazhenin in analogous art of monitoring network elements teaches/suggests: “wherein different sets of aggregated metrics in the first and second pluralities of sets of aggregated metrics are stored in different time-series databases (TSDBs) according to their aggregation granularity”
(Vazhenin ¶ [0025] 2nd sentence: At a shard level, a TSDB can be implemented, which stores and reports system metrics gathered by the node-level monitoring agents.
Vazhenin ¶ [0026] Monitoring agents periodically send new data to TSDBs.
Vazhenin ¶ [0027] In some examples, a computing node that runs an active instance of a TSDB can become overwhelmed with metrics reports from monitoring agents where that TSDB instance serves all cluster computing nodes. To address this issue, the computing nodes of a cluster-based storage system can be divided into shards, where a TSDB can then monitor one shard rather than all computing nodes of the cluster-based storage system. To this end
Vazhenin ¶ [0048] 2nd-4th sentences: proposes During 1st iteration, the metrics reporting server determine that 2 TSDBs-TSDB 1 202 and TSDB 3 206-cover half of the time window, with a total value of two time units > the total value of TSDB 2 204, which is 1 time unit. TSDB 1 202 can be chosen during 1st iteration as it can half of the time window with a single time interval [t0+2, t0+4), while TSDB 3 206 requires 2 time intervals, [t0+1, t0+2), and [t0+4, t0+5). That is, TSDB 1 202 has one intersection with the time window, while TSDB 3 206 has 2 intersections with the time window. Similarly ¶¶ [0055] 2nd-3rd sentences, [0058], [0061]-[0067], [0071], [0074]. Also
Vazhenin ¶ [0106] 3rd sentence proposes: where 1st TSDB is queried for monitoring results for time [t0+2, t0+4), and 2nd TSSDB is queried for monitoring results for [t0+1, t0+2) and [t0+4, t0+5), then these results can be aggregated too produce monitoring results for time [t0+1,t0+5) )
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Yelahanka’s “method” to have included Vazhenin’s teachings in order to have provided a better solution to the problem or reduce consumption achievable in a more efficient approach of monitoring status of nodes of a storage system (Vazhenin ¶¶ [0022],[0031]-[0034] in view of MPEP 2143 C, D and/or G). The predictability of such modification would have been corroborated by the broad level of skills of one of ordinary skills in the art as articulated by Yelahanka ¶ [0034] in view of Vazhenin ¶ [0159], ¶ [0161].
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor of monitoring network elements. In such combination each element merely would have performed the same analytical and processing function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Yelahanka in view of Vazhenin, the to be combined elements would have fitted together like pieces of a puzzle in a logical, complementary, and technologically feasible manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
Following art is made of record and considered pertinent to Applicant’s disclosure:
- EP 3748562 A1 teaching Timeline visualization & investigation systems and methods for time lasting events
- Malboubi et al, Intelligent SDN based traffic (de) aggregation and measurement paradigm iSTAMP, InIEEE INFOCOM 2014-IEEE Conference on Computer Communications pp934-942, Apr 27 IEEE, 2014
- US 20180062943 A1 emphasis on Figs. 6-8, 11,12, 16,17 and associated text
- US 20220247643 A1 ¶ [0209] In several embodiments, method 2200 further and optionally can include an activity 2225 of aggregating data from customer profiles of customers using the SDN control service. Also see Fig. 17 noting considerations for seasonality
- US 20150019537 A1 ¶ [0040] In some embodiments, the report editor can enable a user to further filter the events using the selected fields. If, for example, an initial search query returns 100 events that correspond to log data generated by Server A, and a “time” field is one of the selected fields for the events, then, the interactive GUI can be used to specify additional filtering criteria for the time field, such as the time range of 9 am to 12 pm. If, for example, 10 of the 100 events have at time field with a value (e.g., a timestamp) corresponding to a time between 9 am and 12 pm, application of the additional filtering criteria may result in generating a report that includes the 10 events corresponding to 9 am to 12 pm (e.g., filtering out the 90 events that do not satisfy the additional filtering criteria) and/or includes aggregates or visualizations that are based on the 10 events.
- US 20170367081 A1 ¶ [0040] In one or more embodiments, the SDN controller 230 can collect usage information over time to develop an historic pattern of utilization of services and/or RNA resources. The SDN controller 230 can use historic utilization information to identify time periods (e.g., certain hours, days, weeks, months) when service utilization is significantly higher or lower. The SDN controller 230 can use the historical pattern information to predict future time periods of significantly higher or lower utilization. For example, the collected data may point to an inflection point, where each weekday at 7 am, the demand for voice service jumps by 10% but then drops back to a more typical level at around 10 am.
- US 20230008692 A1 reciting the following:
¶ [0133] 1st, 4th-5th sentences: … before scheduling the software update, pre-check of software validation may be performed….To validate the software, firstly, current running version of firmware on which the software is running is compared with previous validated firmware. If the result of comparison is positive, then a list of nodes that are identified as upgrade candidate is generated.
¶ [0100] Figs.11A-B illustrate use case of scheduling software upgrade, according to various embodiments of the disclosure.
¶ [0101] More particularly, Figs.11A-B represent traffic predicted of devices when the techniques of Figs.10A-B is applied on the campus data network of Fig.9A. Fig.11B illustrates a graph representing aggregated value of traffic at leaf 1 and leaf 2, using the methods of the disclosure. In an embodiment of the disclosure, the first threshold is considered as 1 GB and the second threshold is 20 GB.
¶ [0102] Referring to Fig.11A, time period where traffic for leaf 1 and leaf 2 is above 1 GB and below 20 GB is 2.00-2.30 AM and 3.30-4.00 AM, respectively. Similarly, referring to FIG. 11B, time period where traffic for spine 1 and spine 2 is above 1 GB and below 20 GB is 2.00-2.30 AM and 3.30-4.00 AM, respectively. Hence, based on traffic predicted in Figs.11A-B, the following can be concluded:

TABLE 4

Device
Predicted time window for software upgrade

Leaf1
02.00~2.30 AM

Leaf2
03.30~4.00 AM

Spine1
02.00~2.30 AM

Spine2
03.30~4.00 AM

¶ [0103] A network architecture implementing scheduling of software upgrade, in accordance with a third embodiment of the disclosure is the same as illustrated in FIG. 10B. It is possible that if no suitable time period for software upgrade can be found in accordance with techniques described in Figs.8,10A, and 10B, then the network operator may accept minimum rate of low priority traffic loss during software upgrade. In other words, let us assume that the predicted traffic at the at least one SDN controlled network device is above the first threshold in the time period. Thereafter, if the traffic at the at least one SDN controlled network device is low priority traffic, the software upgrade may be scheduled in the time period. In an embodiment of the disclosure, acceptance low priority traffic loss value may be given by network administrator.

- US 10536350 B2 teaching determining feature utilization in a software-defined network
- US 20170099211 A1 teaching Providing Elasticity in Transport Network Virtualisation
With emphasis on Figs.1,10 and associated text
- US 20090063251 A1 reciting at mid-¶ [0043] Variable time buckets may be selected to choose a planning horizon. Time buckets may be selected for various levels of time granularity, such as weekly and period buckets. The time buckets may be selected by a user, for example, using a graphical user interface.
- US 20230351214 A1 reciting at
¶ [0076] In a simplified manner, Fig. 4 shows at least a part of the historical temporal sensor data 201 divided into consecutive segments 211, ..., 222. The historical temporal sensor data 201 consists, e.g., of several temporal sensor data SD1, ..., SDn representing different parameters of the technical system. A segment type out of the segment types A, B, C, D is assigned to each of the segments 211,..., 222. For example, Segment type A is assigned to segment 211, segment type B is assigned to segment 212.
¶ [0081] Fig.5 shows another embodiment of historical temporal sensor data 202 comprising of temporal sensor data SD11, temporal sensor data SD12 until temporal sensor data SD1n. The historical temporal sensor data 202 are segmented and a segment type is assigned to each segment indicated by different shading. Selected subsequences 203 of the historical temporal sensor data 220 are output as training data. In this embodiment two reference patterns were determined a first one comprising the ordered sequence types (A, B) and a second one comprising ordered sequence types (A, C). Subsequence SS10 comprises two segments according to the reference pattern (A, B). An extended subsequence ESS10 comprises several consecutive segments showing the reference pattern (A, B). A mixed extended subsequence MESS10 is generated by concatenating an extended subsequence of reference pattern (A, B) with a subsequence of a reference pattern (A, C) and with another extended subsequence of reference pattern (A, B). The connecting parts of concatenated subsequences are re-sampled to smoothen the data distribution in this part of the subsequence.

- US 20170048126 A1 teaching debugging in a software-defined networking (sdn) system
¶ [0050] Fig. 3 illustrates temporal matching of statistics and messages in a graph according to one embodiment of the invention. The graph 300 has one x-axis and two y-axes. The x-axis is time, which may be an absolute time or a relative time starting from a reference point. The y-axis at the left is the packet counts, indicating the packet has been processed in a particular interval. One solid line is drawn for the network element 262 and the line illustrates the number of packets processed at the last flow table (e.g., the flow table 15) of the network element 262. A dotted line is also drawn, and it is for illustrating the number of packets processed at the first flow table (e.g., the flow table 0) of the network element 264. As the network element 262 are connected to the network element 264 as illustrated in FIG. 2, the packet processing at the last flow table at the former should be correlated to the first flow table of the latter. The closeness of the number of packets processed tracked by the two lines appears to validate the assumption.
¶ [0051] The y-axis at the right tracks the message types. While many types (and categories within the types) of messages may be plotted in the graph, flow modification messages, group modification messages, and port statistics reply messages are used to illustrate the matching process. Each message is plotted in the graph starting at a time as the timestamp of the message indicates. The length of the message in the graph may be predetermined by the operator of a SDN system, and the messages of the same type and category have the same time duration, while the messages of different types and categories may have different time duration. For example, a flow modification message may last a duration within 1˜10 seconds, a group modification message may last a duration within 1˜15 seconds, and a port statistics reply may last a duration within 1˜5 seconds. The duration for messages of each type and category may be adjusted based on the historical impact of a particular type and category at a given SDN system and a given network element. For example, when it is determined that the impact of port statistics reply message on a network element is brief because there are not many port statistics collected from the network element, the duration of the port statistics reply message may be shorten (e.g., from 5 seconds to 1 seconds). Different type of messages are plotted at different height in the graph. In this example, the port stats reply message occurred once during the time the graph is generated for and that is port stats reply 341; the group modification message also occurred once and that is group modification message 331; and the flow modification message occurred twice and they are flow modification messages 321 and 322.

- US 20170085446 A1 ¶ [0151] 2nd -6th sentences: Search screen 600 includes a search bar 602 that accepts user input in the form of a search string. It also includes a time range picker 612 that enables the user to specify a time range for the search. For “historical searches” the user can select a specific time range, or alternatively a relative time range, such as “today,” “yesterday” or “last week.” For “real-time searches,” the user can select the size of a preceding time window to search for real-time events. Search screen 600 also initially displays a “data summary” dialog as is illustrated in Fig. 6B that enables the user to select different sources for the event data, such as by selecting specific hosts and log files. Similarly, Figs. 33A-B, 35, 36, ¶ [0331], ¶ [0351]

Any inquiry concerning this communication or earlier communications from the examiner should be directed to OCTAVIAN ROTARU whose telephone number is [phone]. The examiner can normally be reached on 571.270.7950 from 9AM to 6PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICIA H MUNSON, can be reached at telephone number [phone]. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/OCTAVIAN ROTARU/
Primary Examiner, Art Unit 3624 A
January 20th, 2026

1 Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016);
2 Mayo, 566 U.S. at 79-80, 86-87, 101 USPQ2d at 1968-69, 1971

Prosecution Timeline

• Oct 10, 2023: Application Filed
• Jan 20, 2026: Non-Final Rejection — §101, §102, §103 (current)