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 .
Examiner Notes
Examiner cites particular columns 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 apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in 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.
Response to Arguments
Applicant’s arguments filed September 18, 2025 have been fully considered but are not persuasive. With respect to the 101 rejections, Applicant argues that the claims are eligible because:
“The subject matter of claim 3 may prevent telemetry exporter (TE) 61 from exporting redundant metrics requested by two (or possibly) more requests. Removing overlapping metrics may promote more efficient telemetry exportation that consumes less computing resources (e.g., in the form of processing cycles, memory bus bandwidth, storage space, network bandwidth, etc. and associated power). This technological improvement may allow for more efficient operation of the SDN architecture system as well as nodes executing the telemetry exporter, including any intervening network devices. Accordingly, the subject matter of amended independent claims incorporate the judicial exception into a practical application that improves operation of SDN architecture system.” (Applicant’s Remarks, Pg. 8).
Examiner respectfully disagrees. “In computer-related technologies, the examiner should determine whether the claim purports to improve computer capabilities or, instead, invokes computers merely as a tool. Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1336, 118 USPQ2d 1684, 1689 (Fed. Cir. 2016). ” (MPEP 2106.05(a)). As discussed in the 101 rejection below, the the claims simply recite the addition of general purpose computers added post-hoc to an abstract idea rather than a specific implementation of a solution to a problem in the software arts. A claim whose entire scope can be performed mentally, cannot be said to improve computer technology. “Examples that the courts have indicated may not be sufficient to show an improvement in computer-functionality:... iii. Mere automation of manual processes,... [and] vi. Instructions to display two sets of information on a computer display in a non-interfering manner, without any limitations specifying how to achieve the desired result, Interval Licensing LLC v. AOL, Inc., 896 F.3d 1335, 1344-45, 127 USPQ2d 1553, 1559-60 (Fed. Cir. 2018).” (MPEP 2106.05(a)).
Applicant’s remaining arguments are related to newly amended claim language and have been fully addressed in the rejections below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter.
In adhering to the 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG), Step 1 is directed to determining whether or not the claims fall within a statutory class. Herein, the claims fall within statutory class of process, machine or manufacture. Hence, the claims qualify as potentially eligible subject matter under 35 U.S.C §101. With Step 1 being directed to a statutory category, the analysis directed to Step 2A.
Step 2A is a two prong inquiry. Prong 1 considers whether the claim recites a judicial exception (an abstract idea enumerated in the 2019 PEG, a law of nature, or a natural phenomenon). In this case independent claim 1 recites mental processes as applied to human activity (i.e. concepts performed in the human mind but for the recitation of generic computing components).
The following claimed steps are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, and/or opinion:
process a first request by which to enable a first metric group and process a second request by which to enable a second metric group...;
transform, based on the first request to enable the first metric group and the second request to enable the second metric group, the first subset of the one or more metrics and the second subset of the one or metrics into telemetry exporter configuration data that configures a telemetry exporter deployed at the compute nodes to export the first subset of the one or more metrics and at least one metric from the second subset of the one or more metrics, and to refrain from exporting the at least one overlapping metric with the second subset of the one or more metrics; and
interface with the telemetry exporter to configure, based on the telemetry exporter configuration data…
For example, but for the recitation of generic computing components, a person could mentally process the first and second requests. A person could also perform the “transform” and “interface” steps with the aid of pen and paper and through observation and judgement. As the Federal Circuit has explained, “[c]ourts have examined claims that required the use of a computer and still found that the underlying, patent-ineligible invention could be performed via pen and paper or in a person’s mind.” Versata Dev. Group v. SAP Am., Inc., 793 F.3d 1306, 1335, 115 USPQ2d 1681, 1702 (Fed. Cir. 2015).
Steps a-c describe formatting and transmitting metric data at a high level of generality. In other words, the claim recites comparing and formatting information for transmission. This is simply the organization and comparison of data which can be performed mentally and is an idea itself. It is similar to other concepts that have been identified as abstract by the courts, such as using categories to organize, store and transmit information in Cyberfone, or comparing new and stored information and using rules to identify options in SmartGene.
Since the claims are directed toward a judicial exception, analysis flows to Prong 2. Prong 2 considers whether the judicial exception is integrated into a practical application. In this case, the judicial exception is not integrated into a practical application because the claim language merely describes steps of collecting data, generic functions of comparing and formatting information, generic field of use/technological environment, and using a computer as a tool to apply the abstract idea and fails to describe an improvement to the functioning of a computer or other technical field. The additional elements recited in the claim do not integrate the judicial exception into a practical application for the following reasons:
The additional elements of “ a “network controller,” “SDN architecture system,” “processing circuitry,” and a “telemetry node” are recited at a high level of generality and amounts to using a generic computing component as a tool to apply the abstract idea (MPEP § 2106.05(f));
The additional element of “to be exported from compute nodes of a cluster managed by the network controller to the telemetry node, wherein the second metric group defines a second subset of the one or more metrics from the plurality of metrics, the second subset of the one or more metrics overlapping with the first subset of the one or more metrics by at least one overlapping metric of the plurality of metrics” amounts to insignificant extra-solution data gathering/data transmission activity (MPEP § 2106.05(g)).
The additional element of “exporter deployed at the compute nodes to export the subset of the one or more metrics”. The “export” step amounts to insignificant extra-solution data transmission activity. (MPEP 2106.05(c)). The recitation of an “exporter” is recited at a high level of generality and amounts to using a generic computing component as a tool to apply the abstract idea (MPEP § 2106.05(f));
The additional element of “the telemetry exporter to export the subset of the one or more metrics” amounts to insignificant extra-solution data transmission activity (MPEP § 2106.05(g)).
Since the claims are directed to the determined judicial exception, the analysis flows to Step 2B. Therein, the elements and combination of elements are examined in the claims to determine whether the claims as a whole amounts to significantly more than the judicial exception. In this case, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. It is noted here that the elements should be considered both individually and as an ordered combination. In this case, the claimed “network controller,” “SDN architecture system,” “processing circuitry,” and “telemetry node” are generically recited as mere instructions to implement an abstract idea on a computer. Thus, these steps do not add significantly more to the respective limitations. Taken as an ordered combination, the afore-mentioned limitations are directed to limitations referenced in Alice Corp. (also called the Mayo test) that are not enough to qualify as significantly more when recited in a claim with an abstract idea. (MPEP § 2106.05 (I)(A)), “Limitations that the courts have found not to be enough to qualify as “significantly more” when recited in a claim with a judicial exception include: i. …mere instructions to implement an abstract idea on a computer.” Furthermore, the telemetry node that performs the “transform” step is recited at a high level of generality and its broadest reasonable interpretation comprises only a generic node to simply perform the generic computer functions of processing and transmitting information. “A transformation applied to a generically recited article or to any and all articles would likely not provide significantly more than the judicial exception.” (MPEP 2106.05(c)). The limitations cited as insignificant extra-solution activities also do not add “significantly more” for the reasons cited in the Step 2A analysis. Furthermore, the courts have also recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: i. Receiving or transmitting data over a network……iv. Storing and retrieving information in memory. Viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself (Note MPEP 2106.05(a)). Since there are no elements or ordered combination of elements that amount to significantly more than the judicial exception, the claims are not eligible subject matter under 35 USC §101.
For the above reasons, the claims of this application are not patentable under 35 USC 101.
Regarding claim 2, The additional elements of “wherein the request defines a custom resource” amounts to insignificant extra-solution data gathering activity (MPEP § 2106.05(g)). The recitation of a “custom resource in accordance with a containerized orchestration platform” appears to be an attempt to generally link the use of the judicial exception to a particular technological environment or field of use. (MPEP 2106.05(h)).
Regarding claim 4, The additional elements of “wherein a container orchestration platform implements the network controller” appears to be an attempt to generally link the use of the judicial exception to a particular technological environment or field of use. (MPEP 2106.05(h)).
Regarding claim 5, the additional elements of :
a) “wherein the first metric group identifies the compute nodes of the cluster from which to export the subset of the one or more metrics as a cluster name;” and
b) … generate the telemetry exporter configuration data for the telemetry exporter associated with the cluster name”
are additional mental process because, but for the recitation of generic computing components, these steps can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, and/or opinion. Steps a) and b) describe formatting and transmitting metric data at a high level of generality. In other words, the claim recites comparing and formatting information for transmission. The recitation of a “ telemetry node” is recited at a high level of generality and its broadest reasonable interpretation comprises only a generic node to simply perform the generic computer functions of processing and transmitting information. Thus the recitation of “telemetry node” amounts to using a generic computing component as a tool to apply the abstract idea (MPEP § 2106.05(f)).
Regarding claim 6, the additional element of “wherein the telemetry node is further configured to receive telemetry data that represents the subset of the one or more metrics defined by the telemetry exporter configuration data” amounts to insignificant extra-solution data gathering activity (MPEP § 2106.05(g)).
Regarding claim 7, the additional element of “wherein the telemetry node is further configured to receive telemetry data that represents only the first subset of the one or more metrics and the second subset of the one or more metrics defined by the telemetry exporter configuration data, the first subset of the one or more metrics and the second subset of the one or more metrics including less than all of the plurality of the metrics” amounts to insignificant extra-solution data gathering activity (MPEP § 2106.05(g)).
Regarding claim 8, the additional element of “wherein the first subset of the one or more metrics includes less than all of the plurality of the metrics” amounts to insignificant extra-solution data gathering activity (MPEP § 2106.05(g)).
Regarding claim 9, the additional element of “wherein the first subset of one or more metrics includes one of border gateway protocol (BGP) metrics, peer metrics, Internet protocol (IP) version four (IPv4) metrics, IP version 6 (IPv6) metrics, Ethernet virtual private network (EVPN) metrics, and virtual router (vRouter) metrics” appears to be an attempt to generally link the use of the judicial exception to a particular technological environment or field of use. (MPEP 2106.05(h)).
Regarding claim 10, this claim is not patent eligible for the same reasons given for claim 1 for the common limitations. The recitation of the additional elements of a “software-defined networking (SDN) architecture system,” “compute nodes forming a cluster,” and “telemetry exporter” merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea under Prong 2. Therefore, these additional elements do not integrate the judicial exception into a practical application. “Merely adding generic computer components to perform the method is not sufficient. Thus, the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology.” (MPEP 2106.05(f)). Under Step 2B, since these additional elements merely recite generic computer components to carry out the abstract idea, they do not amount to significantly more than the judicial exception. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
Regarding claim 11, this claim is similar to claim 2 and is ineligible for the same reasons.
Regarding claim 13, this claim is similar to claim 4 and is ineligible for the same reasons.
Regarding claim 14, this claim is similar to claim 5 and is ineligible for the same reasons.
Regarding claim 15, this claim is similar to claim 6 and is ineligible for the same reasons.
Regarding claim 16, this claim is similar to claim 7 and is ineligible for the same reasons.
Regarding claim 17, this claim is similar to claim 8 and is ineligible for the same reasons.
Regarding claim 18, this claim is similar to claim 9 and is ineligible for the same reasons.
Regarding claim 19, this claim is not patent eligible for the same reasons given for claim 1 for the common limitations.
The following limitations to not recite a practical application or amount to “significantly more” for the following reasons:
The additional elements of “receive the telemetry exporter configuration data” and “collect, based on the telemetry exporter configuration data, metrics data corresponding to only the subset of the one or more metrics of the plurality of metrics” amounts to insignificant extra-solution data gathering activity (MPEP § 2106.05(g)).
The additional element of “export, to the telemetry node, the metrics data corresponding to only the subset of the one or more metrics of the plurality of metrics" amounts to insignificant extra-solution data transmission activity (MPEP § 2106.05(g)).
The recitation of the additional elements of a “logically-related elements,” “a logical element is configured to support a virtual network router and execute a telemetry exporter, ” and a “virtual network router” merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea under Prong 2. Therefore, these additional elements do not integrate the judicial exception into a practical application. “Merely adding generic computer components to perform the method is not sufficient. Thus, the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology.” (MPEP 2106.05(f)). Under Step 2B, since these additional elements merely recite generic computer components to carry out the abstract idea, they do not amount to significantly more than the judicial exception. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
Regarding claim 20, this claim is similar to claim 2 and is ineligible for the same reasons.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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 for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4, 6-11, 13 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Abraham (US 20200059420) in view of Lu et al. (US 11093518) and Badii et al. (US 20230067420).
As per claim 1, Abraham teaches the invention substantially as claimed including network controller for a software-defined networking (SDN) architecture system ([0037], Software-Defined Networking (“SDN”) controller 132 provides a logically and in some cases physically centralized controller for facilitating operation of one or more virtual networks within data center 110A in accordance with one or more examples of this disclosure. The terms SDN controller and Virtual Network Controller (“VNC”) may be used interchangeably throughout this disclosure), the network controller comprising:
processing circuitry ([0013], a computing system includes one or more processors coupled to a memory);
a telemetry node configured for execution by the processing circuitry ([0051], data center 110A further includes a policy controller 201…Policy controller 201 interacts with monitoring agents 205 that are deployed within at least some of the respective physical servers 216 for monitoring resource usage of the physical compute nodes as well as any virtualized host), the telemetry node configured to:
process a first request by which to enable a first metric group ([0055], One or more policies 202 may include instructions to cause one or more policy agents 205 to monitor one or more metrics associated with servers 126 ...One or more policies 202 may alternatively, or in addition, include instructions to cause policy agents 205 to report one or more metrics to policy controller 201) and process a second request by which to enable a second metric group ([0055], One or more policies 202 may include instructions to cause one or more policy agents 205 to monitor one or more metrics associated with servers 126 ...One or more policies 202 may alternatively, or in addition, include instructions to cause policy agents 205 to report one or more metrics to policy controller 201), wherein the first metric group defines a first subset of one or more metrics from a plurality of metrics to be exported from compute nodes of a cluster ([0055], One or more policies 202 may include instructions to cause one or more policy agents 205 to monitor one or more metrics associated with servers 126 ...One or more policies 202 may alternatively, or in addition, include instructions to cause policy agents 205 to report one or more metrics to policy controller 201) managed by the network controller ([0062], controller 302 may monitor and manage each of the public cloud 304, the private cloud 306, and the bare-metal server system 308) to the telemetry node ([0055], cause policy agents 205 to report one or more metrics to policy controller 201), wherein the second metric group defines a second subset of the one or more metrics from the plurality of metrics ([0055], One or more policies 202 may include instructions to cause one or more policy agents 205 to monitor one or more metrics associated with servers 126 ...One or more policies 202 may alternatively, or in addition, include instructions to cause policy agents 205 to report one or more metrics to policy controller 201).
Abraham fails to specifically teach, the second subset of the one or more metrics overlapping with the first subset of the one or more metrics by at least one overlapping metric of the plurality of metrics; transform, based on the first request to enable the first metric group and the second request to enable the second metric group, the first subset of the one or more metrics and the second subset of the one or metrics into telemetry exporter configuration data that configures a telemetry exporter deployed at the compute nodes to export the first subset of the one or more metrics and at least one metric from the second subset of the one or more metrics and to refrain from exporting the at least one overlapping metric with the second subset of the one or more metrics; and interface with the telemetry exporter to configure, based on the telemetry exporter configuration data, the telemetry exporter to export the subset of the one or more metrics.
However, Lu teaches, the telemetry node configured to:
the second subset of the one or more metrics overlapping with the first subset of the one or more metrics by at least one overlapping metric of the plurality of metrics (Column 109, Lines 54-63, the data intake and query system receives a query including search criteria. The query may be input by the user as an SPL command via a user interface. The data satisfying the search query can already be included in the metrics catalog. For example, data retrieved or derived from the metric store can be stored in the catalog or stored in the catalog. The data retrieved or derived from the metrics store can be obtained in accordance with a schedule such that metrics data is readily available for access from the in-memory catalog rather than needing to access the metric store; and Column 110, Lines 7-12, the metadata in the metrics catalog may indicate a metric or type of metric in the metrics store that should be monitored. Metrics data of that metric can be retrieved from the metrics stored in accordance with the metadata such that a subsequent query regarding that metric can be addressed without needing to access the metrics store);
transform, based on the first request to enable the first metric group and the second request to enable the second metric group, the first subset of the one or more metrics and the second subset of the one or metrics into telemetry exporter configuration data (Column 65, Lines 37-43, Once the user has selected the metric(s) and/or log source(s), the lower-tier DIQS generates custom script that the user enters into the command line of the lower-tier DIQS application on the host entity) that configures a telemetry exporter deployed at the compute nodes to export the first subset of the one or more metrics and at least one metric from the second subset of the one or more metrics (Column 65, Lines 40-43, When the lower-tier DIQS executes on the host entity, the custom script causes the collection of the user-specified data and events from the monitored entities; and Column 65, Lines 56-62, The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform. The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform to thereby configure and initiate processing at the targeted execution platform to supply machine data as indicated by the user input); and
interface with the telemetry exporter to configure, based on the telemetry exporter configuration data (Column 65, Lines 50-52, adapts the content of an installation script for the targeted execution platform based at least in part on the received indications; Column 65, Lines 56-62, The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform. The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform to thereby configure and initiate processing at the targeted execution platform to supply machine data as indicated by the user input; and Column 69, Lines 46-57, the lower-tier DIQS generates the script or command to reflect the user's data collection entries. For example, once the user has selected the metrics, log sources, and/or custom sources, the user saves the selections. The lower-tier DIQS provides an add data interface. FIG. 67 is an example of an add data interface displaying an interface diagram of an example user interface 1818. User interface 1818 displays a script 1818d that is an updated version of the script 1814d. Script 1818d has been updated to reflect the user's custom data collection entries and selections from the customize data collection user interface 1816), the telemetry exporter to export the subset of the one or more metrics (Column 65, Lines 40-43, When the lower-tier DIQS executes on the host entity, the custom script causes the collection of the user-specified data and events from the monitored entities; and Column 65, Lines 56-62, The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform. The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform to thereby configure and initiate processing at the targeted execution platform to supply machine data as indicated by the user input).
Abraham and Lu are analogous because they are each related to the collection of metrics for computing environments. Abraham teaches a method of provisioning computing environments according to a configuration and specifying metric to be collected. (Abstract, transforming, by a rules engine executing on the computing device, the high-level topology description to respective templates for the computing infrastructures that each describes a topology for a virtual computing environment in a format that conforms to a schema that can be processed by a corresponding one of the computing infrastructures to implement the virtual computing environment in the corresponding one of the computing infrastructures, and outputting the templates for configuring the computing infrastructures; and [0051], data center 110A further includes a policy controller 201 that provides monitoring, scheduling, and performance management for data center 110A. Policy controller 201 interacts with monitoring agents 205 that are deployed within at least some of the respective physical servers 216 for monitoring resource usage of the physical compute nodes as well as any virtualized host, such as VM 148, executing on the physical host. In this way, monitoring agents 205 provide distributed mechanisms for collecting a wide variety of usage metrics as well as for local enforcement of policies installed by policy controller 201). Lu teaches a method of provisioning computing environments according to a configuration including user-metrics to be collected for a configuration to be deployed (Abstract, Data intake and query system (DIQS) instances supporting applications including lower-tier, focused, work group oriented applications, are tailored to display the metrics for the needs of the user. An interface caused by operation of an entity monitoring system (EMS) operating in conjunction with the lower-tier DIQS displays the monitored entities as individual representations. The user selects a metric and a metric threshold; and Column 11, Lines 43-46, a monitor trigger may be included at or near the beginning of the executable code of the client application 110 such that the monitoring component 112 is initiated or triggered as the application is launched). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the configuration data of Abraham would be modified to include Lu’s user-selected metrics resulting in a system that deploys computing environments that collect user-specified metrics. Therefore, it would have been obvious to combine the teachings of Abraham and Lu.
The combination of Abraham-Lu fails to specifically teach, to refrain from exporting the at least one overlapping metric with the second subset of the one or more metrics.
However, Badii teaches refrain from exporting the at least one overlapping metric with the second subset of the one or more metrics ([0023], rather than allowing multiple write requests for a digital metric including the same value (e.g., multiple write requests for a digital metric with a value of “0”), the blocklist generation system allows write requests for that digital metric only when the value of that digital metric changes from the last write requests (e.g., when the value of the digital metric changes from a “0” to “1”)).
Badii also teaches, the second subset of the one or more metrics overlapping with the first subset of the one or more metrics by at least one overlapping metric of the plurality of metrics ([0023], multiple write requests for a digital metric including the same value (e.g., multiple write requests for a digital metric with a value of “0”)).
The combination of Abraham-Lu and Badii are analogous because they are each related to the collection of metrics for computing environments. Abraham teaches a method of provisioning computing environments according to a configuration and specifying metric to be collected. Lu teaches a method of provisioning computing environments according to a configuration including user-metrics to be collected for a configuration to be deployed. Badii teaches a method of collecting metrics including restricting some metric collection to improve collection efficiency. (Abstract, methods for improving the efficiency and flexibility of implementing computer devices by intelligently generating a metric blocklist based on predicted utilization of digital metrics and deploying the metric blocklist at one or more computing devices to limit digital metric requests to distributed databases). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, policy controller taught by the combination of Abraham-Lu would be modified to include Badii’s “blocklist” mechanism resulting in a system that deploys computing environments that collect user-specified metrics and restricts the collection of redundant metrics. Therefore, it would have been obvious to combine the teachings of the combination of Abraham-Lu and Badii.
As per claim 2, Abraham teaches, wherein the request defines a custom resource in accordance with a containerized orchestration platform ([0035], each of servers 126 may provide an operating environment for …other virtualized instances, such as containers; and [0062], if the network 300 receives instructions to perform a new task, controller 302 may provision network 300 to perform the new task by deploying new software and creating new infrastructure configurations in at least one of the public cloud 304, the private cloud 306, and the bare-metal server system 308).
As per claim 4, Abraham teaches, wherein a container orchestration platform implements the network controller ([0057], orchestrator 212 may implement an overall controller, such as controller 102 of FIG. 1).
As per claim 6, Lu teaches, wherein the telemetry node is further configured to receive telemetry data that represents the subset of the one or more metrics defined by the telemetry exporter configuration data (Column 67, Line 64-Column 68, Line 4, the user selects the “Customize” option on user interface 1814 and the lower-tier DIQS provides a custom data collection user interface, such as the user interface 1816. The user interface 1816 illustrates a list of metrics that can be collected to monitor the performance of the host, a list of log sources, options to select all, deselect all, select one or more of the metrics and log sources, and a field to enter custom sources).
As per claim 7, Lu teaches, wherein the telemetry node is further configured to receive telemetry data that represents only the subset of the one or more metrics defined by the telemetry exporter configuration data, the subset of the one or more metrics including less than all of the plurality of the metrics (Column 69, Lines 46-57, the lower-tier DIQS generates the script or command to reflect the user's data collection entries. For example, once the user has selected the metrics, log sources, and/or custom sources, the user saves the selections. The lower-tier DIQS provides an add data interface. FIG. 67 is an example of an add data interface displaying an interface diagram of an example user interface 1818. User interface 1818 displays a script 1818d that is an updated version of the script 1814d. Script 1818d has been updated to reflect the user's custom data collection entries and selections from the customize data collection user interface 1816).
As per claim 8, Lu teaches, wherein the subset of the one or more metrics includes less than all of the plurality of the metrics (Column 67, Line 64-Column 68, Line 4, the user selects the “Customize” option on user interface 1814 and the lower-tier DIQS provides a custom data collection user interface, such as the user interface 1816. The user interface 1816 illustrates a list of metrics that can be collected to monitor the performance of the host, a list of log sources, options to select all, deselect all, select one or more of the metrics and log sources, and a field to enter custom sources; and Column 69, Lines 46-57, the lower-tier DIQS generates the script or command to reflect the user's data collection entries. For example, once the user has selected the metrics, log sources, and/or custom sources, the user saves the selections. The lower-tier DIQS provides an add data interface. FIG. 67 is an example of an add data interface displaying an interface diagram of an example user interface 1818. User interface 1818 displays a script 1818d that is an updated version of the script 1814d. Script 1818d has been updated to reflect the user's custom data collection entries and selections from the customize data collection user interface 1816).
As per claim 9, Lu teaches, wherein the subset of one or more metrics includes one of border gateway protocol (BGP) metrics, peer metrics, Internet protocol (IP) version four (IPv4) metrics, IP version 6 (IPv6) metrics, Ethernet virtual private network (EVPN) metrics, and virtual router (vRouter) metrics (Column 7, Lines 45-54, Examples of components which may generate machine data from which events can be derived include, but are not limited to…routers…The machine data generated by such data sources can include, for example and without limitation, server log files, activity log files, configuration files, messages, network packet data, performance measurements, sensor measurements, etc.; and Column 10, Lines 32-35, a host device 106 comprising a router may generate one or more router logs that record information related to network traffic managed by the router).
As per claim 10, this is the “method claim” corresponding to claim 1 and is rejected for the same reasons. The same motivation used in the rejection of claim 1 is applicable to the instant claim.
A per claim 11, this claim is similar to claim 2 and is rejected for the same reasons.
A per claim 13, this claim is similar to claim 4 and is rejected for the same reasons.
A per claim 15, this claim is similar to claim 6 and is rejected for the same reasons.
A per claim 16, this claim is similar to claim 7 and is rejected for the same reasons.
A per claim 17, this claim is similar to claim 8 and is rejected for the same reasons.
A per claim 18, this claim is similar to claim 9 and is rejected for the same reasons.
As per claim 19, Abraham teaches the invention substantially as claimed including a software-defined networking (SDN) architecture system ([0037], Software-Defined Networking (“SDN”) controller 132 provides a logically and in some cases physically centralized controller for facilitating operation of one or more virtual networks within data center 110A in accordance with one or more examples of this disclosure. The terms SDN controller and Virtual Network Controller (“VNC”) may be used interchangeably throughout this disclosure), the SDN architecture system comprising:
a network controller ([0048], controller 102) comprising a memory ([0718], Computing device 700 includes in this example, a bus 742 ...Bus 742 couples ...memory device 744; Examiner Note: Computing device 700 is an instance of controller 102: [0716], computing device 700 may be an example instance of controller 102) configured to store a telemetry node ([0048], controller 102 to build and monitor infrastructure of data centers 110; and [0051], data center 110A further includes a policy controller 20) and a processor configured to execute a telemetry node ([0056], Various components, functional units, and/or modules illustrated in FIG. 1 (e.g., user interface device 129, orchestrator 130, SDN controller 132, and policy controller 201, policy agent 205) and/or illustrated or described elsewhere in this disclosure may perform operations described using software, hardware, firmware, or a mixture of hardware, software, and firmware residing in and/or executing at one or more computing devices), the telemetry node configured to:
process a first request by which to enable a first metric group ([0055], One or more policies 202 may include instructions to cause one or more policy agents 205 to monitor one or more metrics associated with servers 126 ...One or more policies 202 may alternatively, or in addition, include instructions to cause policy agents 205 to report one or more metrics to policy controller 201)and process a second request by which to enable a second metric group ([0055], One or more policies 202 may include instructions to cause one or more policy agents 205 to monitor one or more metrics associated with servers 126 ...One or more policies 202 may alternatively, or in addition, include instructions to cause policy agents 205 to report one or more metrics to policy controller 201), wherein the first metric group defines a first subset of one or more metrics from a plurality of metrics to be exported from compute nodes of a cluster ([0055], One or more policies 202 may include instructions to cause one or more policy agents 205 to monitor one or more metrics associated with servers 126 ...One or more policies 202 may alternatively, or in addition, include instructions to cause policy agents 205 to report one or more metrics to policy controller 201) managed by the network controller ([0062], controller 302 may monitor and manage each of the public cloud 304, the private cloud 306, and the bare-metal server system 308) to the telemetry node ([0055], cause policy agents 205 to report one or more metrics to policy controller 201), wherein the second metric group defines a second subset of the one or more metrics from the plurality of metrics ([0055], One or more policies 202 may include instructions to cause one or more policy agents 205 to monitor one or more metrics associated with servers 126 ...One or more policies 202 may alternatively, or in addition, include instructions to cause policy agents 205 to report one or more metrics to policy controller 201); and
a logical element ([0051], monitoring agents 205 provide distributed mechanisms for collecting a wide variety of usage metrics as well as for local enforcement of policies installed by policy controller 201; and [0056], Various components, functional units, and/or modules illustrated in FIG. 1 (e.g., user interface device 129, orchestrator 130, SDN controller 132, and policy controller 201, policy agent 205) and/or illustrated or described elsewhere in this disclosure may perform operations described using software) is configured to support a virtual network router ([0043], Virtual routers 142 (virtual router 142A to virtual router 142N, collectively “virtual routers 142” in FIG. 1) execute multiple routing instances for corresponding virtual networks within data center 110A; and [0724], Computing device 700 may be coupled to a physical network switch fabric that includes an overlay network that extends switch fabric from physical switches to software or “virtual” routers of physical servers coupled to the switch fabric, such virtual router 220 of FIG. 2. Computing device 700 may use one or more dedicated virtual networks to configure minion nodes of a cluster) and execute a telemetry exporter ([0051], Policy controller 201 interacts with monitoring agents 205 that are deployed within at least some of the respective physical servers 216 for monitoring resource usage of the physical compute nodes as well as any virtualized host, such as VM 148, executing on the physical host. In this way, monitoring agents 205 provide distributed mechanisms for collecting a wide variety of usage metrics as well as for local enforcement of policies installed by policy controller 201).
Abraham fails to specifically teach, the second subset of the one or more metrics overlapping with the first subset of the one or more metrics by at least one overlapping metric of the plurality of metrics; transform, based on the first request to enable the first metric group and the second request to enable the second metric group, the first subset of the one or more metrics and the second subset of the one or metrics into telemetry exporter configuration data that configures a telemetry exporter deployed at the compute nodes to export the first subset of the one or more metrics and at least one metric from the second subset of the one or more metrics, and to refrain from exporting the at least one overlapping metric with the second subset of the one or more metrics; and interface with the telemetry exporter to configure, based on the telemetry exporter configuration data, the telemetry exporter to export the subset of the one or more metrics; wherein the telemetry exporter is configured to: receive the telemetry exporter configuration data; collect, based on the telemetry exporter configuration data, metrics data corresponding to only the subset of the one or more metrics of the plurality of metrics; and export, to the telemetry node, the metrics data corresponding to only the subset of the one or more metrics of the plurality of metrics.
However, Lu teaches, the telemetry node configured to:
the second subset of the one or more metrics overlapping with the first subset of the one or more metrics by at least one overlapping metric of the plurality of metrics (Column 109, Lines 54-63, the data intake and query system receives a query including search criteria. The query may be input by the user as an SPL command via a user interface. The data satisfying the search query can already be included in the metrics catalog. For example, data retrieved or derived from the metric store can be stored in the catalog or stored in the catalog. The data retrieved or derived from the metrics store can be obtained in accordance with a schedule such that metrics data is readily available for access from the in-memory catalog rather than needing to access the metric store; and Column 110, Lines 7-12, the metadata in the metrics catalog may indicate a metric or type of metric in the metrics store that should be monitored. Metrics data of that metric can be retrieved from the metrics stored in accordance with the metadata such that a subsequent query regarding that metric can be addressed without needing to access the metrics store);
transform, based on the first request to enable the first metric group and the second request to enable the second metric group, the first subset of the one or more metrics and the second subset of the one or metrics into telemetry exporter configuration data (Column 65, Lines 37-43, Once the user has selected the metric(s) and/or log source(s), the lower-tier DIQS generates custom script that the user enters into the command line of the lower-tier DIQS application on the host entity) that configures a telemetry exporter deployed at the compute nodes to export the first subset of the one or more metrics and at least one metric from the second subset of the one or more metrics (Column 65, Lines 40-43, When the lower-tier DIQS executes on the host entity, the custom script causes the collection of the user-specified data and events from the monitored entities; and Column 65, Lines 56-62, The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform. The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform to thereby configure and initiate processing at the targeted execution platform to supply machine data as indicated by the user input; Examiner Note: each of the claimed first metric group and second metric group are only required to include one metric; therefore, if the second metric group contains the same metric(s) as the first metric group then only the metric(s) of the first metric group will be collected); and
interface with the telemetry exporter to configure, based on the telemetry exporter configuration data (Column 65, Lines 50-52, adapts the content of an installation script for the targeted execution platform based at least in part on the received indications; Column 65, Lines 56-62, The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform. The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform to thereby configure and initiate processing at the targeted execution platform to supply machine data as indicated by the user input; and Column 69, Lines 46-57, the lower-tier DIQS generates the script or command to reflect the user's data collection entries. For example, once the user has selected the metrics, log sources, and/or custom sources, the user saves the selections. The lower-tier DIQS provides an add data interface. FIG. 67 is an example of an add data interface displaying an interface diagram of an example user interface 1818. User interface 1818 displays a script 1818d that is an updated version of the script 1814d. Script 1818d has been updated to reflect the user's custom data collection entries and selections from the customize data collection user interface 1816), the telemetry exporter to export the subset of the one or more metrics (Column 65, Lines 40-43, When the lower-tier DIQS executes on the host entity, the custom script causes the collection of the user-specified data and events from the monitored entities; and Column 65, Lines 56-62, The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform. The lower-tier DIQS can cause the performance of the installation script at the targeted execution platform to thereby configure and initiate processing at the targeted execution platform to supply machine data as indicated by the user input).
and
wherein the telemetry exporter is configured to:
receive the telemetry exporter configuration data (Column 70, Lines 21-26, the execution of the script, perhaps by the command processing shell, configures and installs data collection software on the host entity to collect source data from the virtual and physical infrastructure associated with the host entity. The collected source data is responsive to the data collection information from the user);
collect, based on the telemetry exporter configuration data, metrics data corresponding to only the subset of the one or more metrics of the plurality of metrics (Column 70, Lines 27-38, downloads a software package on the host, determines the operating system of the host, a retrieves the appropriate collection agent for the host's operating system. The lower-tier DIQS-created script further configures the collection agent and installs a collector, such as a forwarder, heavy forwarder, or universal forwarder when data from log sources is to be collected and begins collecting data responsive to the data collection information from the user from the monitored entities. The data collection information includes the monitoring machine, metrics with dimensions, log sources, and custom sources entered by the user at user interfaces); and
export, to the telemetry node, the metrics data corresponding to only the subset of the one or more metrics of the plurality of metrics (Column 65, Lines 40-44, When the lower-tier DIQS executes on the host entity, the custom script causes the collection of the user-specified data and events from the monitored entities. The lower-tier DIQS displays the collected data and events for trouble shooting and analysis; and Column 65, Lines 62-64, receive machine data at the DIQS for ingestion from the targeted execution platform in accordance with the performance of the installation script).
The combination of Abraham-Lu fails to specifically teach, to refrain from exporting the at least one overlapping metric with the second subset of the one or more metric.
However, Badii teaches to refrain from exporting the at least one overlapping metric with the second subset of the one or more metrics ([0023], rather than allowing multiple write requests for a digital metric including the same value (e.g., multiple write requests for a digital metric with a value of “0”), the blocklist generation system allows write requests for that digital metric only when the value of that digital metric changes from the last write requests (e.g., when the value of the digital metric changes from a “0” to “1”)).
Badii also teaches, the second subset of the one or more metrics overlapping with the first subset of the one or more metrics by at least one overlapping metric of the plurality of metrics ([0023], multiple write requests for a digital metric including the same value (e.g., multiple write requests for a digital metric with a value of “0”)).
The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 20, Abraham teaches, wherein the request defines a custom resource in accordance with a containerized orchestration platform ([0035], each of servers 126 may provide an operating environment for …other virtualized instances, such as containers; and [0062], if the network 300 receives instructions to perform a new task, controller 302 may provision network 300 to perform the new task by deploying new software and creating new infrastructure configurations in at least one of the public cloud 304, the private cloud 306, and the bare-metal server system 308).
Claims 5 and 14 rejected under 35 U.S.C. 103 as being unpatentable over the combination of Abraham-Lu-Badii as applied to independent claims 1 and 10 and in further view of Jowett et al. (US 20060161387).
As per claim 5, the combination of Abraham-Lu-Badii fails to specifically teach, wherein the metric group identifies the compute nodes of the cluster from which to export the subset of the one or more metrics as a cluster name, and wherein the telemetry node is, when configured to transform the metric group, configured to generate the telemetry exporter configuration data for the telemetry exporter associated with the cluster name.
However, Jowett teaches, wherein the metric group identifies the compute nodes of the cluster from which to export the subset of the one or more metrics as a cluster name ([0034], The configuration UI 206 contains individual sections logically grouping the various settings concerning a metric; and [0054], the output log file 304 containing metric data in a client system 212 includes a parameter called "group name." The central metrics storage module 218, which can be a database, includes an attribute called "metric name." The transformation process prefixes the "group name" to the "metric name" and the resulting string is stored as the actual "metric name."; and [0046], the data collection module 208 includes a specific identification (number or otherwise) within the metric data sent to the central metrics storage module 218. The identification may include items such as machine name or other hardware/software based identification mechanism that will allow the analysis component 220 to access data specific to a machine or a collection of machines from the central metrics storage module 218), and
wherein the telemetry node is, when configured to transform the metric group, configured to generate the telemetry exporter configuration data for the telemetry exporter associated with the cluster name ([0054], The transformation process prefixes the "group name" to the "metric name" and the resulting string is stored as the actual "metric name.").
The combination of Abraham-Lu-Badii and Jowett are analogous because they are each related to the collection of metrics for computing environments. Abraham teaches a method of provisioning computing environments according to a configuration and specifying metric to be collected. Lu teaches a method of provisioning computing environments according to a configuration including user-metrics to be collected for a configuration to be deployed. Badii teaches a method of collecting metrics including restricting some metric collection to improve collection efficiency. Jowett teaches a method of collecting metrics including grouping subsets of metrics. (Abstract, framework for collecting, storing, and analyzing system metrics concerning a computing system or a computer component. A configuration module is provided to configure settings specific to a metric. A data collection module is provided to collect metric data according to the settings in the configuration module and in one or more component specific plug-ins that extend and customize the framework according to specific needs of the component; and [0054], the output log file 304 containing metric data in a client system 212 includes a parameter called "group name." The central metrics storage module 218, which can be a database, includes an attribute called "metric name." The transformation process prefixes the "group name" to the "metric name" and the resulting string is stored as the actual "metric name."). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the metric data of the combination of Abraham-Lu would be modified to include Jowett’s “group name” resulting in a system that provides a grouping of user-selected metrics. Therefore, it would have been obvious to combine the teachings of the combination of Abraham-Lu and Jowett.
A per claim 14, this claim is similar to claim 5 and is rejected for the same reasons. The same motivation used in the rejection of claim 5 is applicable to the instant claim.
Conclusion
Applicant's amendment necessitated the new grounds 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 MELISSA A HEADLY whose telephone number is (571)272-1972. The examiner can normally be reached Monday- Friday 9-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at 571-272-3338. 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.
/MELISSA A. HEADLY/
Examiner Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights