DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is in response to the communication filed on 07/31/2024. Claims 1-20 are pending in this application.
Priority
This application was effectively filed on 07/31/2024. The assignee of record is Dell Products L.P. The listed inventor(s) is/are: Bhanjois et al.
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 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 1, 11 and 19 recite the limitation “a short duration” in line 5, line 7 and line 5 respectively. The limitation “a short duration” is a relative term which renders the claim indefinite. The limitation “a short duration” is not defined by the claims, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not reasonably apprised of the scope of the invention.
Claim 1 recites the limitation “the telemetry catalog” in line 11. There is insufficient antecedent basis for this limitation in the claim. For examination purpose, “the telemetry catalog” will read as “a telemetry catalog.”
Claims 5, 14 and 20 recite the limitation “on the order of hours or days.” The limitation “on the order of hours or days” does not provide a clear definition of the duration. This limitation renders the claim indefinite. The limitation “on the order of hours or days” may lead to hundreds or thousands of hours or days.
Claim 8 recites the limitation “the producer” in line 1. There is insufficient antecedent basis for this limitation in the claim. For examination purpose, “the producer” will read as “a producer.”
Claim 12 recites the limitation “the one or more consumers” in line 4. There is insufficient antecedent basis for this limitation in the claim. For examination purpose, “the one or more consumers” will read as “one or more consumers.”
Claims 13 and 20 recite the limitation “a Santorini network” in line 1 respectively. The limitation “a Santorini network” is a term which renders the claim indefinite. The limitation “a Santorini network” is not defined by the claims, the specification does not provide enough detail to notify one of ordinary skill in the art of the scope of such network. For examination purpose, “a Santorini network” will read as “a cluster network.”
Claim 18 recites the limitation “the telemetry handler the producer” in line 2. It is unclear to the examiner what is the relationship between “the telemetry handler” and “the producer.”
Claim 19 recites the limitation “in a datastore” in line 4. It is unclear to the examiner the limitation “in a datastore” is the same as the limitation “a datastore” recited in line 3.
Claim 20 recites the limitation “the one or more consumers” in line 7. There is insufficient antecedent basis for this limitation in the claim. For examination purpose, “the one or more consumers” will read as “one or more consumers.”
The dependent claims of the above rejected claims are rejected due to their dependencies.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 13 and 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 13 and 20 recite the limitation “a Santorini network” in line 1 respectively. A search does not find a prior art from on or before the filing of the instant application that provides enough details of “a Santorini network” to have it be known to one of ordinary skill in the art. For instance, this forum posting from November 27, 2024 says that it is not done yet, and speculates it will take 7-8 years to complete it (https://www.thelayoff.com/t/1vHUeAqy). For examination purpose, “a Santorini network” will read as “a cluster network.”
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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.
Claims 1-3, 7 and 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chayat et al. (US 20180288503 A1, published 10/04/2018; hereinafter Chayat), in view of Osiecki et al. (US 20170111242 A1, published 04/20/2017; hereinafter Osiecki).
For Claim 1, Chayat teaches a method of processing telemetry data in a cluster network having a plurality of nodes (Chayat, FIG. 1, FIG. 2; ¶ 0014 “… the example network 100 may represent a grouping of related or interconnected devices, such as a datacenter, a computing cluster, a Local Area Network (LAN), a Wide Area Network (WAN) …”; ¶ 0019 “… the system 200 may correspond generally to some or all of the telemetry logic 120 shown in FIG. 1 …”), comprising:
storing the telemetry data as generated by telemetry producers (Chayat exemplifies Network Devices 110 including telemetry logic in FIG. 1) in the network in a datastore (Chayat exemplifies Destination Node 160 in FIG. 1) as metric datasets … (Chayat, FIGS 1-3; ¶ 0017 “… the network device 110 may include telemetry logic 120 to generate telemetry data associated with the network device 110 … The telemetry logic 120 may generate a telemetry container including multiple types of telemetry data, and may send the telemetry container to a destination entity specified in a profile …”; ¶ 0030 “… the destination field 330 may specify a network address, a memory address, a register, a process identifier, an application, a Virtual Machine (VM), a Virtual Network Function (VNF), a destination device, a hardware component, and so forth …”); …;
registering the short-term metric (Chayat exemplifies telemetry profiles in FIG. 2 and FIG. 3) with … condition for triggering collection of the metric (Chayat teaches storing the telemetry profiles specifying the collection trigger conditions; FIGS 1-3; ¶ 0017 “… the telemetry logic 120 may use profiles specifying triggers, source registers, and destinations for telemetry data …”; ¶ 0019 “… the storage 205 may include a set of telemetry profiles 220 and a set of message profiles 230 …”; ¶ 0020 “… the telemetry registers 240 may be any memory locations to store multiple types of telemetry data associated with a source device (e.g., network device 110 or component 140 shown in FIG. 1) …”; ¶ 0027 “… The collection trigger field 310 may specify one or more conditions to trigger the collection of telemetry data …”);
initiating, upon detection of the condition, collection of the short-term metric (Chayat teaches performing monitoring when detecting satisfaction of the conditions; FIG. 2, FIG. 3; ¶ 0028 “… the virtualized telemetry controller 210 (shown in FIG. 2) may perform monitoring according to the collection trigger field 310 of each telemetry profile 300, and may detect satisfaction of the condition(s) specified in collection trigger field 310. For example, the virtualized telemetry controller 210 may determine that a time period specified in the collection trigger field 310 has expired. In another example, the virtualized telemetry controller 210 may determine that a command or exception specified in the collection trigger field 310 has occurred …”; also see steps 620, 640 corresponding to FIG. 6);
Chayat does not explicitly teach, but Osiecki teaches storing the telemetry data in a datastore having a defined schema (Osiecki teaches storing data models representing the metrics; FIG. 1; ¶ 0022 “… Further, a data store 149 is stored in a memory that is accessible to the server 103. Stored within the data store 149 are data models 151 that represent the metrics 109 …”; ¶ 0025 “… The aggregation application 126 processes the metrics 109 in the aggregation queue 143 and applies the results to the storage queue 146 to be stored in the data store 149 by the data store application 129 …”);
defining a short-term metric as a metric to be collected for a short duration (Osiecki teaches that collected metrics are associated with a time period; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0027 “… the metrics 109 associated with each respective consecutive time period 156 are represented by a data model 151 …”);
registering the short-term metric with a metric schema, defined duration (Osiecki teaches storing the data models in active metric list(s) and the data models associating with time periods; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0042 “… the applications executable on the server further include a metric directory application 163 that maintains one or more active metric lists 169 in a data store 166. The metric directory application 163 serves to maintain a list of active metrics 109 for which data models 151 may be retrieved. To this end, each time a data model 151 generated from one or more instances of a metric 109 is to be stored in the data store 149, a copy of the same is supplied to the metric directory application 163 … Each active metric list 169 may be stored in the form of a table, database, or other data structure …”), and …; …;
stopping collection of the metric at the end of the defined duration (Osiecki teaches a time period associating with the generated data model, therefore there is a point of time which ends calculating the collected metrics into the data model; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”); and
unregistering any short-term metric that is no longer needed or requires updating to clean up the telemetry catalog (Osiecki teaches the metric directory application removing the out of date metrics from the active metric list(s); FIG. 1, ¶ 0048 “… when the timestamp associated with a given metric 109 in an active metric list 169 indicates that the most recent data associated with a metric 109 has been stored in the data store 149 longer than the predefined storage time period mentioned above, the metric directory application 163 proceeds to remove such metric 109 from the active metric list 169 …”).
Osiecki and Chayat are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the generating data models from the collected metrics techniques of Osiecki with the system of Chayat to reduce the storage demand for the metrics data and facilitate metrics searching ability (Osiecki ¶ 0014).
For Claim 2, Chayat-Osiecki teaches the method of claim 1 further comprising mapping a function of the short-term metric to the condition (Chayat, FIG. 3; 0027 “… The collection trigger field 310 may specify one or more conditions to trigger the collection of telemetry data. For example, the collection trigger field 310 may specify a periodic timer, a control signal, an interrupt, a device status, a processing exception, a register flag, a system state, a trigger packet, and so forth …”).
For Claim 3, Chayat-Osiecki teaches the method of claim 1 wherein the telemetry data comprises data generated periodically by each producer upon operation in the cluster network, and consists of performance data, topology information, alerts, security states, and service features (Chayat, FIG. 1; ¶ 0014 “… the example network 100 may represent a grouping of related or interconnected devices, such as a datacenter, a computing cluster, a Local Area Network (LAN), a Wide Area Network (WAN) …”; ¶ 0017 “… the network device 110 may include telemetry logic 120 to generate telemetry data associated with the network device 110. Examples of such telemetry data may include link statistics, system statistics, access control list statistics, system status, temperature level, power consumption data, and so forth …”).
For Claim 7, Chayat-Osiecki teaches the method of claim 1 further comprising storing the short-term metric schema, duration, and condition in a telemetry catalog (Chayat teaches storing the telemetry profiles specifying the collection trigger conditions, Osiecki teaches storing the data models in active metric list(s) and the data models associating with time periods) accessible by a telemetry transmitter (Chayat exemplifies the telemetry logic in FIG. 1), and wherein the short-term metric is collected for transmission by the telemetry transmitter to one or more consumers of the telemetry data, the one or more consumers comprising at least one of: pod components of the nodes, storage users (Chayat teaches a memory address ¶ 0030), graphical user interfaces (GUI), and storage vendors (Chayat, FIGS 1-3; ¶ 0017 “… the network device 110 may include telemetry logic 120 to generate telemetry data associated with the network device 110 … The telemetry logic 120 may generate a telemetry container including multiple types of telemetry data, and may send the telemetry container to a destination entity specified in a profile …”; ¶ 0030 “… the destination field 330 may specify a network address, a memory address, a register, a process identifier, an application, a Virtual Machine (VM), a Virtual Network Function (VNF), a destination device, a hardware component, and so forth …”). See motivation to combine for claim 1.
For Claim 11, Chayat teaches a method of processing telemetry data in a cluster network having a plurality of telemetry producers (Chayat exemplifies Network Devices 110 including telemetry logic in FIG. 1) each periodically generating metric datasets (Chayat, FIG. 1, FIG. 2; ¶ 0014 “… the example network 100 may represent a grouping of related or interconnected devices, such as a datacenter, a computing cluster, a Local Area Network (LAN), a Wide Area Network (WAN) …”; ¶ 0019 “… the system 200 may correspond generally to some or all of the telemetry logic 120 shown in FIG. 1 …”), comprising: …; …;
defining a short-term metric as a metric (Chayat exemplifies telemetry profiles in FIG. 2 and FIG. 3) to be collected …, wherein the short-term metric comprises a metric collected upon occurrence of a condition (Chayat teaches the telemetry profiles specifying the collection trigger conditions; FIGS 1-3; ¶ 0017 “… the telemetry logic 120 may use profiles specifying triggers, source registers, and destinations for telemetry data …”; ¶ 0019 “… the storage 205 may include a set of telemetry profiles 220 and a set of message profiles 230 …”; ¶ 0027 “… The collection trigger field 310 may specify one or more conditions to trigger the collection of telemetry data …”); …;
storing the … condition for the short-term metric … (Chayat teaches storing the telemetry profiles specifying the collection trigger conditions; FIGS 1-3; ¶ 0017 “… the telemetry logic 120 may use profiles specifying triggers, source registers, and destinations for telemetry data …”; ¶ 0019 “… the storage 205 may include a set of telemetry profiles 220 and a set of message profiles 230 …”; ¶ 0020 “… the telemetry registers 240 may be any memory locations to store multiple types of telemetry data associated with a source device (e.g., network device 110 or component 140 shown in FIG. 1) …”; ¶ 0027 “… The collection trigger field 310 may specify one or more conditions to trigger the collection of telemetry data …”);
collecting, by the telemetry transmitter (Chayat exemplifies the telemetry logic in FIG. 1 and corresponding virtualized telemetry controller 210 in FIG. 2) …, the short-term metric dataset, upon detecting the occurrence of the condition (Chayat teaches performing monitoring when detecting satisfaction of the conditions; FIG. 2, FIG. 3; ¶ 0019 “… the system 200 may correspond generally to some or all of the telemetry logic 120 shown in FIG. 1 …”; ¶ 0028 “… the virtualized telemetry controller 210 (shown in FIG. 2) may perform monitoring according to the collection trigger field 310 of each telemetry profile 300, and may detect satisfaction of the condition(s) specified in collection trigger field 310. For example, the virtualized telemetry controller 210 may determine that a time period specified in the collection trigger field 310 has expired. In another example, the virtualized telemetry controller 210 may determine that a command or exception specified in the collection trigger field 310 has occurred …”; also see steps 620, 640 corresponding to FIG. 6).
Chayat does not explicitly teach, but Osiecki teaches first receiving schema definitions of metric datasets of the telemetry data produced by the telemetry producers; storing the schema definitions in a telemetry catalog accessed by a telemetry transmitter (Osiecki teaches storing the data models in active metric list(s); FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0042 “… the applications executable on the server further include a metric directory application 163 that maintains one or more active metric lists 169 in a data store 166. The metric directory application 163 serves to maintain a list of active metrics 109 for which data models 151 may be retrieved. To this end, each time a data model 151 generated from one or more instances of a metric 109 is to be stored in the data store 149, a copy of the same is supplied to the metric directory application 163 … Each active metric list 169 may be stored in the form of a table, database, or other data structure …”);
defining a short-term metric as a metric to be collected for a short duration, … (Osiecki teaches that collected metrics are associated with a time period; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0027 “… the metrics 109 associated with each respective consecutive time period 156 are represented by a data model 151 …”);
second receiving a schema definition for a short-term metric dataset produced by a producer; storing the schema definition, duration, and … for the short-term metric in the telemetry catalog (Osiecki teaches storing the data models in active metric list(s) and the data models associating with time periods; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0042 “… the applications executable on the server further include a metric directory application 163 that maintains one or more active metric lists 169 in a data store 166. The metric directory application 163 serves to maintain a list of active metrics 109 for which data models 151 may be retrieved. To this end, each time a data model 151 generated from one or more instances of a metric 109 is to be stored in the data store 149, a copy of the same is supplied to the metric directory application 163 … Each active metric list 169 may be stored in the form of a table, database, or other data structure …”); and
collecting, … and for the duration, the short-term metric (Osiecki, FIG. 1; 0025 “… The aggregation application 126 processes the metrics 109 in the aggregation queue 143 and applies the results to the storage queue 146 to be stored in the data store 149 by the data store application 129. According to various embodiments, the aggregation application 126 serves to aggregate multiple metrics 109 for respective time periods 156 …”).
Osiecki and Chayat are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the generating data models from the collected metrics techniques of Osiecki with the system of Chayat to reduce the storage demand for the metrics data and facilitate metrics searching ability (Osiecki ¶ 0014).
For Claim 12, Chayat-Osiecki teaches the method of claim 11 wherein the telemetry data comprises data generated periodically by each producer upon operation in the cluster network, and consists of performance data, topology information, alerts, security states, and service features (Chayat, FIG. 1; ¶ 0014 “… the example network 100 may represent a grouping of related or interconnected devices, such as a datacenter, a computing cluster, a Local Area Network (LAN), a Wide Area Network (WAN) …”; ¶ 0017 “… the network device 110 may include telemetry logic 120 to generate telemetry data associated with the network device 110. Examples of such telemetry data may include link statistics, system statistics, access control list statistics, system status, temperature level, power consumption data, and so forth …”), and further wherein the one or more consumers comprises at least one of: pod components of the nodes, storage users (Chayat teaches a memory address ¶ 0030), graphical user interfaces (GUI), and storage vendors (Chayat, FIGS 1-3; ¶ 0030 “… the destination field 330 may specify a network address, a memory address, a register, a process identifier, an application, a Virtual Machine (VM), a Virtual Network Function (VNF), a destination device, a hardware component, and so forth …”).
Claim Rejections - 35 USC § 103
Claims 4, is/are rejected under 35 U.S.C. 103 as being unpatentable over Chayat et al. (US 20180288503 A1, published 10/04/2018; hereinafter Chayat), in view of Osiecki et al. (US 20170111242 A1, published 04/20/2017; hereinafter Osiecki), and in further view of Bernat et al. (US 20210329354 A1, published 10/21/2021; hereinafter Bernat).
For Claim 4, Chayat-Osiecki teaches the method of claim 3 wherein the telemetry data comprises log data (Osiecki, FIG. 1; ¶ 0018 “… In addition, the data communication network 100 includes a monitored system 106 that generates logs and/or metrics 109 that may be transmitted to the servers 103 as a data stream …”), and … See motivation to combine for claim 1.
Chayat-Osiecki does not explicitly teach, but Bernat teaches the short-term metric comprises trace data of the cluster network (Bernat, ¶ 0002 “… An app mesh can use a control plane to manage telemetry collection. For example, there may be a need for log files from the application, as a simple example. Specific performance monitoring metrics, application metrics, and/or traces can be collected …”; ¶ 0076 “… FIG. 12 depicts an example system. For example, an orchestrator can provide application program interfaces (APIs) to one or more users to collect telemetry metrics and data to trace a flow of one or more services performed as part of a service mesh …”).
Bernat and Chayat-Osiecki are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry collection techniques of Bernat with the system of Chayat-Osiecki to facilitate a short duration of telemetry collection for distributed services (Bernat ¶ 0004).
Claim Rejections - 35 USC § 103
Claims 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chayat et al. (US 20180288503 A1, published 10/04/2018; hereinafter Chayat), in view of Osiecki et al. (US 20170111242 A1, published 04/20/2017; hereinafter Osiecki), in view of Bernat et al. (US 20210329354 A1, published 10/21/2021; hereinafter Bernat), and in further view of Tayeb et al. (US 20220417117 A1, published 12/29/2022; hereinafter Tayeb).
For Claim 5, Chayat-Osiecki-Bernat teaches the method of claim 4. Chayat-Osiecki-Bernat does not explicitly teach, but Tayeb teaches wherein the duration is on the order of hours or days (Tayeb, FIG. 3; ¶ 0039 “… the specific data collection attributes indicated by the configuration messages 311 can be analyzed. For example, if metric C1 includes processor utilization measurements, configuration message 311c indicates that metric C1 is collected at a sampling rate of 50 kilohertz (kHz) during a specified time period (e.g., a 24 hour period), and the manifest 211r specifies to collect metric C1 (processor utilization measurements) at a sampling rate of 25 kHz during a same or similar time period, then the requesting agent 210r may determine that sharing agent's 210c shared data/metrics C1 is suitable for the requesting agent's 210r telemetry system …”).
Tayeb and Chayat-Osiecki-Bernat are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry collection techniques of Tayeb with the system of Chayat-Osiecki-Bernat to improve system performance and/or reduce resource consumption (Tayeb ¶ 0002).
For Claim 6, Chayat-Osiecki-Bernat-Tayeb teaches the method of claim 5 wherein the producer comprises a security node (Tayeb teaches collecting telemetry data from computing devices such as firewall; FIG. 1; ¶ 0024 “… the controlled entity 160 is embodied as a computing device, the collector 110 includes one or more sensors in the computing device or otherwise accessible to computing device …”; ¶ 0175 “… The term ‘security appliance’, ‘firewall’, and the like at least in some examples refers to a computer appliance designed to protect computer networks from unwanted traffic and/or malicious attacks …”). See motivation to combine for claim 6.
Claim Rejections - 35 USC § 103
Claims 8-9 and 15-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chayat et al. (US 20180288503 A1, published 10/04/2018; hereinafter Chayat), in view of Osiecki et al. (US 20170111242 A1, published 04/20/2017; hereinafter Osiecki), and in further view of Lyer et al. (US 20220414026 A1, published 12/29/2022; hereinafter Lyer).
For Claim 8, Chayat-Osiecki teaches the method of claim 7. Chayat-Osiecki does not explicitly teach, but Lyer teaches wherein the producer is provided with a telemetry library (Lyer teaches a platform framework 200) for connection through an application programming interface (API) in the telemetry transmitter for registering the schema of the short-term metric (Lyer teaches a producer registering the platform framework via an API with its variables ; FIG. 2; ¶ 0056 “… platform framework 200 may be provided as a software library or an ‘.exe’ file …”; ¶ 0058 “… In operation, platform framework 200 enables the management and orchestration of its participants' communications. The term ‘participant,’ as used herein, refers to any entity (e.g., hardware device driver, software module, etc.) configured to register with platform framework 200 by issuing a registration command to management and oversight engine 202 via API 205 …”; ¶ 0060 “… Producers are entities (e.g., 207A-N) configured to advertise or publish the capabilities (e.g., variables, primitives, etc.) and statuses of associated hardware (e.g., 206A) or software components (e.g., 206N) to platform framework 200 via API 205, which can then be consumed and/or modified by other participants (e.g., 210A-N) …”).
Lyer and Chayat-Osiecki are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry producer registration techniques of Lyer with the system of Chayat-Osiecki to facilitate communicating and utilizing information or data (Lyer ¶ 0002).
For Claim 9, Chayat-Osiecki teaches the method of claim 7. Chayat-Osiecki does not explicitly teach, but Lyer teaches wherein the defining and registering steps are performed while the network is running and executing applications, in order to maintain up-to-date collection of short-term metrics generated by producers in the cluster network (Lyer teaches distributed platform framework so as to facilitate running various operations concurrently; FIG. 2; ¶ 0085 “… platform framework 200 may be extensible or distributed. For example, different instances or portions of platform framework 200 may be executed by different processing components (e.g., processor(s) 101 and EC 120) of IHS 100, or across different IHSs. Additionally, or alternatively, independent instances of platform framework 200 may be executed by different workspaces and in secure communications with each other, such that a participant, service, or runtime object's handle may identify the particular platform framework 200 that the participant or service is registered with …”). See motivation to combine for claim 8.
For Claim 15, Chayat-Osiecki teaches the method of claim 11. Chayat-Osiecki does not explicitly teach, but Lyer teaches wherein the metric datasets and short-term metric data are collected and registered by the telemetry transmitter while the network is running and executing applications, in order to maintain up-to-date collection of short-term metrics generated by producers in the cluster network (Lyer teaches distributed platform framework so as to facilitate running various operations concurrently; FIG. 2; ¶ 0085 “… platform framework 200 may be extensible or distributed. For example, different instances or portions of platform framework 200 may be executed by different processing components (e.g., processor(s) 101 and EC 120) of IHS 100, or across different IHSs. Additionally, or alternatively, independent instances of platform framework 200 may be executed by different workspaces and in secure communications with each other, such that a participant, service, or runtime object's handle may identify the particular platform framework 200 that the participant or service is registered with …”). See motivation to combine for claim 8.
For Claim 16, the claim is substantially similar to claim 8 and therefore is rejected for the same reasoning set forth above.
For Claim 17, Chayat-Osiecki-Lyer teaches the method of claim 16 wherein the telemetry transmitter (Chayat exemplifies Telemetry Logic 120 in FIG. 1 and corresponding Virtualized Telemetry Controller 210 in FIG. 2) interfaces with the producer through a telemetry handler (Chayat’s Telemetry Logic 120 in FIG. 1 and corresponding Virtualized Telemetry Controller 210 in FIG. 2 also teaches the functionality of the telemetry handler) to provide notification of the occurrence of the condition to trigger the producer to transmit the short-term metric dataset to a datastore (Chayat exemplifies a Destination Node in FIG. 1) for collection by the telemetry transmitter (Chayat, FIGS 1-3; ¶ 0019 “… the system 200 may correspond generally to some or all of the telemetry logic 120 shown in FIG. 1 …”; ¶ 0021 “… the virtualized telemetry controller 210 may utilize the telemetry profiles 220 to determine triggers, source registers, and destinations for telemetry data …”; ¶ 0027 “… The collection trigger field 310 may specify one or more conditions to trigger the collection of telemetry data. For example, the collection trigger field 310 may specify a periodic timer, a control signal, an interrupt, a device status, a processing exception, a register flag, a system state, a trigger packet, and so forth …”).
Claim Rejections - 35 USC § 103
Claims 10 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chayat et al. (US 20180288503 A1, published 10/04/2018; hereinafter Chayat), in view of Osiecki et al. (US 20170111242 A1, published 04/20/2017; hereinafter Osiecki), in view of Lyer et al. (US 20220414026 A1, published 12/29/2022; hereinafter Lyer), and in further view of Gupta et al. (US 20250219894 A1, filed 12/29/2023; hereinafter Gupta).
For Claim 10, Chayat-Osiecki-Lyer teaches the method of claim 9. Chayat-Osiecki-Lyer does not explicitly teach, but Gupta teaches wherein the cluster network includes a telemetry pipeline implementing an Open Telemetry (OTEL) protocol (Gupta teaches collecting logs using OTEL protocol; FIG. 4B; ¶ 0107 “… Log collector tools 444 may obtain and pre-process candidate logs from multiple layers of a network infrastructure …”; ¶ 0114 “… otel.library.name …: aos-otel-collector …”), and wherein the telemetry transmitter includes a collector receiving the telemetry data from producers through a remote procedure call (RPC) process (Gupta, FIG. 1; ¶ 0046 “… Services 122 may communicate with each other using calls, such as remote procedure calls (RPCs). Services 122 may communicate with each other along a chain of RPCs to provide the functionality of the network application …”; ¶ 0060 “… Log collector tools 144 may include software tools (e.g., FluentBit and FluentD) configured to collect, filter, format, and tag logs and metrics from multiple sources (e.g., an application layer, a compute layer, and a network layer) …”), and further wherein cluster network includes nodes each containing a plurality of pods performing network functions and generating the telemetry data for transmission to the consumers (Gupta, FIG. 1; ¶ 0035 “… Each of compute nodes 110 may host one or more workloads. The term ‘workload’ encompasses virtual machines, containers, Kubernetes Pods, and/or other virtualized computing resources that provide an at least partially independent execution environment for applications …”; ¶ 0077 “… Log collector tools 244 may include software tools for collecting telemetry data from various sources throughout computing infrastructure 100. Log collector tools 244 may collect telemetry data such as logs, traces, and performance metrics …”).
Gupta and Chayat-Osiecki-Lyer are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the collecting and analyzing network telemetry data techniques of Gupta with the system of Chayat-Osiecki-Lyer to facilitate efficient, thorough, and simplified troubleshooting of performance issues of network applications (Gupta ¶ 0010).
For Claim 18, Chayat-Osiecki-Lyer teaches the method of claim 17 further comprising: processing the short-term telemetry dataset in the telemetry handler the producer (Chayat, FIG. 2; 0021 “… the virtualized telemetry controller 210 may utilize the telemetry profiles 220 to determine triggers, source registers, and destinations for telemetry data. Further, in some embodiments, the virtualized telemetry controller 210 may utilize the message profiles 230 to determine how to package the telemetry data for transmission to the appropriate destination …”); and …
Chayat-Osiecki-Lyer does not explicitly teach, but Gupta teaches inputting the telemetry data to the datastore through a telemetry pipeline, wherein the telemetry pipeline implements an Open Telemetry (OTEL) protocol (Gupta teaches collecting logs using OTEL protocol; FIG. 4B; ¶ 0107 “… Log collector tools 444 may obtain and pre-process candidate logs from multiple layers of a network infrastructure …”; ¶ 0114 “… otel.library.name …: aos-otel-collector …”), and comprises a collector receiving the telemetry data through a remote procedure call (RPC) process (Gupta, FIG. 1; ¶ 0046 “… Services 122 may communicate with each other using calls, such as remote procedure calls (RPCs). Services 122 may communicate with each other along a chain of RPCs to provide the functionality of the network application …”; ¶ 0060 “… Log collector tools 144 may include software tools (e.g., FluentBit and FluentD) configured to collect, filter, format, and tag logs and metrics from multiple sources (e.g., an application layer, a compute layer, and a network layer) …”). See motivation to combine for claim 10.
Claim Rejections - 35 USC § 103
Claim 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chayat et al. (US 20180288503 A1, published 10/04/2018; hereinafter Chayat), in view of Osiecki et al. (US 20170111242 A1, published 04/20/2017; hereinafter Osiecki), in view of Rao et al. (US 20240403137 A1, filed 05/30/2024; hereinafter Rao), in view of and in further view of Bernat et al. (US 20210329354 A1, published 10/21/2021; hereinafter Bernat).
For Claim 13, Chayat-Osiecki teaches the method of claim 12 … further wherein the telemetry data comprises log data (Osiecki, FIG. 1; ¶ 0018 “… In addition, the data communication network 100 includes a monitored system 106 that generates logs and/or metrics 109 that may be transmitted to the servers 103 as a data stream …”), and … See motivation to combine for claim 11.
Chayat-Osiecki does not explicitly teach, but Rao teaches wherein the cluster network comprises a Santorini network processing containerized data utilizing a Kubernetes-based framework, and further wherein the plurality of nodes each contain a plurality of pods performing network functions and generating the telemetry data for transmission to the subscribing consumers (Rao teaches edge nodes, cloud nodes, cluster of devices, utilization of edge/MEC/Kubernetes on deployment, management of microservices process; FIGS 1-5; ¶ 0064 “… In block 424, the runtime component for App n can execute the application according to the provided specifications, collecting telemetry data and making dynamic adjustments as deemed necessary. The runtime system can continuously evaluate the collected telemetry data against the specified placement rules to determine if adjustments are needed …”; ¶ 0069 “… In block 442, the edge/MEC/Kubernetes can orchestrate the deployment and management of microservices across edge and cloud environments using containerization technologies. Kubernetes can provide the necessary tools for automating the deployment, scaling, and management of containerized applications, ensuring that microservices are deployed efficiently and can scale dynamically to handle varying workloads …”; ¶ 0074 “… In block 506, one or more devices (e.g., DataX cluster) can be utilized to represent the physical and virtual IoT devices and sensors that generate data for real-time analytics applications. These devices can include, for example, cameras, environmental sensors, other IoT endpoints that produce telemetry data, etc., and the DataX cluster can provide sufficient computational resources to process data locally, reducing latency and improving response times …”), and …
Rao and Chayat-Osiecki are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the containerized network architecture techniques of Rao with the system of Chayat-Osiecki to enhance performance, reduce latency, and provide optimal resource utilization for various computing systems and applications (Rao ¶ 0002).
Chayat-Osiecki-Rao does not explicitly teach, but Bernat teaches the short-term metric comprises trace data of the cluster network (Bernat, ¶ 0002 “… An app mesh can use a control plane to manage telemetry collection. For example, there may be a need for log files from the application, as a simple example. Specific performance monitoring metrics, application metrics, and/or traces can be collected …”; ¶ 0076 “… FIG. 12 depicts an example system. For example, an orchestrator can provide application program interfaces (APIs) to one or more users to collect telemetry metrics and data to trace a flow of one or more services performed as part of a service mesh …”).
Bernat and Chayat-Osiecki-Rao are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry collection techniques of Bernat with the system of Chayat-Osiecki-Rao to facilitate a short duration of telemetry collection for distributed services (Bernat ¶ 0004).
Claim Rejections - 35 USC § 103
Claim 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chayat et al. (US 20180288503 A1, published 10/04/2018; hereinafter Chayat), in view of Osiecki et al. (US 20170111242 A1, published 04/20/2017; hereinafter Osiecki), in view of Rao et al. (US 20240403137 A1, filed 05/30/2024; hereinafter Rao), in view of Bernat et al. (US 20210329354 A1, published 10/21/2021; hereinafter Bernat), and in further view of Tayeb et al. (US 20220417117 A1, published 12/29/2022; hereinafter Tayeb).
For Claim 14, Chayat-Osiecki-Rao-Bernat teaches the method of claim 13. Chayat-Osiecki-Rao-Bernat does not explicitly teach, but Tayeb teaches wherein the duration is on the order of hours or days (Tayeb, FIG. 3; ¶ 0039 “… the specific data collection attributes indicated by the configuration messages 311 can be analyzed. For example, if metric C1 includes processor utilization measurements, configuration message 311c indicates that metric C1 is collected at a sampling rate of 50 kilohertz (kHz) during a specified time period (e.g., a 24 hour period), and the manifest 211r specifies to collect metric C1 (processor utilization measurements) at a sampling rate of 25 kHz during a same or similar time period, then the requesting agent 210r may determine that sharing agent's 210c shared data/metrics C1 is suitable for the requesting agent's 210r telemetry system …”), and wherein the producer comprises a security pod (Tayeb teaches collecting telemetry data from computing devices such as firewall; FIG. 1; ¶ 0024 “… the controlled entity 160 is embodied as a computing device, the collector 110 includes one or more sensors in the computing device or otherwise accessible to computing device …”; ¶ 0175 “… The term ‘security appliance’, ‘firewall’, and the like at least in some examples refers to a computer appliance designed to protect computer networks from unwanted traffic and/or malicious attacks …”).
Tayeb and Chayat-Osiecki-Rao-Bernat are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry collection techniques of Tayeb with the system of Chayat-Osiecki-Rao-Bernat to improve system performance and/or reduce resource consumption (Tayeb ¶ 0002).
Claim Rejections - 35 USC § 103
Claim 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chayat et al. (US 20180288503 A1, published 10/04/2018; hereinafter Chayat), in view of Osiecki et al. (US 20170111242 A1, published 04/20/2017; hereinafter Osiecki), and in further view of Gupta et al. (US 20250219894 A1, filed 12/29/2023; hereinafter Gupta).
For Claim 19, Chayat teaches a system processing telemetry data in a cluster network having nodes … (Chayat, FIG. 1, FIG. 2; ¶ 0014 “… the example network 100 may represent a grouping of related or interconnected devices, such as a datacenter, a computing cluster, a Local Area Network (LAN), a Wide Area Network (WAN) …”; ¶ 0019 “… the system 200 may correspond generally to some or all of the telemetry logic 120 shown in FIG. 1 …”), the system comprising:
a datastore (Chayat exemplifies Destination Node 160 in FIG. 1) storing the telemetry data as generated by telemetry producers (Chayat exemplifies Network Devices 110 including telemetry logic in FIG. 1) in the network as metric datasets … (); …;
a telemetry transmitter (Chayat exemplifies Telemetry Logic 120 in FIG. 1) component registering the short-term metric with … condition for triggering collection of the metric (Chayat teaches storing the telemetry profiles specifying the collection trigger conditions; FIGS 1-3; ¶ 0017 “… the telemetry logic 120 may use profiles specifying triggers, source registers, and destinations for telemetry data …”; ¶ 0019 “… the storage 205 may include a set of telemetry profiles 220 and a set of message profiles 230 …”; ¶ 0020 “… the telemetry registers 240 may be any memory locations to store multiple types of telemetry data associated with a source device (e.g., network device 110 or component 140 shown in FIG. 1) …”; ¶ 0027 “… The collection trigger field 310 may specify one or more conditions to trigger the collection of telemetry data …”); and
a telemetry collector component (Chayat exemplifies Telemetry Logic 120 in FIG. 1 and corresponding Virtualized Telemetry Controller 210 in FIG. 2) initiating, upon detection of the condition, collection of the short-term metric (Chayat teaches performing monitoring when detecting satisfaction of the conditions; FIG. 2, FIG. 3; ¶ 0028 “… the virtualized telemetry controller 210 (shown in FIG. 2) may perform monitoring according to the collection trigger field 310 of each telemetry profile 300, and may detect satisfaction of the condition(s) specified in collection trigger field 310. For example, the virtualized telemetry controller 210 may determine that a time period specified in the collection trigger field 310 has expired. In another example, the virtualized telemetry controller 210 may determine that a command or exception specified in the collection trigger field 310 has occurred …”; also see steps 620, 640 corresponding to FIG. 6), and …
Chayat does not explicitly teach, but Osiecki teaches storing the telemetry data in a datastore having a defined schema (Osiecki teaches storing data models representing the metrics; FIG. 1; ¶ 0022 “… Further, a data store 149 is stored in a memory that is accessible to the server 103. Stored within the data store 149 are data models 151 that represent the metrics 109 …”; ¶ 0025 “… The aggregation application 126 processes the metrics 109 in the aggregation queue 143 and applies the results to the storage queue 146 to be stored in the data store 149 by the data store application 129 …”);
a producer … defining a short-term metric as a metric to be collected for a short duration (Osiecki teaches that collected metrics are associated with a time period; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0027 “… the metrics 109 associated with each respective consecutive time period 156 are represented by a data model 151 …”);
a telemetry transmitter component registering the short-term metric with a metric schema, defined duration, and … (Osiecki teaches storing the data models in active metric list(s) and the data models associating with time periods; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0042 “… the applications executable on the server further include a metric directory application 163 that maintains one or more active metric lists 169 in a data store 166. The metric directory application 163 serves to maintain a list of active metrics 109 for which data models 151 may be retrieved. To this end, each time a data model 151 generated from one or more instances of a metric 109 is to be stored in the data store 149, a copy of the same is supplied to the metric directory application 163 … Each active metric list 169 may be stored in the form of a table, database, or other data structure …”)
stopping collection of the metric at the end of the defined duration (Osiecki teaches a time period associating with the generated data model, therefore there is a point of time which ends calculating the collected metrics into the data model; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”).
Osiecki and Chayat are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the generating data models from the collected metrics techniques of Osiecki with the system of Chayat to reduce the storage demand for the metrics data and facilitate metrics searching ability (Osiecki ¶ 0014).
Chayat-Osiecki does not explicitly teach, but Gupta teaches a network having nodes each containing a plurality of pods and a producer pod (Gupta, FIG. 1; ¶ 0035 “… Each of compute nodes 110 may host one or more workloads. The term ‘workload’ encompasses virtual machines, containers, Kubernetes Pods, and/or other virtualized computing resources that provide an at least partially independent execution environment for applications …”; ¶ 0077 “… Log collector tools 244 may include software tools for collecting telemetry data from various sources throughout computing infrastructure 100. Log collector tools 244 may collect telemetry data such as logs, traces, and performance metrics …”);
Gupta and Chayat-Osiecki are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the collecting and analyzing network telemetry data techniques of Gupta with the system of Chayat-Osiecki to facilitate efficient, thorough, and simplified troubleshooting of performance issues of network applications (Gupta ¶ 0010).
Claim Rejections - 35 USC § 103
Claim 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chayat et al. (US 20180288503 A1, published 10/04/2018; hereinafter Chayat), in view of Osiecki et al. (US 20170111242 A1, published 04/20/2017; hereinafter Osiecki), in view of Gupta et al. (US 20250219894 A1, filed 12/29/2023; hereinafter Gupta), in view of Rao et al. (US 20240403137 A1, filed 05/30/2024; hereinafter Rao), in view of Bernat et al. (US 20210329354 A1, published 10/21/2021; hereinafter Bernat), and in further view of Tayeb et al. (US 20220417117 A1, published 12/29/2022; hereinafter Tayeb).
For Claim 20, Chayat-Osiecki-Gupta teaches the system of claim 19 …
yet further wherein the telemetry data comprises data generated periodically by each producer upon operation in the cluster network, and consists of performance data, topology information, alerts, security states, and service features (Chayat, FIG. 1; ¶ 0014 “… the example network 100 may represent a grouping of related or interconnected devices, such as a datacenter, a computing cluster, a Local Area Network (LAN), a Wide Area Network (WAN) …”; ¶ 0017 “… the network device 110 may include telemetry logic 120 to generate telemetry data associated with the network device 110. Examples of such telemetry data may include link statistics, system statistics, access control list statistics, system status, temperature level, power consumption data, and so forth …”), and
the one or more consumers comprises at least one of: pod components of the nodes, storage users (Chayat teaches a memory address ¶ 0030), graphical user interfaces (GUI), and storage vendors (Chayat, FIGS 1-3; ¶ 0017 “… the network device 110 may include telemetry logic 120 to generate telemetry data associated with the network device 110 … The telemetry logic 120 may generate a telemetry container including multiple types of telemetry data, and may send the telemetry container to a destination entity specified in a profile …”; ¶ 0030 “… the destination field 330 may specify a network address, a memory address, a register, a process identifier, an application, a Virtual Machine (VM), a Virtual Network Function (VNF), a destination device, a hardware component, and so forth …”), and
yet further the telemetry data comprises log data (Osiecki, FIG. 1; ¶ 0018 “… In addition, the data communication network 100 includes a monitored system 106 that generates logs and/or metrics 109 that may be transmitted to the servers 103 as a data stream …”), and … See motivation to combine for claim 19.
Chayat-Osiecki-Gupta does not explicitly teach, but Rao teaches wherein the cluster network comprises a Santorini network processing containerized data utilizing a Kubernetes-based framework, and further wherein the plurality of nodes each contain a plurality of pods performing network functions and generating the telemetry data for transmission to the subscribing consumers (Rao teaches edge nodes, cloud nodes, cluster of devices, utilization of edge/MEC/Kubernetes on deployment, management of microservices process; FIGS 1-5; ¶ 0064 “… In block 424, the runtime component for App n can execute the application according to the provided specifications, collecting telemetry data and making dynamic adjustments as deemed necessary. The runtime system can continuously evaluate the collected telemetry data against the specified placement rules to determine if adjustments are needed …”; ¶ 0069 “… In block 442, the edge/MEC/Kubernetes can orchestrate the deployment and management of microservices across edge and cloud environments using containerization technologies. Kubernetes can provide the necessary tools for automating the deployment, scaling, and management of containerized applications, ensuring that microservices are deployed efficiently and can scale dynamically to handle varying workloads …”; ¶ 0074 “… In block 506, one or more devices (e.g., DataX cluster) can be utilized to represent the physical and virtual IoT devices and sensors that generate data for real-time analytics applications. These devices can include, for example, cameras, environmental sensors, other IoT endpoints that produce telemetry data, etc., and the DataX cluster can provide sufficient computational resources to process data locally, reducing latency and improving response times …”),
Rao and Chayat-Osiecki-Gupta are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the containerized network architecture techniques of Rao with the system of Chayat-Osiecki-Gupta to enhance performance, reduce latency, and provide optimal resource utilization for various computing systems and applications (Rao ¶ 0002).
Chayat-Osiecki-Gupta-Rao does not explicitly teach, but Bernat teaches the short-term metric comprises trace data of the cluster network (Bernat, ¶ 0002 “… An app mesh can use a control plane to manage telemetry collection. For example, there may be a need for log files from the application, as a simple example. Specific performance monitoring metrics, application metrics, and/or traces can be collected …”; ¶ 0076 “… FIG. 12 depicts an example system. For example, an orchestrator can provide application program interfaces (APIs) to one or more users to collect telemetry metrics and data to trace a flow of one or more services performed as part of a service mesh …”),
Bernat and Chayat-Gupta-Osiecki-Rao are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry collection techniques of Bernat with the system of Chayat-Osiecki-Gupta-Rao to facilitate a short duration of telemetry collection for distributed services (Bernat ¶ 0004).
Chayat-Gupta-Osiecki-Rao-Bernat does not explicitly teach, but Tayeb teaches the duration is on the order of hours or days (Tayeb, FIG. 3; ¶ 0039 “… the specific data collection attributes indicated by the configuration messages 311 can be analyzed. For example, if metric C1 includes processor utilization measurements, configuration message 311c indicates that metric C1 is collected at a sampling rate of 50 kilohertz (kHz) during a specified time period (e.g., a 24 hour period), and the manifest 211r specifies to collect metric C1 (processor utilization measurements) at a sampling rate of 25 kHz during a same or similar time period, then the requesting agent 210r may determine that sharing agent's 210c shared data/metrics C1 is suitable for the requesting agent's 210r telemetry system …”).
Tayeb and Chayat-Gupta-Osiecki-Rao-Bernat are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry collection techniques of Tayeb with the system of Chayat-Gupta-Osiecki-Rao-Bernat to improve system performance and/or reduce resource consumption (Tayeb ¶ 0002).
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed below, thank you:
i. Karthikeyan (US 20230300218 A1) teaches that a telemetry producer sends a hello message to a telemetry registration interface. The interface returns a hello message. The producer sends a producer protocol suite to the interface. An acceptance of the protocol suite and an indication that the protocol suite has been forwarded to a telemetry registration controller is returned. The producer sends a hello message to the controller. The controller returns an acknowledgement and a producer identifier (ID). A second hello message and the producer ID is sent from the producer to the controller. The controller returns a second acknowledgement and the producer ID, indicating the producer registration. A telemetry consumer sends the controller a hello message. An acknowledgement with a consumer identifier (ID), is returned to the consumer. The consumer sends a consumer request packet to the controller. The controller sends the producer ID, and an indication of consumer registration to the consumer (Karthikeyan, Abstract).
ii. Kommula et al. (US 20230336447 A1) teaches a performance monitoring system includes a metric collector configured to receive, via metric exporters, telemetry data comprising metrics related to a network of computing devices. A metric time series database stores related metrics. An alert rule evaluator service is configured to evaluate rules using stored metrics. The performance monitoring system may include a machine learning module and is configured to determine optimized metric collection sampling intervals and rule evaluation intervals, and to automatically determine recommended alert rules (Kommula, Abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZONGHUA DU whose telephone number is (408)918-7596. The examiner can normally be reached Monday - Friday 8 AM - 5 PM PST.
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, John Follansbee can be reached on (571) 272-3964. 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.
/Z.D./Examiner, Art Unit 2444
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444