DETAILED ACTION
This office action is in response to claims filed 5 March 2026..
Claims 1-30 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 .
Response to Arguments
Applicant's arguments filed 5 March 2026 regarding the objections and rejections made for double patenting, and under 35 U.S.C. 112, and 101 have been fully considered and are persuasive. The objections and rejections have been withdrawn.
Applicant's arguments filed 5 March 2026 regarding the rejections made under 35 U.S.C. 102 have been fully considered but they are not persuasive.
On pages 12-13, the applicant argues the following:
“But one of ordinary skill in the art would recognize that aggregating measurements into a set of measurements does not teach generating a single usage value over a period of time by ‘combining the normalized usage value of each of the plurality of physical resources’ as recited in claim 1 as clarified herein…Applicant respectfully submits that this disclosure SUAREZ merely amounts to the determination of a normalized value for the cluster 410.”
“In contrast, Claim 1 requires the generation of a single usage value over a period of time by combining the normalized usage value of each of the plurality of physical resources.” Thus, applicant respectfully submits that Suarez fails to teach, disclose, or suggest at least the features of Claim 1 as clarified herein.
The examiner respectfully disagrees. While Suarez does discuss aggregating container utilization metrics into a set of utilization metrics for a cluster, the office action makes it clear that this set of utilization metrics is NOT what is being mapped to the claimed “single usage value.” Rather, the set of utilization metrics are used to determine a single utilization “percentage” indicative of the overall utilization of the cluster. In other words, this percentage, and not the set of utilization metrics, represents the claimed “single usage value”. SUAREZ clarifies this via an example scenario:
“In a first scenario, the first container instance 402A has fully (100 percent) utilized the two cores in its first processing resources 412A, and the second container instance 402B is utilizing none (zero percent) of the cores in its second processing resources 412B. If the instances were weighted equally, the overall processor utilization of the cluster 410 would be 50 percent; however, this would not be an accurate reflection of the processing capability of the cluster 410, because, in actuality, only two of the 10 allocated cores are being utilized, leaving eight cores available for work. Consequently, the processor utilization for the cluster 410 may take into account the total allocated processing units (in this example, processing units reflecting a number of cores), which, in the example 400, is 10. As a result, since only two out of 10 processing units are being fully utilized, the normalized processor utilization for the cluster 410 in scenario A is 20 percent” (Column 13, Lines 37-54).
Thus, in this scenario, aggregated normalized utilization of a cluster is represented by a single value: 20%. Therefore, the applicant’s argument is not persuasive.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-21, 23-26, and 29-30 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by SUAREZ et al. Patent No.: US 10,782,990 B1 (hereafter SUAREZ).
SUAREZ was cited previously.
Regarding claim 1, SUAREZ teaches:
A method comprising:
aggregating, via one or more data formats, a plurality of resource attributes for a plurality of resources associated with one or more computing systems over a period of time; executing one or more workloads on the plurality of physical systems; receiving, one or more utilization readings for a respective attribute from the one or more workloads ([Column 4, Lines 29-32] FIG. 1 illustrates an aspect of an environment 100 in which an embodiment may be practiced. As illustrated in FIG. 1, the environment 100 may include a cluster 110 of container instances 102A-02N running one or more services 108AA-NN in software containers 104AA-04NN. The container instances 102A-02N may also be reporting, through the network 106, processor utilization 112 and memory utilization 114 (i.e., processor and memory represent “resource attributes”, of which “utilization readings” of executing workloads are received via the reporting)); and
receiving, one or more allocation readings for the respective attribute from the one or more workloads ([Column 8, Lines 23-26] Cluster utilization data 222 may be values indicating an amount or proportion of available (i.e., unallocated) resources out of the total resources of the cluster (i.e., cluster utilization data indicates total and unused allocation amounts, representative of “allocation readings”));
calculating a normalized usage value for a respective resource ([Column 13, Lines 36-37] With the cluster 410, two scenarios are presented to illustrate normalization (i.e., normalization of utilization or “usage”) of the present disclosure) by:
assigning, one or more weightings to the respective resource; and Generating, based upon its one or more weightings and one or more allocations, one or more conversion units ([Column 13, Lines 48-54] The processor utilization for the cluster 410 may take into account the total allocated processing units (in this example, processing units reflecting a number of cores), which, in the example 400, is 10. As a result, since only two out of 10 processing units are being fully utilized, the normalized processor utilization for the cluster 410 in scenario A is 20 percent (i.e., percentage represents a “conversion unit” which applies a weight to a current utilization based on a ratio between processor resources allocated to a container and total processor resources allocated to a cluster)); and
dividing its one or more utilizations by the one or more conversion units to generate the normalized usage value ([Column 3, Lines 6-19] One method of normalizing may include multiplying the current resource utilization of a container instance by the total resource allocation of the container instance, and then dividing by the collective resources of the cluster. As an example, if, in a cluster of two virtual machine instances, a first virtual machine instance has been allocated six processing units and a second virtual machine instance has been allocated eight processing units (for a total of 14 processing units for the cluster), resource utilization may be normalized by multiplying (i.e., or “dividing” by the inverse) the current resource utilization (i.e., “utilization”) of a virtual machine instance by 6/14 (i.e., “conversion unit” for the first container), in the case of the first virtual machine instance, or by 8/14 (i.e., “conversion unit” of the second container), in the case of the second virtual machine instance (i.e., normalized resource usage for each container is calculated by using the following equation)
N
o
r
m
a
l
i
z
e
d
U
s
a
g
e
=
c
u
r
r
e
n
t
r
e
s
o
u
r
c
e
u
t
i
l
i
z
a
t
i
o
n
(
i
.
e
.
,
”
u
t
i
l
i
z
a
t
i
o
n
”
c
o
l
l
e
c
t
i
v
e
r
e
s
o
u
r
c
e
s
o
f
t
h
e
c
l
u
s
t
e
r
(
i
.
e
.
,
"
a
l
l
o
c
a
t
i
o
n
"
)
t
o
t
a
l
r
e
s
o
u
r
c
e
a
l
l
o
c
a
t
i
o
n
o
f
t
h
e
c
o
n
t
a
i
n
e
r
i
n
s
t
a
n
c
e
i
.
e
.
,
”
c
o
m
p
u
t
e
p
o
r
t
i
o
n
”
); and
generating, by combining the normalized usage value of each of the plurality of resources, a single usage value over a period of time ([Column 34, Lines 21-24] Aggregate, with other sets of measurements corresponding to the set of software containers for the application, the set of measurements into a set of aggregated measurements. [Column 13, Lines 51-54] As a result, since only two out of 10 processing units are being fully utilized, the normalized processor utilization for the cluster 410 in scenario A is 20 percent (i.e., normalized utilization measurements for each container are aggregated, or “summed”) into a single metric of utilization for the cluster).
Regarding claim 2, SUAREZ further teaches:
the single usage value over the period of time is further normalized to generate a single usage value per unit of time ([Column 5, Line 62-Column 6, Line 4] Processor utilization 112 may take any of a variety of forms, including…an average (e.g., mean, median, mode, etc.) of virtual or real processor utilization by an individual or collective plurality of the software containers 104AA-04NN over a particular range of time (i.e., average utilization represents a single utilization, or “usage” value over a range, or “unit of time”)).
Regarding claim 3, SUAREZ further teaches:
the single usage value per unit of time is an average ([Column 5, Line 62-Column 6, Line 4] Processor utilization 112 may take any of a variety of forms, including…an average (e.g., mean, median, mode, etc.) of virtual or real processor utilization by an individual or collective plurality of the software containers 104AA-04NN over a particular range of time (i.e., average utilization represents a single utilization, or “usage” value over a range, or “unit of time”)).
Regarding claim 4, SUAREZ further teaches:
the one or more data formats is transmitted over one or more data pipelines ([Column 33, Line 62-Column 34, Line 2] The first set of measurements (i.e., “data formats”) is obtained through a first communications channel (i.e., “pipeline”); the second set of measurements is obtained through a second communications channel; and the second instructions include instructions that cause the telemetry front-end service to: obtain a third set of measurements through a third communications channel (i.e., further, as illustrated in Fig. 5, telemetry data 520A is provided to the telemetry front-end service 514 via at least three channels or “pipelines”)).
Regarding claim 5, SUAREZ further teaches:
the one or more data formats are aggregated via one or more interfaces ([Column 14, Lines 25-30] FIG. 5 depicts the telemetry data 520A being provided to a telemetry front-end service 514 of a telemetry agent communication service 521, which, in turn, routes the grouped telemetry data 520B through a streaming service 524, which sends the streamed telemetry data 520C to a set of telemetry metrics processors 526 (i.e., telemetry front-end service 514 comprises at least three “interfaces” of the telemetry agent communication service because it receives telemetry data from, and therefore interfaces with, external data sources, and further groups, or “aggregates” the data)).
Regarding claim 6, SUAREZ further teaches:
the one or more interfaces comprise one or more plugins communicatively coupled with one or more computing systems and/or one or more collectors ([Column 14, Lines 25-30] FIG. 5 depicts the telemetry data 520A being provided to a telemetry front-end service 514 of a telemetry agent communication service 521, which, in turn, routes the grouped telemetry data 520B through a streaming service 524, which sends the streamed telemetry data 520C to a set of telemetry metrics processors 526 (i.e., telemetry front-end service 514 represents a “plug-in” for the telemetry agent communication service 521 because the telemetry front-end service 514 is an application that adds specific data collection, grouping, and routing features to the telemetry agent communication service 521)).
Regarding claim 7, SUAREZ further teaches:
the single usage value over the period of time is generated for one more application workloads ([Column 7, Line 58-Column 8, Line 17] The services 204A-04B may be applications (i.e., “workloads”) configured to run in software containers such as the software containers 208A-08C…The utilization data 220A-20B may be values reflecting resource utilization by the particular service (i.e., utilization reflects the resource usage of the applications)).
Regarding claim 8, SUAREZ further teaches:
the single usage value per unit of time is generated for one or more application workloads ([Column 7, Line 58-Column 8, Line 17] The services 204A-04B may be applications (i.e., “workloads”) configured to run in software containers such as the software containers 208A-08C…The utilization data 220A-20B may be values reflecting resource utilization by the particular service (i.e., average utilization reflects the average resource usage of the applications)).
Regarding claim 9, SUAREZ further teaches:
the single usage value per unit of time is generated for one or more cluster systems ([Column 13, Lines 51-54] As a result, since only two out of 10 processing units are being fully utilized, the normalized processor utilization for the cluster 410 in scenario A is 20 percent into a single metric of utilization for the cluster (i.e., single utilization metric represents resource usage of the cluster)).
Regarding claim 10, SUAREZ further teaches:
the received resource attribute readings are from one or more cluster systems and/or one or more cluster nodes ([Column 4, Lines 27-32] The environment 100 may include a cluster 110 (i.e., “cluster system”) of container instances 102A-02N running one or more services 108AA-NN in software containers 104AA-04NN. The container instances 102A-02N may also be reporting, through the network 106, processor utilization 112 and memory utilization 114 (i.e., utilization is collected from container nodes of a cluster)).
Regarding claim 11, SUAREZ further teaches:
the received resource attribute readings are from one or more containers ([Column 4, Lines 27-32] The environment 100 may include a cluster 110 (i.e., “cluster system”) of container instances 102A-02N running one or more services 108AA-NN in software containers 104AA-04NN. The container instances 102A-02N may also be reporting, through the network 106, processor utilization 112 and memory utilization 114 (i.e., utilization is collected from container nodes of a cluster)).
Regarding claim 12, SUAREZ further teaches:
the received resource attribute readings are from one or more virtual machines and/or one or more hypervisors ([Column 1, Line 62-Column 2, Line 2] A customer of a computing resource service provider providing computing resources capable of supporting execution of software containers has a service (e.g., software application for processing data, etc.) that the customer desires to run in one or more software containers in a cluster of one or more container instances (which may be virtual machine instances capable of hosting software containers) (i.e., resources utilized by containers reflect the resource utilization of the virtual machine that hosts those containers)).
Regarding claim 13, SUAREZ further teaches:
the single usage value per unit of time is generated for one or more logically grouped containers ([Column 13, Lines 51-54] As a result, since only two out of 10 processing units are being fully utilized, the normalized processor utilization for the cluster 410 in scenario A is 20 percent into a single metric of utilization for the cluster (i.e., clusters of containers represent containers that are “logically grouped”. Further, as illustrated in FIG.1, containers 104 are additionally grouped into container instances 102)).
Regarding claim 14, SUAREZ further teaches:
the single usage value per unit of time is generated for one or more environments ([Column 4, Lines 27-32] The environment 100 may include a cluster 110 (i.e., “cluster system”) of container instances 102A-02N running one or more services 108AA-NN in software containers 104AA-04NN. The container instances 102A-02N may also be reporting, through the network 106, processor utilization 112 and memory utilization 114 (i.e., utilization metrics are gathered from an “environment” 100, however, cluster 110 may also be considered to be a type of “environment”). [Column 13, Lines 51-54] As a result, since only two out of 10 processing units are being fully utilized, the normalized processor utilization for the cluster 410 in scenario A is 20 percent into a single metric of utilization for the cluster (i.e., the single metric of utilization represents utilization for the environment 100, comprising cluster 110)).
Regarding claim 15, SUAREZ further teaches:
the received resource attribute readings are from one or more environments ([Column 4, Lines 27-32] The environment 100 may include a cluster 110 (i.e., “cluster system”) of container instances 102A-02N running one or more services 108AA-NN in software containers 104AA-04NN. The container instances 102A-02N may also be reporting, through the network 106, processor utilization 112 and memory utilization 114 (i.e., utilization metrics are gathered from an “environment” 100, however, cluster 110 may also be considered to be a type of “environment”)).
Regarding claim 16, SUAREZ further teaches:
the received resource attribute readings are from one or more virtual clusters ([Column 4, Lines 27-32] The environment 100 may include a cluster 110 (i.e., “cluster system”) of container instances 102A-02N running one or more services 108AA-NN in software containers 104AA-04NN. The container instances 102A-02N may also be reporting, through the network 106, processor utilization 112 and memory utilization 114 (i.e., cluster 110 represents a “virtual cluster” because containers represent virtualized execution environments)).
Regarding claim 17, SUAREZ further teaches:
a respective resource attribute is normalized by first receiving a plurality of sub-attribute readings ([Column 3, Lines 6-19] One method of normalizing may include multiplying the current resource utilization of a container instance by the total resource allocation of the container instance, and then dividing by the collective resources of the cluster. As an example, if, in a cluster of two virtual machine instances, a first virtual machine instance has been allocated six processing units and a second virtual machine instance has been allocated eight processing units (for a total of 14 processing units for the cluster), resource utilization may be normalized by multiplying (i.e., or “dividing” by the inverse) the current resource utilization of a virtual machine instance by 6/14, in the case of the first virtual machine instance, or by 8/14, in the case of the second virtual machine instance (i.e., current resource utilization represents a “sub-attribute reading” because it is a preliminary or initial reading that must be multiplied by the processing unit allocation ratio (in this example, either 6/14 or 8/14) to determine the final normalized result)).
Regarding claim 18, SUAREZ further teaches:
aggregating one or more tags over the period of time, wherein the one or more tags are assigned to one or more computing systems, containers, logically grouped containers, environments, and/or applications ([Column 3, Lines 37-44] customers may apply a “label” (i.e., “tag”) to their software containers (e.g., an identifier may be assigned to a group of software containers), and telemetry metrics corresponding to software containers having the same label may be aggregated. In this manner, aggregation can be applied to arbitrary groupings, which, combined with autoscaling of the cluster based on aggregated telemetry measurements of a group being above or below a threshold).
Regarding claim 19, SUAREZ further teaches:
the single usage value per unit of time is generated for one or more tags ([Column 3, Lines 37-44] customers may apply a “label” to their software containers (e.g., an identifier may be assigned to a group of software containers), and telemetry metrics corresponding to software containers having the same label may be aggregated. In this manner, aggregation can be applied to arbitrary groupings, which, combined with autoscaling of the cluster based on aggregated telemetry measurements of a group being above or below a threshold (i.e., aggregated telemetry measurements for the one or more identifiers result in the single utilization metric for those identifiers)).
Regarding claim 20, SUAREZ further teaches:
aggregating one or more costs over the period of time ([Column 9, Line 64-Column 10, Line 8] If a certain task definition is overutilizing or underutilizing the cluster, the cluster may be scaled up, down, or rolled back accordingly. For example, a first set of utilization data may be obtained (first utilization measurement) before deploying a software application to the cluster. Then, after deployment, a second set of utilization data may be obtained (second utilization measurement) and compared with the first set. If the difference is too costly (e.g., the difference indicates that processing utilization or memory utilization has now exceeded a predetermined threshold) (i.e., determining an aggregated “cost” due to resource utilization), the change (e.g., the software deployment) may be undone/rolled back automatically).
Regarding claim 21, SUAREZ further teaches:
one or more of the costs are divided by the single usage value per unit of time to generate a cost per single usage value per unit of time ([Column 9, Line 64-Column 10, Line 8] If a certain task definition is overutilizing or underutilizing the cluster, the cluster may be scaled up, down, or rolled back accordingly. For example, a first set of utilization data may be obtained (first utilization measurement) before deploying a software application to the cluster. Then, after deployment, a second set of utilization data may be obtained (second utilization measurement) and compared with the first set. If the difference is too costly (e.g., the difference indicates that processing utilization or memory utilization has now exceeded a predetermined threshold) (i.e., cost is based on a single metric of utilization for a cluster and therefore represents a “cost per single usage value per unit time”), the change (e.g., the software deployment) may be undone/rolled back automatically).
Regarding claim 23, SUAREZ further teaches:
one or more costs are divided by the single usage value per unit of time for one or more of the tags to generate a cost per single usage value per unit of time for the one or more tags ([Column 9, Line 64-Column 10, Line 8] If a certain task definition is overutilizing or underutilizing the cluster, the cluster may be scaled up, down, or rolled back accordingly. For example, a first set of utilization data may be obtained (first utilization measurement) before deploying a software application to the cluster. Then, after deployment, a second set of utilization data may be obtained (second utilization measurement) and compared with the first set. If the difference is too costly (e.g., the difference indicates that processing utilization or memory utilization has now exceeded a predetermined threshold) (i.e., cost is based on a single metric of utilization for a cluster comprising containers and their associated identifiers, and therefore represents a “cost per single usage value per unit time”), the change (e.g., the software deployment) may be undone/rolled back automatically).
Regarding claim 24, SUAREZ further teaches:
the single usage value per unit of time is generated for one or more tags ([Column 9, Line 64-Column 10, Line 8] If a certain task definition is overutilizing or underutilizing the cluster, the cluster may be scaled up, down, or rolled back accordingly. For example, a first set of utilization data may be obtained (first utilization measurement) before deploying a software application to the cluster. Then, after deployment, a second set of utilization data may be obtained (second utilization measurement) and compared with the first set. If the difference is too costly (e.g., the difference indicates that processing utilization or memory utilization has now exceeded a predetermined threshold) (i.e., cost is based on a single metric of utilization for a cluster comprising containers and their associated identifiers, and therefore represents a “cost per single usage value per unit time”), the change (e.g., the software deployment) may be undone/rolled back automatically).
Regarding claim 25, SUAREZ further teaches:
one or more costs are divided by the single usage value per unit of time to generate a cost per single usage value per unit of time ([Column 9, Line 64-Column 10, Line 8] If a certain task definition is overutilizing or underutilizing the cluster, the cluster may be scaled up, down, or rolled back accordingly. For example, a first set of utilization data may be obtained (first utilization measurement) before deploying a software application to the cluster. Then, after deployment, a second set of utilization data may be obtained (second utilization measurement) and compared with the first set. If the difference is too costly (e.g., the difference indicates that processing utilization or memory utilization has now exceeded a predetermined threshold) (i.e., cost is based on a single metric of utilization for a cluster comprising containers, and therefore represents a “cost per single usage value per unit time”), the change (e.g., the software deployment) may be undone/rolled back automatically).
Regarding claim 26, SUAREZ further teaches:
one or more of the costs is divided by the single usage value per unit of time for one or more tags to generate a cost per single usage value per unit of time for the one or more tags ([Column 9, Line 64-Column 10, Line 8] If a certain task definition is overutilizing or underutilizing the cluster, the cluster may be scaled up, down, or rolled back accordingly. For example, a first set of utilization data may be obtained (first utilization measurement) before deploying a software application to the cluster. Then, after deployment, a second set of utilization data may be obtained (second utilization measurement) and compared with the first set. If the difference is too costly (e.g., the difference indicates that processing utilization or memory utilization has now exceeded a predetermined threshold) (i.e., cost is based on a single metric of utilization for a cluster comprising containers and their associated identifiers, and therefore represents a “cost per single usage value per unit time”), the change (e.g., the software deployment) may be undone/rolled back automatically).
Regarding claim 29, it comprises limitations similar to claim 1, and is therefore rejected for at least similar rationale. SUAREZ further teaches the additional limitation of aggregating, from one or more collectors ([Column 4, Lines 29-32] The container instances 102A-102N (“one or more collectors”) may also be reporting, through the network 106, processor utilization 112 and memory utilization 114).
Regarding claim 30, it comprises limitations similar to claim 1, and is therefore rejected for at least similar rationale. SUAREZ further teaches the additional limitation of Aggregating, via one or more interfaces ([Column 14, Lines 25-30] FIG. 5 depicts the telemetry data 520A being provided to a telemetry front-end service 514 of a telemetry agent communication service 521, which, in turn, routes the grouped telemetry data 520B through a streaming service 524, which sends the streamed telemetry data 520C to a set of telemetry metrics processors 526 (i.e., telemetry front-end service 514 comprises at least three “interfaces” of the telemetry agent communication service because it receives telemetry data from, and therefore interfaces with, external data sources, and further groups, or “aggregates” the data)).
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.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over SUAREZ, as applied to claim 2 above, and in further view of XU et al. Pub. No.: US 2017/0116042 A1 (hereafter XU)
XU was cited previously.
Regarding claim 22, while SUAREZ discusses execution of containers and monitoring of resource utilization, SUAREZ does not explicitly teach:
the single usage value per unit of time is generated for one or IoT devices.
However, in analogous art that similarly discusses execution of containers and monitoring of resource utilization, XU teaches:
the…usage value per unit of time is generated for one or IoT devices ([0004] The rapid growth of Internet of Things (IoT) has been driven in part by accessibility of wireless modules, sensors, and microcontrollers. As the number and variety of connected devices (i.e., “IoT devices”) increases, the demand for applications to interface with the devices and to process the large quantities of data produced by the devices also increases. To match this growing demand, web and mobile application developers are aligning their development practices and methodologies to meet the challenges of the IoT applications. Computing virtualization may be an attractive solution for the developers to rapidly develop, test, and deploy IoT applications across multiple platforms. [0039] The container monitor 432 is configured to monitor and track extended resource utilization of the IoT service containers 450 (i.e., IoT service containers represent containers that execute applications “for one or more IoT devices”). For example, upon receiving an extended resource constraint for an IoT service container 450 from the container manager 431, the container monitor 432 requests the resource manager 433 to reserve extended resources for the IoT service container 450 according to the extended resource constraint. While the IoT service container 450 is in operation, the container monitor 432 tracks and monitors the extended resource usage of the IoT service container 450. The container monitor 432 is further configured to communicate with the IoT service client 440. When the container monitor 432 receives a request from a user via the IoT service client 440, the container monitor 432 dispatches the request to the container manager 431 and/or the resource manager 433. The container monitor 432 may also send responses to the user in response to the requests (i.e., resource utilization of the IoT service container “for the one or more IoT devices” is monitored and output to the user)).
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 XU’s teaching of monitoring resource utilization of containers for IoT devices, with SUAREZ’s teaching of monitoring resource utilization of containers and determining a single utilization value, to realize, with a reasonable expectation of success, a system that monitors resource utilization of containers to determine a single utilization value, as in SUAREZ, where the container utilize resources for one or more IoT devices, as in XU. A person having ordinary skill would have been motivated to make this combination to support a wider array of different devices using virtualization (XU [0004]).
Claims 27 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over SUAREZ, as applied to claim 1 above, and in further view of ROTH et al. Patent No.: US 10,089,476 B1 (hereafter ROTH).
ROTH was cited previously.
Regarding claim 27, while SUAREZ teaches providing users with application containers and monitoring resource utilization, SUAREZ does not explicitly teach:
an account summary or invoice is then generated for one or more subscriptions.
However, in analogous art that similarly discusses providing users with application containers and monitoring resource utilization, ROTH teaches:
an account summary or invoice is then generated for one or more subscriptions ([Column 6, Lines 58-65] Aggregated usage reports and cost breakdowns may be generated to view itemized billing or resource use of particular compartments, particular users or resources within a compartment, or particular groups of users within a compartment. In at least another embodiment, aggregated usage reports for one or more containers may be combined into an overall usage report of all resource usage within the one or more containers (i.e., itemized billing from container resource usage represents an “account summary and/or invoice”)).
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 ROTH’s teaching of providing a user with a summary/invoice of costs related to resource utilization of containers, with SUAREZ’s teaching of monitoring resource utilization of containers, to realize, with a reasonable expectation of success, a system that monitors resource utilization of containers, as in SUAREZ, and provides a summary/invoice of the costs due to the resource utilization to a user, as in ROTH. A person having ordinary skill would have been motivated to make this combination to give users an enhanced level of understanding related to pricing and costs of maintaining container clusters.
Regarding claim 28, while SUAREZ teaches providing users with application containers and monitoring resource utilization, SUAREZ does not explicitly teach:
an account summary and/or invoice is then generated for one or more subscriptions.
However, in analogous art that similarly discusses providing users with application containers and monitoring resource utilization, ROTH teaches:
an account summary and/or invoice is then generated for one or more subscriptions ([Column 6, Lines 58-65] Aggregated usage reports and cost breakdowns may be generated to view itemized billing or resource use of particular compartments, particular users or resources within a compartment, or particular groups of users within a compartment. In at least another embodiment, aggregated usage reports for one or more containers may be combined into an overall usage report of all resource usage within the one or more containers (i.e., itemized billing from container resource usage represents an “account summary and/or invoice”)).
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 ROTH’s teaching of providing a user with a summary/invoice of costs related to resource utilization of containers, with SUAREZ’s teaching of monitoring resource utilization of containers, to realize, with a reasonable expectation of success, a system that monitors resource utilization of containers, as in SUAREZ, and provides a summary/invoice of the costs due to the resource utilization to a user, as in ROTH. A person having ordinary skill would have been motivated to make this combination to give users an enhanced level of understanding related to pricing and costs of maintaining container clusters.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
SLEDZ et al. Patent No.: US 10,033,620 B1 discloses compiling cluster utilization metrics into a single cluster usage percentage over periods of time.
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
Prosecution Insights