DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments filed July 16, 2026 have been fully considered but are not persuasive. Applicant’s arguments are related to newly amended claim language and have been fully addressed in the rejections below.
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.
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439).
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, 4, 7-9, 12, 15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Anand et al. (US 20210342193) in view of Venkadasamy et al (US 20200174839) and Chen et al. (US 20230012021).
As per claim 1, Anand teaches the invention substantially as claimed including a computer-implemented method comprising:
identifying, using .... first telemetry data of a container ([0032], data repository 108 can store historical node utilization metrics data values over time. Metrics data collected by orchestrator 110 and stored in node utilization area 2121 can be associated to, e.g., a container and application ID and node identifier so that the stored data provides statistics on node performance as well as application performance over time; Examiner Note: the claimed “first telemetry data” is mapped to Anand’s “historical node utilization metrics”), a set of features predicting a resource usage of the container ([0037], Orchestrator 110 can predict runtime utilization characteristics of a container based application running within system 100 using, e.g., a combination of historical application utilization data stored within node utilization area 2121 and SLA parameter values stored in area 2122), the container comprising an executing application ([0045], A container can be mapped to a specific application and an application mapping to a container can be regarded to be a container based application. In the described example of FIG. 1, container CA runs application A, container CB runs application B, and container CC runs application C);
predicting, using a time series analysis applied to data of the identified set of features, a future resource usage of the container at a future time ([0041], Orchestrator 110 running application process 113 can predict application utilization characteristics of container based applications running in system 100 during a next time period; [0062], orchestrator 110 can plot a plurality of CPU availability values for a certain compute node over time up to the current time t=N and can plot regression line 3003 with reference to the plotted data values. Orchestrator 110, in the scenario described with reference to FIG. 3A, can determine that regression line value 3004 at a next time period t=N+1 relative to the current time t=N is the value for predicted CPU availability at a next time period; and [0072], orchestrator 110 can train predictive model 4002 to predict average utilization for respective container-based applications run by system 100. Predictive model 4002 can be trained with training data and once trained can be configured to predict average utilization of an application across a plurality of metrics, e.g., CPU utilization data, memory utilization data, storage utilization data, I/O utilization data, latency utilization data, errors utilization data, traffic utilization data, and/or saturation utilization data), the data of the identified set of the features extracted from second telemetry data of the container ([0036], Global applications registry 2124 can store data indicating characteristics of container based applications as determined from obtained metrics data; and [0071], Orchestrator 110 can iteratively train the predictive models of FIGS. 3A-3E, and can iteratively query the trained predictive models to generate lists of predicted availability of each compute node of system 100 across a plurality of performance characteristics, e.g. involving CPU availability, memory availability, storage availability, and I/O availability)that is distinct from the first telemetry data ([0031], Orchestrator 110 can be configured to iteratively obtain metrics data from respective ones of computing environments 140A-140Z and using the iteratively obtained metrics data can iteratively update data repository 108).
Anand fails to specifically teach, identifying, using a regression analysis on first telemetry data of a container, a set of features predicting a resource usage of the container wherein the regression analysis determines weights corresponding to a relative predictive importance of each feature; and adjusting, at the future time according to the future resource usage, a size of a resource available to the container.
However, Venkadasamy teaches, identifying, using a regression analysis on first telemetry data of a container ([0014], To forecast the growth of an application with respect to use of resources, time-series data containing historical allocations of resources to the application and/or historical performance metrics for the application are obtained...a linear regression model may be used to estimate the growth rate as the slope of a line that is fit to a time series of historical allocations of the application regarding processor, memory, and/or other physical resources), a set of features predicting a resource usage of the container ([0044], Multiple versions of a machine learning model may be adapted to different applications, resources, or pools 220, or the same machine learning model may be used to predict usage rates 210, growth rates 112, allocation increase 216, and/or additional hosts 218 for all applications, resources, and/or pools 22),the container comprising an executing application ([0012], applications are deployed in containers within one or more sets of hosts); and
adjusting, at the future time according to the future resource usage, a size of a resource available to the container ([0015], Estimated growth rates of applications with respect to one or more resources are then used to determine increases in resource allocations to the applications that support the growth rates).
Venkadasamy also teaches, predicting, using a time series analysis of data of the set of features, a future resource usage of the container at a future time (Abstract, During operation, the system obtains time-series data containing resource allocations for applications deployed in one or more containers within a set of hosts. Next, the system applies one or more machine learning models to the time-series data to estimate a growth rate associated with use of a resource by an application. The system then determines an increase in allocation of the resource to the application that supports the estimated growth rate).
Anand and Venkadasamy are analogous because they are each related to container management. Anand teaches a method of container management and provisioning based on predicted container utilization based on past telemetry data. ([0040], Orchestrator 110 running API process 111 can also iteratively push updated global registry data and global application registry data to data repositories associated to respective clusters of computing environments 140A-140Z. Global registry data and global application registry data can include e.g. tables, ordered lists, and/or trained predictive models that have been trained by machine learning. Orchestrator 110 running availability process 112 can predict an availability of compute nodes of computing environments 140A-140Z using metrics data stored in node utilization area 2121 of orchestrator data repository 108. API process 111 or orchestrator 110 can be provided using an open service broker API. An open service broker API can facilitate such functions as (a) obtaining data on services and a service broker provides; (b) provisioning service instances; (c) connecting container based applications to service instances; and (d) deprovisioning service instances). Venkadasamy teaches a method of container management including container scaling based on predicted resource utilization using regression analysis of telemetry data. (Abstract, system for forecasting container-based resource usage. During operation, the system obtains time-series data containing resource allocations for applications deployed in one or more containers within a set of hosts. Next, the system applies one or more machine learning models to the time-series data to estimate a growth rate associated with use of a resource by an application. The system then determines an increase in allocation of the resource to the application that supports the estimated growth rate. Finally, the system outputs the increase in allocation for use in managing use of resources within the set of hosts; and [0014], To forecast the growth of an application with respect to use of resources, time-series data containing historical allocations of resources to the application and/or historical performance metrics for the application are obtained...a linear regression model may be used to estimate the growth rate as the slope of a line that is fit to a time series of historical allocations of the application regarding processor, memory, and/or other physical resources). 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 teachings of Anand would be modified with the scaling mechanism taught by Venkadasamy resulting in a system that manages container resources based on predicted resource utilization. Therefore, it would have been obvious to combine the teachings of Anand and Venkadasamy.
The combination of Anand-Venkadasamy fails to specifically teach, wherein the regression analysis determines weights corresponding to a relative predictive importance of each feature.
However, Chen teaches, wherein the regression analysis determines weights corresponding to a relative predictive importance of each feature ([0167], the self-tuning resource allocating system 528 calculates a weight for the first resource object grouping using a linear regression function and utilization statistics associated with the first resource object group associated with a sampling period. For example, the self-tuning resource allocating system 528 may define the utilization of each resource group as feature x.sub.k, and calculate weight θ.sub.k of each feature that contributes to the system performance using the linear regression function below, where n is the number of utilization stats collected in sampling periods).
The combination of Anand-Venkadasamy and Chen are analogous because they are each related to container management. Anand teaches a method of container management and provisioning based on predicted container utilization based on past telemetry data. Venkadasamy teaches a method of container management including container scaling based on predicted resource utilization using regression analysis of telemetry data. Chen teaches a method of utilizing regression analysis with weighted features to predict resource utilization. ([0019], continuously improving the prediction of the impact of updated resource allocation and utilization, and continuously adjusting resources until the storage system reaches a desired performance with lowest resource allocation and/or highest resource utilization, etc.; and [0024], the self-tuning resource allocating system adjusts at least one weight to align a predicted performance of the processing device with an actual performance). 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 teachings of the combination of Anand- Venkadasamy would be modified with the regression analysis taught by Chen resulting in a system that manages container resources based on predicted resource utilization using regression analysis and feature weights. Therefore, it would have been obvious to combine the teachings of the combination of Anand-Venkadasamy and Chen.
As per claim 4, Venkadasamy teaches, wherein the adjusting comprises expanding the size of the resource available to the container ([0015], Estimated growth rates of applications with respect to one or more resources are then used to determine increases in resource allocations to the applications that support the growth rates).
As per claim 7, this is the “computer program product 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.
As per claim 8, Anand teaches, wherein the stored program instructions are stored in a computer readable storage device in a data processing system ([0010], computer program product can include a computer readable storage medium readable by one or more processing circuit and storing instructions for execution by one or more processor for performing a method), and wherein the stored program instructions are transferred over a network from a remote data processing system ([0026], Orchestrator 110, UE devices 120A-120Z and computing environments 140A-140Z can be in communication with one another via network 190. Network 190 can be a physical network and/or a virtual network).
As per claim 9, Anand teaches, wherein the stored program instructions are stored in a computer readable storage device in a server data processing system, and wherein the stored program instructions are downloaded in response to a request over a network to a remote data processing system for use in a computer readable storage device associated with the remote data processing system ([0153], Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network), further comprising:
program instructions to meter use of the program instructions associated with the request ([0149], Metering and Pricing 82 provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources s); and
program instructions to generate an invoice based on the metered use ([0149], Metering and Pricing 82 provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources).
As per claim 12, this claim is similar to claim 4 and is rejected for the same reasons.
As per claim 15, this is the “system 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.
As per claim 18, this claim is similar to claim 4 and is rejected for the same reasons.
Claims 2-3, 5-6, 10-11, 13-14, 16-17, and 19-20 rejected under 35 U.S.C. 103 as being unpatentable over the combination of Anand-Venkadasamy-Chen as applied to independent claims 1, 7, and 15 and in further view of Rafey et al (US 20210089361).
As per claim 2, the combination of Anand-Vekadasamy fails to specifically teach, wherein the set of features is specific to a role of the container.
However, Rafey teaches, wherein the identified set of features is specific to a role of the container ([0020], The container profile is used, along with historical resource utilization data for software container instances, to enable a container platform at runtime to dynamically regulate the allocation, de-allocation and throttling of resources by container instances in accordance with the importance of the software containers; and [0020], Machine learning algorithms may be used for determining the container profiles and generating resource management plans for different software container instances based at least in part on the functional factors).
The combination of Anand-Venkadasamy-Chen and Rafey are analogous because they are each related to container management. Anand teaches a method of container management and provisioning based on predicted container utilization based on past telemetry data. Venkadasamy teaches a method of container management including container scaling based on predicted resource utilization. Chen teaches a method of utilizing regression analysis with weighted features to predict resource utilization. Rafey teaches a method managing containers based on container profiles and predicted resource utilization. (Abstract, creating a resource management plan for the given software container utilizing one or more machine learning algorithms, the resource management plan comprising resource management metric thresholds determined based at least in part on historical resource utilization data for additional software containers having associated software container profiles similar to the given software container profile. The method further comprises executing the instance of the given software container on a software container platform, and managing resource utilization of the executing instance of the given software container based at least in part on the resource management plan; and sing container profile metrics and historical container resource utilization data, the container orchestration engine 316 is configured at runtime of the container instances 310 to predict an optimized resource management plan for each of the container instances 310. Predicting the optimized resource management plan, in some embodiments, utilizes one or more machine learning algorithms such as a KNN machine learning algorithm). 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 teachings of the combination of Anand-Venkadasamy-Chen would be modified with the container profiling mechanism taught by Rafey resulting in a system that manages container resources based on predicted resource utilization and profile information. Therefore, it would have been obvious to combine the teachings of Anand-Venkadasamy-Chen and Rafey.
As per claim 3, the combination of Anand-Vekadasamy-Chen fails to specifically teach, wherein the identified set of features is specific to a computer language in which the executing application is implemented.
However, Rafey teaches, wherein the identified set of features is specific to a computer language in which the executing application is implemented ([0048], a given software container profile for the given software container is generated based at least in part on rankings associated with the set of source code entities of the source code of the given software container. A given one of the rankings associated with a given one of the source code entities characterizes functional importance to an enterprise system. Functional importance to the enterprise system may be determined based at least in part on usage of the given source code entity and connectedness of the given source code entity).
The same motivation used in the rejection of claim 2 is applicable to the instant claim.
As per claim 5, the combination of Anand-Vekadasam-Chen fails to specifically teach, wherein the adjusting comprises reducing the size of the resource available to the container.
However, Rafey teaches, wherein the adjusting comprises reducing the size of the resource available to the container ([0019], Resource management in container platforms, including throttling of resources allocated to or utilized by software container instances, may be handled using quota systems, traffic-based scaling in and out, attributed-based throttling, etc. In effect, all these are technical factors that play a deciding role in how resources (e.g., compute resources, memory resources, storage resources, network resources, etc.) are allocated to different software container instance).
The same motivation used in the rejection of claim 2 is applicable to the instant claim.
As per claim 6, Rafey teaches, wherein the adjusting comprises instantiating a second container comprising a second instantiation of the executing application ([0020], generating resource management plans for different software container instances based at least in part on the functional factors; and [0035], container instance monitoring module 118 is also configured to execute the requested instance of the given software container on the container platform 102, and to manage resource utilization of the executing instance of the given software container based at least in part on the resource management plan for the given software container), the second container instantiated with second resource of the same size as the resource available to the container ([0035], resource management plan comprises a set of resource management metric thresholds determined based at least in part on historical resource utilization data for one or more additional software containers having associated software container profiles similar to the given software container profile).
The same motivation used in the rejection of claim 2 is applicable to the instant claim.
As per claim 10, this claim is similar to claim 2 and is rejected for the same reasons. The same motivation used in the rejection of claim 2 is applicable to the instant claim.
As per claim 11, this claim is similar to claim 3 and is rejected for the same reasons. The same motivation used in the rejection of claim 2 is applicable to the instant claim.
As per claim 13, this claim is similar to claim 5 and is rejected for the same reasons. The same motivation used in the rejection of claim 2 is applicable to the instant claim.
As per claim 14, this claim is similar to claim 6 and is rejected for the same reasons. The same motivation used in the rejection of claim 2 is applicable to the instant claim.
As per claim 16, this claim is similar to claim 2 and is rejected for the same reasons. The same motivation used in the rejection of claim 2 is applicable to the instant claim.
As per claim 17, this claim is similar to claim 3 and is rejected for the same reasons. The same motivation used in the rejection of claim 2 is applicable to the instant claim.
As per claim 19, this claim is similar to claim 5 and is rejected for the same reasons. The same motivation used in the rejection of claim 2 is applicable to the instant claim.
As per claim 20, this claim is similar to claim 6 and is rejected for the same reasons. The same motivation used in the rejection of claim 2 is applicable to the instant claim.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is as follows:
Ghergu et al. (US 11868812) Teaches predictive scaling of containers including metering and pricing:
Column 12, Lines 33-40, Resource provisioning 481 provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment 300. Metering and pricing 482 provide cost tracking as resources are utilized within the cloud computing environment 300, and billing or invoicing for consumption of these resources. In one example, these resources can include application software licenses; and
Tang et al. (US 10409642) Teaches resource monitoring and scaling based on predicted resource utilization:
Abstract, A first capacity for the first resource and a second capacity for the second resource is determined based at least in part on the at least one policy. The first resource and the second resource are caused to be scaled according to the first capacity and the second capacity respectively; and
Column 2, Line 66-Column 3, Line 8, techniques described and suggested in the present disclosure improve the field of computing, specifically the field of computer resource scaling, by analyzing historical data relating to resource utilization in order to determine utilization patterns that can be used to provide scaling policy recommendations and develop predictive scaling policies. Additionally, techniques described and suggested in the present disclosure improve the efficiency of computing services by synchronizing resources of different types to be scaled in tandem.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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