DETAILED ACTION
This office action is in response to claims filed 19 December 2025.
Claims 1-3, 5-16, and 18-22 are pending.
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 .
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-3, 5-16, and 18-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea (mental process) without significantly more.
Regarding claim 1, in step 1 of the 101 analysis set forth in MPEP 2106, the claim recites a system that performs actions upon detecting that a cluster is not utilized within a threshold amount associated with cost. A system is one of the four statutory categories of invention.
In step 2A, prong 1 of the 101 analysis set forth in the MPEP 2106, the examiner has determined that the following limitations recite a process that, under the broadest reasonable interpretation, covers a mental process but for recitation of generic computer components:
i. “identify, using a lookup table, a first user device associated with at least a first user of the one or more users that executed a first task associated with the plurality of cloud services based on a gateway address to obtain network layer information of the first user device” (a person can mentally obtain network layer information by simply evaluating a table or listing of data and make a judgement of particular information based on criteria).
ii. “determine a relationship between each cloud service of the plurality of cloud services based on the metrics and the network layer” (a person can mentally determine relationships between cloud services by simply evaluating services and making a judgement of relationships between them (MPEP 2106)).
iii. “determine one or more costs associated with the first node cluster, the one or more costs based on the relationship” (a person can mentally determine costs associated with clusters by simply evaluating services and making a judgement of costs (MPEP 2106)).
iii. “determine, based on the metrics, whether the first node cluster is utilized within a predetermined threshold” (a person can mentally determine cluster utilization by simply evaluating metrics and a threshold and making a judgement of cluster utilization (MPEP 2106)).
iv. “determining the first node cluster is not utilized within the predetermined threshold” (a person can mentally determine cluster utilization by simply evaluating metrics and a threshold and making a judgement of cluster utilization (MPEP 2106)).
If claim limitations, under their broadest reasonable interpretation, covers performance of the limitations as a mental process but for the recitation of generic computer components, then it falls within the mental process grouping of abstract ideas. Accordingly, the claim “recites” an abstract idea.
In step 2A, prong 2 of the 101 analysis set forth in MPEP 2106, the examiner has determined that the following additional elements do not integrate this judicial exception into a practical application:
v. “A system comprising: one or more processors; and a memory in communication with the one or more processors and storing instructions that, when executed by the one or more processors, are configured to cause the system to” (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05(f)).
vi. “receive real-time data corresponding to a first node cluster” (Insignificant extra-solution activity of mere data gathering (MPEP 2106.05(g))).
vii. “the first node cluster indicative of a plurality of cloud services live tracked and utilized by one or more users” (Generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h));
viii. “extract metrics associated with the plurality of cloud services” (Insignificant extra-solution activity of mere data gathering (MPEP 2106.05(g))).
ix. “responsive to determining…automatically conduct one or more actions associated with the one or more costs” (since the actions include transmitting an alert to a user (in claim 2), this analysis treats this as representing insignificant extra-solution activity of mere data output (MPEP 2106.05(g)). However, in the alternative, scaling sizes of a system, enabling users to create a dashboard, and generating an optimized resource are mental processes of observation, evaluation, judgement, and opinion).
In step 2B of the 101 analysis set forth in the 2019 PEG, the examiner has determined through reanalysis of the following limitations considered in step 2A prong 2, that the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
v. “A system comprising: one or more processors; and a memory in communication with the one or more processors and storing instructions that, when executed by the one or more processors, are configured to cause the system to” (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05(f)).
vi. “receive real-time data corresponding to a first node cluster” (well-understood, routine, and conventional activity of receiving transmitted data, (MPEP 2106.05(d)(II)).
vii. “the first node cluster indicative of a plurality of cloud services live tracked and utilized by one or more users” (Generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h));
viii. “extract metrics associated with the plurality of cloud services” (retrieving information in memory or extracting data from a document (MPEP 2106.05(g))).
ix. “responsive to determining…automatically conduct one or more actions associated with the one or more costs” (since the actions include transmitting an alert to a user (in claim 2), this represents a well-understood, routine, and conventional activity of receiving transmitted data. Scaling sizes of a system, enabling users to create a dashboard, and generating an optimized resource are mental processes of observation, evaluation, judgement, and opinion).
Considering the additional elements individually and in combination, and the claim as a whole, the additional elements do not provide significantly more than the abstract idea. Therefore, the claim is not patent eligible.
Regarding claim 2, the additional element “the one or more actions comprise one or more of scaling a size of the system, transmitting an alert to the one or more users, enabling the one or more users to create a dynamic dashboard, generating an optimized resource configuration, or combinations thereof” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (since the actions include transmitting an alert to a user (in claim 2), this analysis treats this as representing insignificant extra-solution activity of mere data output (MPEP 2106.05(g)). However, in the alternative, scaling sizes of a system, enabling users to create a dashboard, and generating an optimized resource are mental processes of observation, evaluation, judgement, and opinion), and under step 2B it does not amount to significantly more than the judicial exception (since the actions include transmitting an alert to a user (in claim 2), this represents a well-understood, routine, and conventional activity of receiving transmitted data. Scaling sizes of a system, enabling users to create a dashboard, and generating an optimized resource are mental processes of observation, evaluation, judgement, and opinion).
Regarding claim 3, the additional element “scaling the size of the system is based on one or more second node clusters remaining in the system” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 4, the additional element “the alert comprises an indication of waste associated with the first node cluster” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 5, the additional element “enabling the one or more users to create the dynamic dashboard comprises displaying, using an interactive graphical user interface (GUI) on a respective user device associated with the one or more users, one or more selectable user input objects” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra solution activity of mere data output (MPEP 2106.05(g)), and under step 2B it does not amount to significantly more than the judicial exception (well understood, routine, and conventional activity of transmitting data(MPEP 2106.05(d)(II)).
Regarding claim 6, the additional element “the optimized resource configuration comprises instructions for providing a second plurality of cloud services to the one or more users” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 7, the additional element “the plurality of cloud services comprise one or more of Infrastructure-as-a-Service (IaaS), Platforms-as-a-Service (PaaS), Software-as-a-Service (SaaS), or combinations thereof” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 8, the additional element “the relationship is indicative of a dependency of a first cloud service on a second cloud service of the plurality of cloud services” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 9, the additional element “the one or more costs comprise one or more of migration costs, operational costs, maintenance costs, security costs, or combinations thereof” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 10, it recites similar limitations as claim 1, and is therefore rejected for similar rationale. The additional element “wherein the relationship comprises at least one of a run-time dependency and an operational dependency between a first cloud service and a second cloud service of the plurality of cloud services” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claims 11-18, they comprise limitations similar to claims 2-9, respectively, and are therefore rejected for similar rationale.
Regarding claim 19, it recites similar limitations as claim 1, and is therefore rejected for similar rationale. The additional element “extract metrics associated with the plurality of cloud services, wherein the metrics comprise a time-ordered set of data points associated with the plurality cloud services” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally extract data by evaluating information, and making a judgment of particular information to identify (MPEP 2106.04(a))).
Regarding claim 20, it comprises limitations similar to those of claim 2, and are therefore rejected for similar rationale.
Regarding claim 21, the additional element “cause the system to: access an execution log storing information related to a plurality of tasks associated with the plurality of cloud services” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra-solution activity of mere data gathering (MPEP 2106.05(g))), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of retrieving information from memory, (MPEP 2106.05(d)(II)). Further the additional element “identify a second user device associated with at least a second user of the one or more users that executed a second task of the plurality of tasks to obtain application layer information” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally identify data by evaluating information, and making a judgment of particular information to identify (MPEP 2106.04(a))). Further the additional element “wherein the relationship is further based on the application layer information” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)), and under step 2B it does not amount to significantly more than the judicial exception (generally links the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)).
Regarding claim 22, the additional element “generate a dependency map illustrating a respective relationship between the (i) first user device and the first task, and (ii) the second user device and the second task by combining the application layer information and the network layer information” does not render the claim patent eligible because under step 2A prong 1, it recites a judicial exception (mental process) (a person can mentally generate a mapping by simply evaluating tasks, and making a judgment of a mapping relationship between tasks (MPEP 2106.04(a))). Further the additional limitation “cause a third user device to display the dependency map on an interactive graphical user interface (GUI)” does not render the claim patent eligible because under step 2A prong 2, it does not integrate the judicial exception into a practical application (insignificant extra-solution activity of mere data output (MPEP 2106.05(g))), and under step 2B it does not amount to significantly more than the judicial exception (well-understood, routine, and conventional activity of transmitting data over a network, (MPEP 2106.05(d)(II)).
Examiner’s Note
Claims 1-9 were not rejected using prior art.
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 10-16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over VEDAM Patent No.: US 11,240,139 B2 (hereafter VEDAM), in view of EINKAUF et al. Pub. No.: US 2016/0323377 A1 (hereafter EINKAUF).
VEDAM and EINKAUF were cited previously.
Regarding claim 10, VEDAM teaches the invention substantially as claimed, including:
A method comprising:
receiving data corresponding to a first node cluster in real-time as part of live tracking of cloud services, the first node cluster indicative of a plurality of cloud services utilized by one or more users ([Column 11, Lines 29-31 At step 902, the computing system may receive a service request for enabling an application service process from a client via a client computer. [Column 11, Lines 36-43] At step 904, a group of services may be identified for the service request to perform a service process over the service mesh via networks 110. The group of services may include a front service (e.g. a first service) and an end service (e.g., a second service). In some embodiments, the group of services may include one or more other services between the front service and the end service and form a service dependency path (e.g., FIG. 5) (i.e., service request is indicative of a plurality of services on the service dependency path). [Column 3, Lines 33-36] The present disclosure provides a practical solution of dynamically discovering (i.e., “live tracking”), linking and routing micro/nano-services over a dense services mesh network in a minimum cost topology. Embodiments described herein may apply dynamically configurable routing rules to discover, link and route any type of services for providing accurate responses to clients' inquiries globally. Embodiments described herein may maintain a reliable delivery of service-to-service communication through the complex topology of services in a cloud computing environment (i.e., reliable delivery of communications in a dynamically changing service topology suggests “real-time” topology discovery and routing based on “real-time” data));
extracting metrics associated with the plurality of cloud services; determining a relationship between each cloud service of the plurality of cloud services based on the metrics, wherein the relationship comprises at least one of a run-time dependency and an operational dependency between a first cloud service and a second cloud service of the plurality of cloud services ([Column 11, Lines 47-52] At step 906, each instance associated with the group of services along the service dependency path (i.e., dependency path represents “operational dependencies”) may iteratively query a global registry to obtain (i.e., “extract”) respective groups of active dependent service instances (i.e., metrics indicating availability of plural cloud services are used to obtain the services). The process 600 (604, 606 and 608) may be applied to obtain respective groups of active dependent instances along the service dependency path);
determining one or more costs associated with the first node cluster, the one or more costs based on the relationship ([Column 11, Lines 8-13] At step 804, the application server 140 associated with the service instance A1 may determine a service dependency path or a service routing link with a minimum cost vector. Based on the adjacency table associated with a service instance, the minimum cost decision algorithm may be utilized to build the minimum spanning tree on the meta-adjacency graph)…
automatically conducting one or more actions associated with the one or more costs ([Column 12, Lines 4-8] At step 910, the computing system may apply a minimum cost algorithm to determine a cost amount for each of the plurality of the service dependency path. The process 800 may be applied on each group of service instance to obtain a respective cost amount. [Column 12, Lines 12-16] At step 912, based on the service dependency path having a minimum cost, the computing system may execute a first service of the minimum-cost service dependency path. The computing system may further route the service inquiry to the second service instance in the service dependency path).
While VEDAM discusses optimizing a cost function, VEDAM does not explicitly teach
determining, based on the metrics, whether the first node cluster is utilized within a predetermined threshold; and
responsive to determining the first node cluster is not utilized within the predetermined threshold, automatically conducting one or more actions associated with the one or more costs;
However, in analogous art that similarly teaches a system optimizing cloud cluster costs, EINKAUF teaches:
determining, based on the metrics, whether the first node cluster is utilized within a predetermined threshold; and responsive to determining the first node cluster is not utilized within the predetermined threshold, automatically conducting one or more actions associated with the one or more costs ([0028] The systems described herein may allow the operator to create an auto-scaling policy so that if utilization exceeded 80%, the system would, automatically (e.g., programmatically) add capacity on behalf of the operator. Conversely, customers who launch clusters very often have the problem that the cluster (or a particular node thereof) is not doing anything and it is forgotten about. The systems described herein may allow the customer to define an auto-scaling policy that would reduce capacity (or shut down the cluster entirely) based on certain rules…In some embodiments, automatic cluster scaling may allow service provider customers to reduce their costs (e.g., by removing excess capacity) and helps them meet their own performance targets or service level agreements (e.g., by automatically adding capacity when there is significant demand) (i.e., automatically performing scaling actions to reduce costs));
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined EINKAUF’s teaching of performing autoscaling actions in response to cluster utilization meeting a threshold, with VEDAM’s teaching of optimizing cluster costs, to realize, with a reasonable expectation of success, a system that optimizes cluster costs, as in VEDAM, and determines when utilization meets a threshold to perform autoscaling, as in EINKAUF. A person having ordinary skill would have been motivated to make this combination to ensure customers reduce operating costs for cluster resources (EINKAUF [0028]).
Regarding claim 11, EINKAUF further teaches:
the one or more actions comprise one or more of scaling a size of the system, transmitting an alert to the one or more users, enabling the one or more users to create a dynamic dashboard ([0033] In response to determining that an auto-scaling trigger condition evaluates true, the auto-scaling rules engine 165 may send a notification to resource manager 150 indicating that an automatic scaling should be performed. [0034] In some embodiments, resource manager 150 may include a client interface through which one or more clients 110 may interact with provider network 100 to receive distributed computing services (i.e., client users receives notification, or an “alert” of recommended action via client interface, or “dashboard” on the resource manager)), generating an optimized resource configuration, or combinations thereof ([0028] The systems described herein may allow the operator to create an auto-scaling policy so that if utilization exceeded 80%, the system would, automatically (e.g., programmatically) add capacity on behalf of the operator. Conversely, customers who launch clusters very often have the problem that the cluster (or a particular node thereof) is not doing anything and it is forgotten about. The systems described herein may allow the customer to define an auto-scaling policy that would reduce capacity (or shut down the cluster entirely) based on certain rules…In some embodiments, automatic cluster scaling may allow service provider customers to reduce their costs (e.g., by removing excess capacity) and helps them meet their own performance targets or service level agreements (e.g., by automatically adding capacity when there is significant demand) (i.e., automatically performing “scaling” actions to reduce costs to an “optimal resource configuration”)).
Regarding claim 12, EINKAUF further teaches:
scaling the size of the system is based on one or more second node clusters remaining in the system ([0032] When increasing the capacity of one of the instance groups within a MapReduce cluster (such as MapReduce cluster 120), one or more available instances from various resource pools (such as resource pools 130) may be added to the instance group).
Regarding claim 13, EINKAUF further teaches:
the alert comprises an indication of waste associated with the first node cluster ([0033] In response to determining that an auto-scaling trigger condition evaluates true, the auto-scaling rules engine 165 may send a notification to resource manager 150 indicating that an automatic scaling should be performed. [0028] In some embodiments, automatic cluster scaling may allow service provider customers to reduce their costs (e.g., by removing excess capacity) (i.e., notification of auto scaling condition indicates that there are excessive, or “wasted” resources)).
Regarding claim 14, EINKAUF further teaches:
enabling the one or more users to create the dynamic dashboard comprises displaying, using an interactive graphical user interface (GUI) on a respective user device associated with the one or more users, one or more selectable user input objects ([0034] In some embodiments, resource manager 150 may include a client interface through which one or more clients 110 may interact with provider network 100 to receive distributed computing services. For example, in some embodiments, a client 110 may (through client interface 155) define an auto-scaling policy to be applied to one or more particular ones of the instance groups within MapReduce cluster 120. Each policy may define an expression (e.g., an auto-scaling trigger condition) to be evaluated when executing a distributed application on MapReduce cluster 120, may specify a scaling action to take when the expression evaluates true (e.g., add or remove capacity), may specify an amount or percentage by which to increase or decrease capacity, and/or may identify the cluster (and/or instance group(s) thereof), to which the policy applies. [0111] Cluster auto-scaling may be enabled upon creation of a cluster, or while a cluster is running, through a graphical user interface (GUI) of the distributed computing system (or any component thereof) or through user interface “wizard” that implements a policy/rule building application (i.e., user specifies various criteria of the distributed computing service by interacting with displayed “objects” in the GUI 155)).
Regarding claim 15, EINKAUF further teaches:
the optimized resource configuration comprises instructions for providing a second plurality of cloud services to the one or more users ([0119] As previously noted, the systems described herein may implement clusters of computing resource instances that include two or more instance groups, each containing a subset (e.g., an overlapping or non-overlapping subset) of instances (e.g., instances that may be designed for use with a particular type of workload). In some embodiments, some instance groups may be running particular services while others are not. For example, one instance group may be using spot instances, while another instance group may be using on-demand instances. As described herein, particular auto-scaling policies and corresponding auto-scaling actions may target particular ones of the instance groups within a cluster. For example, if an application is running out of HDFS capacity and needs to add more HDFS capacity, the use of a targeted auto-scaling policy may allow nodes to be added only to the instance group or groups that are running HDFS (i.e., auto scaling actions add resource instance groups which provide specific corresponding “second cloud services”, such as HDFS, to the users)).
Regarding claim 16, VEDAM further teaches:
the plurality of cloud services comprise one or more of Infrastructure-as-a-Service (IaaS), Platforms-as-a-Service (PaaS), Software-as-a-Service (SaaS), or combinations thereof ([Column 4, Lines 30-35] Central server 120 may be in communication with a plurality of application servers 140 in response to user requests for deploying applications to a plurality of client devices 150 via a network 110. As shown, central server computer 120 may receive a service request from client computer 140 via a browser 143 (i.e., central server provides an application, or “software” running on remote application servers to plural client devices as a “service”, thereby providing “software-as-a-service”)).
Regarding claim 18, VEDAM further teaches:
the one or more costs comprise one or more of migration costs, operational costs, maintenance costs, security costs, or combinations thereof (With micro-services, only the micro-service supporting the function with resource constraints needs to be scaled out, thus providing resource and cost optimization benefits. Routing a service instance to different adjacent dependent service instances may be associated with different costs. In a microservices-based architecture, for example, the system's runtime scalability may refer to its adaptability (at a reasonable cost) to changes in the number of users accessing it or refer to the development process ability to accommodate many developers working on it in parallel (i.e., executing services which includes routing service instances between dependent service instances, and providing access to the services, incurs costs associated with “operation” of those services, or “operational costs”)).
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over VEDAM, in view of EINKAUF, as applied to claim 10 above, and in further view of FEATONBY Patent No.: US 11,487,591 B1 (hereafter FEATONBY).
Regarding claim 19, VEDAM teaches the invention substantially as claimed, including:
one or more processors; and
a memory in communication with the one or more processors and storing instructions that, when executed by the one or more processors, are configured to cause the system to:
receive, in real-time, data corresponding to a first node cluster, the first node cluster indicative of a plurality of cloud services utilized by one or more users (([Column 11, Lines 29-31 At step 902, the computing system may receive a service request for enabling an application service process from a client via a client computer. [Column 11, Lines 36-43] At step 904, a group of services may be identified for the service request to perform a service process over the service mesh via networks 110. The group of services may include a front service (e.g. a first service) and an end service (e.g., a second service). In some embodiments, the group of services may include one or more other services between the front service and the end service and form a service dependency path (e.g., FIG. 5) (i.e., service request is indicative of a plurality of services on the service dependency path). [Column 3, Lines 33-36] The present disclosure provides a practical solution of dynamically discovering (i.e., “live tracking”), linking and routing micro/nano-services over a dense services mesh network in a minimum cost topology. Embodiments described herein may apply dynamically configurable routing rules to discover, link and route any type of services for providing accurate responses to clients' inquiries globally. Embodiments described herein may maintain a reliable delivery of service-to-service communication through the complex topology of services in a cloud computing environment (i.e., reliable delivery of communications in a dynamically changing service topology suggests “real-time” topology discovery and routing based on “real-time” data));
extract metrics associated with the plurality of cloud services…dynamically determine a relationship between each cloud service of the plurality of cloud services, wherein the relationship comprises at least one of a run-time dependency and an operational dependency between a first cloud service and a second cloud service of the plurality of cloud services ([Column 11, Lines 47-52] At step 906, each instance associated with the group of services along the service dependency path (i.e., dependency path represents “operational dependencies”) may iteratively query a global registry to obtain (i.e., “extract”) respective groups of active dependent service instances (i.e., metrics indicating availability of plural cloud services are used to obtain the services). The process 600 (604, 606 and 608) may be applied to obtain respective groups of active dependent instances along the service dependency path. [Column 7, Lines 27-30] The metadata of each service instance may include various features such as instance-state, instance-load, instance-capacity, cost, FIB as calculated and determined at that service instance, etc)…automatically conduct one or more actions ([Column 12, Lines 4-8] At step 910, the computing system may apply a minimum cost algorithm to determine a cost amount for each of the plurality of the service dependency path. The process 800 may be applied on each group of service instance to obtain a respective cost amount. [Column 12, Lines 12-16] At step 912, based on the service dependency path having a minimum cost, the computing system may execute a first service of the minimum-cost service dependency path. The computing system may further route the service inquiry to the second service instance in the service dependency path).
While VEDAM discusses extracting metrics including instance state, load, capacity, etc, VEDAM does not explicitly teach:
wherein the metrics comprise a time-ordered set of data points associated with the plurality of cloud services;
However, in analogous art that similarly extracts metrics, FEATONBY teaches:
wherein the metrics comprise a time-ordered set of data points associated with the plurality of cloud services ([Column 13, Lines 54-61] At block 506, the container service 140 obtains resource utilization data from the compute optimization service 136. For example, the container service 140 may obtain, using the identifiers associated with the container images, the historical resource utilization data associated with the respective container images from the compute optimization service 136. In some embodiments, the obtained resource utilization data is for prior executions of the same container image (i.e., historical resource utilization data represents time-ordered data points));
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined FEATONBY’s teaching of obtaining historical resource utilization data of container images, with VEDAM’s teaching of obtaining resource utilization data of container images, to realize, with a reasonable expectation of success, a system that obtains resource utilization data of container images, as in VEDAM, where the resource utilization data comprises historical, time-ordered data, as in FEATONBY. A person having ordinary skill would have been motivated to make this combination to make more accurate allocations of resources based on historical data.
While VEDAM and FEATONBY discuss optimizing a cost function, they do not explicitly teach
determine, based on the metrics, whether the first node cluster is utilized within a predetermined threshold; and
responsive to determining the first node cluster is not utilized within the predetermined threshold, automatically conduct one or more actions associated with the one or more costs;
However, in analogous art that similarly teaches a system optimizing cloud cluster costs, EINKAUF teaches:
determine, based on the metrics, whether the first node cluster is utilized within a predetermined threshold; and responsive to determining the first node cluster is not utilized within the predetermined threshold, automatically conducting one or more actions associated with the one or more costs ([0028] The systems described herein may allow the operator to create an auto-scaling policy so that if utilization exceeded 80%, the system would, automatically (e.g., programmatically) add capacity on behalf of the operator. Conversely, customers who launch clusters very often have the problem that the cluster (or a particular node thereof) is not doing anything and it is forgotten about. The systems described herein may allow the customer to define an auto-scaling policy that would reduce capacity (or shut down the cluster entirely) based on certain rules…In some embodiments, automatic cluster scaling may allow service provider customers to reduce their costs (e.g., by removing excess capacity) and helps them meet their own performance targets or service level agreements (e.g., by automatically adding capacity when there is significant demand) (i.e., automatically performing scaling actions to reduce costs));
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined EINKAUF’s teaching of performing autoscaling actions in response to cluster utilization meeting a threshold, with VEDAM and FEATONBY’s teaching of optimizing cluster costs, to realize, with a reasonable expectation of success, a system that optimizes cluster costs, as in VEDAM and FEATONBY, and determines when utilization meets a threshold to perform autoscaling, as in EINKAUF. A person having ordinary skill would have been motivated to make this combination to ensure customers reduce operating costs for cluster resources (EINKAUF [0028]).
Regarding claim 20, it comprises limitations similar to those of claim 11, and is therefore rejected for similar rationale.
Conclusion
THIS ACTION IS MADE FINAL. 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 MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
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, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/ Primary Examiner, Art Unit 2195