DETAILED 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 .
This action is responsive to the Applicant’s amendments filed on 11/5/2025. Claims 1-5 and 7-20 remain pending in the application. Claims 1, 17, and 19 have been amended. Claim 6 has been canceled. Any examiner’s note, objection, and rejection not repeated is withdrawn due to Applicant’s amendment.
Examiner’s Note
The Examiner cites particular columns, paragraphs, figures, and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may also apply. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in its entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Claim Objections
Claim 4 is objected to because of the following informalities: With regard to SuperGuide Corp. v. DirecTV Enters., Inc., 358 F.3d 870 (Fed. Cir. 2004), the courts have held that the plain meaning of “at least one of A, B, and C” means “at least one A, and at least one B, and at least one C”, and that if the applicant intended “at least one of A, B, and C” to mean “A, or B, or C”, they should have used “or”. In the case of claim 4, “at least one of” with “and” using its plain meaning, joins the items in the series, meaning all of the individual elements used together must be found. There is no explicit disclosure or example of all of the limitations of claim 4 being simultaneously included. For example, obtaining the value of a port from (1) a configuration file, and (2) a second configuration file, and (3) source code associated with the microservice, simultaneously is both redundant and not disclosed in the instant specification.
For purposes of examination, the Examiner assumes “or” is intended.
Appropriate correction is required.
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 8-14 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 8 and 14, both claims depend from claim 6 which has been canceled. Accordingly, both claims lack a proper antecedent basis and their scope is unclear. For the purposes of examination, the Examiner assumes dependency from claim 1 is intended.
Any claim not explicitly mentioned is rejected due to dependency on a rejected claim.
Claim Rejections - 35 USC § 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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5, 7, and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Liu et al. (US 20230409369 A1) hereafter Liu in view of Deshmukh et al. (US 20210203542 A1) hereafter Deshmukh, further in view of Phanishayee et al. (US 20240160471 A1) hereafter Phanishayee.
Regarding claim 1, Liu teaches:
A method comprising:
reading, by an exporter creation system executing on at least one processing device (Paragraph 155; “Computing device 500 of FIG. 4 may represent a real or virtual server and may represent an example instance of any of servers 12 and may be referred to as a compute node”, where compute nodes are where the system executes and corresponds to the applicant’s processing device), a configuration file associated with a microservice (Paragraph 104; “TE 61 may receive TECD 61 and collect, based on TECD 63, MD 64 corresponding to only the subset of the one or more metrics”, where receiving configuration data and performing collection based on that data requires the telemetry exporter to read and apply configuration contents. TECD is generated for a specific telemetry exporter, provided to the telemetry exporter, and is received and used by the telemetry exporter to control behavior. Because the TECD is config data that persists long enough to be received, interpreted, and acted upon by the TE, this satisfies the claimed configuration file because the claim does not require a specific file format, only configuration data that is read and used from a source. Paragraph 114 confirms association with a microservice, “The SDN architecture component microservices of configuration nodes 230, control nodes 232, compute nodes, user interface 244, and analytics nodes (not shown) may produce telemetry data.”), wherein the configuration file specifies event monitoring system specifications (Paragraph 103; “telemetry node 60 may transform... metrics into telemetry exporter configuration data (TECD) 63 that configures a telemetry exporter”, where configurating which metrics are collected thereby defines the specifications of the event monitoring system.) and comprises a metrics array with metric elements (Paragraph 101; “Telemetry node 60 may define MGs 62 as custom resources within a container orchestration platform, transforming each of MGs 62 into a configuration map that defines (e.g., as an array) the enabled metrics”.);
automatically generating (Paragraph 214; “A Telemetry Operator... implements the reconciler for the Metric Group Custom Resource and builds a Configuration Map from one or more MetricGroups”, where the telemetry operator builds the configuration automatically in response to Metric Group definitions. No user-driven instantiation is described, indicating automatic generation in response to Metric Group generation.), by the exporter creation system (Paragraph 214; telemetry operator acts as the exporter creation system that governs the metric exporting behavior) during runtime initialization of the microservice (Paragraph 214; “metric groups... provide the user with runtime flexibility to define collections of telemetric metrics and to selectively enable/disable the export of such collections”, where runtime flexibility indicates that metric exporting functionality is generated or configured during runtime initialization), a metric exporter for metrics associated with the microservice (Paragraph 214; “Metric Agents... monitor ConfigMap changes” and “define collections of telemetric metrics and... selectively enable/disable the export of such collections”, where metric agents monitor configuration changes and act on those changes to decide which metrics are to be output correspond to metric exporters as they implement the exporting of metrics according to config data. Paragraph 114 confirms association with a microservice, “The SDN architecture component microservices of configuration nodes 230, control nodes 232, compute nodes, user interface 244, and analytics nodes (not shown) may produce telemetry data.”);
by identifying the metrics array in the configuration file (Paragraph 101; “transforming each of MGs 62 into a configuration map that defines (e.g., as an array) the enabled metrics”, where the enabled metrics are explicitly defined as an array. Further, Paragraph 103 discloses the use of a telemetry exporter configuration data. The configuration map and TECD constitute a form of configuration file that is utilized to configure metrics exporters. The metrics array is contained within this configuration structure. The definition of the enabled metrics in the array requires that the metrics of the configuration structure be identified.);
parsing each metric element in the metrics array to extract event monitoring system constructs including name, description, and type parameters (Paragraph 101; “Telemetry node may define MGs 62 as custom resources... transforming each of MGs 62 into a configuration map that defines (e.g., as an array) the enabled metrics”, where the transformation of metric groups into a config map that defines enabled metrics requires parsing the individual metric definitions. Paragraph 101 further describes “limit[ing] export function 780 to only export enabled metrics specified by the configuration mapping”. Limiting export functionality based on enabled metrics requires extracting monitoring-related constructs from each metric element such that the telemetry system can perform event monitoring and export accordingly.);
creating a collector object according to the event monitoring system specifications for each metric element using the extracted constructs (Paragraphs 101-104; “Telemetry node 60 may transform... the subset of the one or more metrics into telemetry exporter configuration data (TECD) 63 that configures a telemetry exporter deployed at the one or more logically-related elements” which “represent configuration data specific for TE”. Paragraph 101 further discloses that it “defines (e.g., as an array) the enabled metrics. Transformation of metric definitions into configuration data that configures a telemetry exporter corresponds to creation of a collector object responsible for collecting metrics. Metric groups and the resulting TECD define the specifications governing metric collection and export, corresponding to event monitoring system specifications. The transformation of metric definitions into TECD corresponds to extraction of metric-related constructs which are used to configure the collector.);
registering, by the exporter creation system, each collector object associated with an event monitoring system to enable metric collection (Paragraphs 101-104; “Telemetry node 60 may transform... the subset of the one or more metrics into telemetry exporter configuration data (TECD) 63 that configures a telemetry exporter deployed at the one or more logically related elements... to export the subset of the one or more metrics”, where the transformation of metric definitions into config data and pushing TECD to telemetry exporters corresponds to registering each collector object to enable metric collection. TE 61 is associated with the event monitoring system and configured to collect metrics, corresponding to the claimed registration functionality.);
providing, by the metric exporter through the server process, the metrics to the event monitoring system (Paragraphs 103-104; “Telemetry node 60 may transform, based on the request to enable the metric group, the subset of the one or more metrics into telemetry exporter configuration data (TECD) 63 that configures a telemetry exporter deployed at the one or more logically related elements... to export the subset of the one or more metrics”. The telemetry exporter functions as the metric exporter and provides collected metrics through a deployed server process to the telemetry node, corresponding to the event monitoring system) upon receiving a request from the event monitoring system (Paragraph 103; “based on the request to enable the metric group... allowing telemetry node 60 to identify the type of TE 61 and generate customized TECD 63 for that particular type of 61”, where TE 61 collects and exports metrics in response to a request from a telemetry node.), wherein the metrics are generated by executing metric generating logic referenced in the configuration file (Paragraphs 101-102; “Telemetry node 60 may define MGs 62 as custom resources within a container orchestration platform, transforming each of MGs 61 into a configuration map that defines (e.g., as an array) the enabled metrics... Telemetry node 60 may then interface with the identified telemetry exporter... to configure, based on telemetry exporter configuration data, TE 61 to collect and export only the metrics that were enabled for collection”, where the config map directs TE 61 how to generate metrics for the requested subset, corresponding to the metrics generating logic referenced in the configuration file.);
wherein the method is implemented by at least one processing device comprising a processor coupled to a memory (Paragraph 155; “bus 542 may couple memory device 524, microprocessor 510, and NIC 530. Bus 542 may represent a Peripheral Component Interface (PCI) express (PCIe) bus”).
Liu does not teach that the collector object is dynamically created; a client library, or initiating, by the exporter creation system, a server process in the microservice with a configured port value.
However, Deshmukh teaches:
dynamic collector creation (Paragraph 22; “each of managed element 14 may initiate a management session 15 by... outputting a SSH session request to NMS 10” where “NMS microservices 22 listen for SSH session requests... and process each SSH”. The establishing of new management sessions constitute creation of new collectors. The management session is not pre-established but is initiated upon receipt of a SSH request from a managed element, establishing that the creation occurs dynamically.);
initiating, by the exporter creation system, a server process in the microservice with a configured port value (Paragraph 22; “each of managed element 14 may initiate a management session 15 by, in one example, outputting a SSH session request to NMS 10. NMS microservices 22 listen for SSH session requests on respective ports advertised to managed network 4 by NMS 10 and process each SSH session request to establish a new one of management sessions 15”. NMS microservices operate as endpoints for management sessions and begin execution to handle session requests, corresponds to initiating a server process within each microservice. The microservices listen on respective ports, corresponds to using a configured port value, the respective port, to establish the server process in the microservice.).
Liu and Deshmukh are considered to be analogous to the claimed invention because they are in the same field of event management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Deshmukh and have implemented collector object creation dynamically. A person of ordinary skill in the art would have recognized that dynamic object creation is a known method in the art and implementation would have yielded the predictable result of optimal object creation for varying groups metrics to be analyzed. A person of ordinary skill in the art would have further recognized that configuring a server process in a microservice to listen on particular ports is a known method in the art would the implementation would have yielded the predictable outcome of allowing a microservice to properly receive and process requests without port conflicts.
Liu in view of Deshmukh does not teach a client library.
However, Phanishayee teaches:
a client library (Paragraph 48; “DLCSMT client library 406 provides a client library that applications can use to collect application related metrics that are used by DL schedulers”.).
Liu, Deshmukh, and Phanishayee are considered to be analogous to the claimed invention because they are in the same field of event management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu in view of Deshmukh to incorporate the teachings of Phanishayee and have registered the collector objects with a client library. A person of ordinary skill in the art would have recognized that collectors require registration with a client-side library to properly receive metric data. Known methods for configuring and registering collectors with client libraries would have yielded the predictable result of enabling metric collection in accordance with monitoring system specifications, ensuring each collector object is tracked, configured, and invoked.
Claim 17 contains similar limitations as those of claim 1, additionally reciting a memory and processing device. Liu teaches:
A memory; and processing device coupled to the memory (Paragraph 155; “FIG. 4 is a block diagram of an example computing device”, computing device corresponds to the processing device. Further, “bus 542 may couple memory device 524, microprocessor 510, and NIC 530”).
Claim 17 is rejected for similar reasons as those of claim 1.
Claim 19 contains similar limitations as those of claim 1, additionally reciting a non-transitory computer-readable storage medium. Liu teaches:
A non-transitory computer-readable storage medium (Paragraph 273; “the computer-readable storage media may comprise non-transitory media”).
Claim 19 is rejected for similar reasons as those of claim 1.
Regarding claim 2, Liu in view of Deshmukh, further in view of Phanishayee teaches the method of claim 1. Liu teaches:
initiating a process, by the exporter creation system in the microservice, wherein the process receives the request from the event monitoring system to provide the metrics to the event monitoring system (Paragraph 103-104; “Telemetry node 60 may transform... the subset of the one or more metrics into telemetry exporter configuration data (TECD) 62 that configures a telemetry exporter deployed at the one or more logically-related elements... to export the subset of the one or more metrics”, where TECD 63 configures the telemetry exporter to operate on the microservice, effectively initiating a process to handle metric exporting. TE 61 receives config data and requests from the telemetry node, corresponding to the event monitoring system. Further, TE 61 sends the collected data back to telemetry node 60, which corresponds to providing metrics back to the event monitoring system.).
Deshmukh teaches:
a server (Paragraph 22; “NMS microservices 22 listen for SSH session requests on respective ports advertised to managed network 4 by NMS 10 and process each SSH session request to establish a new one of management sessions 15.” Further, Paragraph 17 lists the elements of communication links to include servers. Therefore, a person of ordinary skill in the art would have at least been motivated to have utilized a server for managing each microservice.).
Claim 18 recites similar limitations as those of claim 2. Claim 18 is rejected for similar reasons as those of claim 2.
Claim 20 recites similar limitations as those of claim 2. Claim 20 is rejected for similar reasons as those of claim 2.
Regarding claim 5, Liu in view of Deshmukh, further in view of Phanishayee teach the method of claim 1. Liu teaches:
wherein generating, by the exporter creation system, the metric exporter comprises:
generating the metric exporter during a runtime initialization of the microservice (Paragraph 214; “metric groups... provide the user with runtime flexibility to define collections of telemetric metrics and to selectively enable/disable the export of such collections”, where runtime flexibility indicates that metric exporting functionality is generated during runtime initialization).
Regarding claim 7, Liu in view of Deshmukh, further in view of Phanishayee teach the method of claim 1. Liu teaches:
wherein the at least one metric element comprises at least one event monitoring system construct used by the event monitoring system (Paragraph 214; “Custom Resource that provide the user with runtime flexibility to define collections of telemetric metrics and to selectively enable/disable the export of such collections, Changes to a Metric Group are pushed to each cluster that has been selected for the Metric Group (by default, a Metric Group may apply to all clusters)”, where the metric groups and their configuration maps define the set of telemetry metrics and related constructs utilized by the telemetry system. Each metric element in the metric group includes these constructs which are used by the telemetry operator and agents to configure collection and export of metrics; thus the metric elements comprise event monitoring system constructs.).
Regarding claim 14, Liu in view of Deshmukh, further in view of Phanishayee teach the method of claim 1. Liu teaches:
wherein the collector object has a reference to at least one event monitoring system construct used by the event monitoring system (Paragraph 214; “Custom Resource that provide the user with runtime flexibility to define collections of telemetric metrics and to selectively enable/disable the export of such collections, Changes to a Metric Group are pushed to each cluster that has been selected for the Metric Group (by default, a Metric Group may apply to all clusters)”, where the metric groups and their configuration maps define the set of telemetry metrics and related constructs utilized by the telemetry system. Each metric element in the metric group includes these constructs which are referenced by the telemetry operator and agents to configure collection and export of metrics; thus the metric elements correspond to the collector objects and comprise event monitoring system constructs utilized by the event monitoring system for metric gathering and output.).
Regarding claim 15, Liu in view of Deshmukh, further in view of Phanishayee teach the method of claim 1. Deshmukh teaches:
wherein the configuration file is written in a data serialization language (Paragraph 20; “In general, NETCONF provides mechanisms for configuring network devices and uses an Extensible Markup Language (XML)-based data encoding for configuration data”, where XML is a data serialization language.).
It would have been obvious to a person of ordinary skill in the art to have utilized XML as the configuration file. A person of ordinary skill in the art would have recognized that data serialization languages are known in the art and its implementation would yield the predictable result of interoperability and storage efficiency.
Regarding claim 16, Liu in view of Deshmukh, further in view of Phanishayee teach the method of claim 1. Liu teaches:
wherein registering, by the exporter creation system, the metric exporter with a library associated with an event monitoring system comprises:
registering a collector object associated with the configuration file with the event monitoring system (Paragraphs 101-104; “Telemetry node 60 may transform... the subset of the one or more metrics into telemetry exporter configuration data (TECD) 63 that configures a telemetry exporter deployed at the one or more logically related elements... to export the subset of the one or more metrics”, where the transformation of metric definitions into config data and pushing TECD to telemetry exporters corresponds to registering each collector object to enable metric collection. TE 61 is associated with the event monitoring system and configured to collect metrics, corresponding to the claimed registration functionality.).
Phanishayee teaches:
a client library (Paragraph 48; “DLCSMT client library 406 provides a client library that applications can use to collect application related metrics that are used by DL schedulers.”).
A person of ordinary skill in the art would have recognized that collectors require registration with a client-side library to properly receive metric data. Known methods for configuring and registering collectors with client libraries would have yielded the predictable result of enabling metric collection in accordance with monitoring system specifications, ensuring each collector object is tracked, configured, and invoked.
Claims 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Deshmukh, further in view of Phanishayee, further in view of Chakravarty et al. (US 20080114873 A1) hereafter Chakravarty.
Regarding claim 3, Liu in view of Deshmukh, further in view of Phanishayee teach the method of claim 2. Liu teaches:
the exporter creation system (Paragraphs 101-104; “Telemetry node 60 may transform... the subset of the one or more metrics into telemetry exporter configuration data (TECD) 63 that configures a telemetry exporter deployed at the one or more logically related elements... to export the subset of the one or more metrics”, where the telemetry node configures the telemetry exporter, thereby acting as the exporter creation system.).
Deshmukh teaches:
a server (Paragraph 22; “each of managed element 14 may initiate a management session 15 by, in one example, outputting a SSH session request to NMS 10. NMS microservices 22 listen for SSH session requests on respective ports advertised to managed network 4 by NMS 10 and process each SSH session request to establish a new one of management sessions 15”. NMS microservices operate as endpoints for management sessions and begin execution to handle session requests, corresponding to initiation of a server by definition as it functions as processing requests from clients, operating as a central hub that serves multiple clients, and acts as a specialized service provider that enables resource sharing across the system.).
Liu in view of Deshmukh, further in view of Phanishayee does not teach obtaining a value of a port.
However, Chakravarty teaches:
obtaining a value of a port (Paragraph 47; “pointing the agent engine process to read the port configuration which points to the location of the collector script in the directory”).
Liu, Deshmukh, Phanishayee, and Chakravarty are considered to be analogous to the claimed invention because they are in the same field of event management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu in view of Deshmukh, further in view of Phanishayee to incorporate the teachings of Chakravarty and obtain the value of a port. A person of ordinary skill in the art would have recognized obtaining the value of a port to be a known method in the art that would have yielded the predictable result of avoiding port conflicts and ensuring stable communication protocols.
Regarding claim 4, Liu in view of Deshmukh, further in view of Phanishayee, further in view of Chakravarty teaches the method of claim 3. Chakravarty teaches:
wherein obtaining by the exporter creation system the value of the port comprises:
obtaining the value of the port from at least one of the configuration file, a second configuration file or source code associated with the microservice (Paragraph 47; “The collector manager process may write the collector script(s) to a collector directory 16, write the port configuration to a file” and “point[s] the agent engine process to read the port configuration which points to the location of the collector script in the directory (operation 306)” where the file corresponds to the configuration file as it contains the port configuration.).
Claims 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee et al. (US 20210028985 A1) hereafter Banerjee.
Regarding claim 8, Liu in view of Deshmukh, further in view of Phanishayee teach the method of claim 1. Liu teaches:
wherein the at least one metric element comprises a collector section wherein the metric generating logic generates a portion of the metrics (Paragraph 214; “Custom Resource that provide the user with runtime flexibility to define collections of telemetric metrics and to selectively enable/disable the export of such collections, Changes to a Metric Group are pushed to each cluster that has been selected for the Metric Group (by default, a Metric Group may apply to all clusters)”, where each metric group includes config details defining which metrics are to be collected. Telemetry agents read the config map and execute the corresponding metric generation logic to produce metrics, thereby corresponding to the claimed collector section within each metric element, where the metric generating logic generates a portion of the metrics.) associated with the microservice (Paragraph 88; “Each of configuration nodes 30 may itself be implemented using one or more cloud native, component microservices. Each of control nodes 32 may itself be implemented using one or more cloud native, component microservices. Each of telemetry nodes 60 may also itself be implemented using one or more cloud native, component microservices.”, where metric gathering on nodes may be microservice nodes, corresponding to association with a microservice.).
Liu in view of Deshmukh, further in view of Phanishayee does not teach identifying a location of metric generating logic in source code.
However, Banerjee teaches:
identifying a location of metric generating logic in source code (Paragraph 69-70; where the identification of a particular logic, corresponding to metric generating logic, occurs via processing of the descendant location path).
Liu, Deshmukh, Phanishayee, and Banerjee are considered to be analogous to the claimed invention because they are in the same field of event management. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu in view of Deshmukh, further in view of Phanishayee to incorporate the teachings of Banerjee and identify a location of metric generating logic in source code. A person of ordinary skill in the art would have recognized the location of metric generating logic as a known method to yield the predictable outcome of deployment of a proper function to obtain metrics.
Regarding claim 9, Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee teach the method of claim 8. Liu teaches:
wherein the at least one metric element comprises a collector section associated with the microservice, wherein the metric generating logic generates a portion of the metrics associated with the microservice (Paragraph 214; “Custom Resource that provide the user with runtime flexibility to define collections of telemetric metrics and to selectively enable/disable the export of such collections, Changes to a Metric Group are pushed to each cluster that has been selected for the Metric Group (by default, a Metric Group may apply to all clusters)”, where each metric group corresponds to a metric element in the claim. The config map pushed to the clusters provides the configuration that the metric agents use as metric generating logic. This configuration and execution define a collector section and the agent generates a portion of the metrics. Paragraph 114 confirms association with a microservice, “The SDN architecture component microservices of configuration nodes 230, control nodes 232, compute nodes, user interface 244, and analytics nodes (not shown) may produce telemetry data.”).
Banerjee teaches:
identifying a location of metric generating logic in source code (Paragraph 69-70; where the identification of a particular logic, corresponding to metric generating logic, occurs via processing of the descendant location path).
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee, further in view of Sneed et al. (US 12373327 B2) hereafter Sneed.
Regarding claim 10, Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee teach the method of claim 9. Liu teaches:
an exporter creation system (Paragraphs 101-104; “Telemetry node 60 may transform... the subset of the one or more metrics into telemetry exporter configuration data (TECD) 63 that configures a telemetry exporter deployed at the one or more logically related elements... to export the subset of the one or more metrics”, where the telemetry node configures the telemetry exporter, thereby acting as the exporter creation system.).
Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee does not teach providing an abstract method from which the method implementations of the metric generating logic are generated as concrete implementations of the abstract method.
However, Sneed teaches:
providing an abstract method from which the method implementations of the metric generating logic are generated as concrete implementations of the abstract method (Col. 15, lines 58-67; where function signatures for metric functions/methods correspond to abstract methods used for concrete implementations of metric generating logic).
Liu, Deshmukh, Phanishayee, Banerjee and Sneed are considered to be analogous to the claimed invention because they are in the same field of event management. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee with Sneed to have provided an abstract method from which the method implementations of metric generating logic are generated as concrete implementations of the abstract method. A person of ordinary skill in the art would have understood the providing an abstract method as a known method in the art that would yield the predictable result of a structure for enabling monitoring of various metrics by changing certain variables rather than requiring rewriting of the monitoring code each time.
Regarding claim 11, Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee, further in view of Sneed teach the method of claim 10. Liu teaches:
wherein the exporter creation system constructs an instance of each method and creates a respective collector object from each instance (Paragraph 214; “Custom Resource that provide the user with runtime flexibility to define collections of telemetric metrics and to selectively enable/disable the export of such collections, Changes to a Metric Group are pushed to each cluster that has been selected for the Metric Group (by default, a Metric Group may apply to all clusters)”, where the metric group receives the configuration and effectively creates collector objects for each metric element defined in the metric group, thereby corresponding to each implementation of metric generating logic. Thus, the action of the exporter creation system constructing instances and creating collector objects is supported by the configuration-drive instantiation of metric agents and their collectors.).
Sneed teaches:
concrete implementations (Col. 15, lines 58-67; where function signatures for metric functions/methods correspond to abstract methods used for concrete implementations of metric generating logic).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee, further in view of Sneed, further in view of Brendle et al. (US 20050021354 A1) hereafter Brendle.
Regarding claim 12, Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee, further in view of Sneed teach the method of claim 11.
Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee, further in view of Sneed does not teach wherein each respective collector object comprises a respective reference to the instance of each of the concrete implementations and a respective reference to each of the at least one event monitoring system construct used by the event monitoring system.
However, Brendle teaches:
wherein each respective collector object comprises a respective reference to the instance of each of the concrete implementations and a respective reference to each of the at least one event monitoring system construct used by the event monitoring system (Paragraph 87; created objects that act as proxies for system entities correspond to the collector object. The created object instance inherently holds a reference to a concrete class implementation as it is an instance of that class. The ability to create multiple such objects for different classes implies references to multiple concrete implementations. Inner objects returned from method calls correspond to references to event monitoring system constructs used by the event monitoring system).
Liu, Deshmukh, Phanishayee, Banerjee, Sneed, and Brendle are considered to be analogous to the claimed invention because they are in the same field of event management. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee, further in view of Sneed with Brendle to have each respective collector object comprise a respective reference to the instance of each of the concrete implementations and a respective reference to each of the at least one event monitoring system construct used by the event monitoring system. A person of ordinary skill in the art would be motivated by the desire to pair implementations with relevant monitoring system constructs and the monitoring system itself to yield the predictable result of proper pairing of monitoring constructs with the system.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee, further in view of Brendle.
Regarding claim 13, Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee, teach the method of claim 9.
Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee does not teach wherein the exporter creation system is written in an interpreted language, and wherein the collector section comprises at least one module name of a module that contains the method implementations of the metric generating logic in the source code.
However, Brendle teaches:
wherein the exporter creation system is written in an interpreted language (Paragraph 213; “A computer program can be written in any form of programming language, including compiled or interpreted languages”), and wherein the collector section comprises at least one module name of a module that contains the method implementations of the metric generating logic in the source code (Paragraph 160; Brendle discloses storing the name of the module that provides logic for metric queries, corresponding to storing a module name. The service module must contain the logic to execute the query, corresponding to method implementations of metric generating logic in the source code).
Liu, Deshmukh, Phanishayee, Banerjee, and Brendle are considered to be analogous to the claimed invention because they are in the same field of event management. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Liu in view of Deshmukh, further in view of Phanishayee, further in view of Banerjee with Brendle to have the exporter creation system is written in an interpreted language, and wherein the collector section comprises at least one module name of a module that contains the method implementations of the metric generating logic in the source code. A person of ordinary skill in the art would have recognized the use of an interpreted language to be a known method for modular development, and the collector section comprising a module name containing method implementations of metric generating logic would yield the predictable result of pointing the system towards where metric generation logic is located.
Response to Arguments
Applicant's arguments filed 11/05/2025 have been fully considered but some are not persuasive. Applicant’s arguments are summarized below:
Claims 1-5 and 7-20 are not directed to abstract ideas, provide a practical application, and provide significantly more. Therefore, the rejections of claims 1-5 and 7-20 under 35 U.S.C. 101 should be withdrawn.
The prior art of record does not teach the newly amended limitations of independent claims 1, 17, and 19.
Dependent claims are submitted as allowable for at least the above reasons.
The Examiner respectfully disagrees with B and C.
With regard to the rejections of claims 1-5 and 7-20 under 35 U.S.C. 101, reanalysis of independent claims 1, 17, and 19 showed that a human would be unable to perform the action of executing a processing device within the mind, and therefore the independent claims do not recite an abstract idea. Claims dependent on independent claims 1, 17, and 19 do not recite further abstract ideas. Therefore, the analysis of claims 1-5 and 7-20 under 35 U.S.C. 101 ends at step 2A, prong one, with a conclusion of eligibility. Accordingly, the rejections of claims 1-5 and 7-20 under 35 U.S.C. 101 are withdrawn.
Applicant’s arguments with respect to claims 1, 17, and 19 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Independent claims 1, 17, and 19 remain rejected for the reasons stated above. Therefore, contrary to Applicant's arguments, because the dependent claims depend from an unpatentable claim and does not add limitations that overcome the rejection, it likewise remains rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Ghattu et al. (US 20240036947 A1) discusses a configuration testing API utilizing a one-to-one framework for API accessing, authentication, and monitoring.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH P TRAN whose telephone number is (571)272-6926. The examiner can normally be reached M-TH 4:30 a.m. - 12:30 p.m. PT, F 4:30 a.m. - 8:30 a.m. PT, or at Kenneth.Tran@uspto.gov.
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, April Blair can be reached at (571) 270-1014. 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.
/KENNETH P TRAN/ Examiner, Art Unit 2196
/APRIL Y BLAIR/ Supervisory Patent Examiner, Art Unit 2196