DETAILED ACTION
Claims 1-20 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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/13/2026 has been entered.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 7-10, and 12-19 are rejected under 35 U.S.C. 103 as being unpatentable over Beaty et al. (US 2011/0131589 A1) in further view of Mahadik (US 12,164,965 B2).
Regarding claim 1, Beaty teaches the invention substantially as claimed including a method, comprising:
hosting a first application, that is a legacy application for direct execution by an operating system and having unknown resource requirements ([0007] A system for planning and transforming legacy devices into a virtualized environment includes a user profiling module configured to gather profiling data over time to represent legacy device activities and analyze the profiling data for system applications and user applications to determine usage frequency and resource requirements of at least one application. The profiling module including a program application configured in software for collecting profiling data and running on a legacy device. A benchmarking module is configured to capture user action events to simulate a user workload for the at least one application to determine how resource utilization and execution times scale from a legacy environment to a virtualized environment. A transformation planner is configured to employ scale factors from the benchmarking module to produce a plan to provision for legacy services in the virtualized environment, and a transformation executor is configured to execute the plan to provide services for the legacy system within the virtualized environment.), within a first [virtual] container of a container hosting environment ([0044] Benchmarking module 113 obtains accurate scaling factor information based on running a workload mix of the legacy desktops 104 on the target virtualized environment 102.);
acquiring a first peak resource usage for the first application ([0064] FIGS. 4E and 4F present resource usage due to a single application across all of the users. This information is used in case of provisioning a shared services environment (in which a given application, such as Microsoft Office.TM., is delivered to all of the users from a shared server).);
PNG
media_image1.png
366
720
media_image1.png
Greyscale
determining a first resource request for the first application based on the first peak resource usage ([0052]; [0058] The benchmarking involves replaying typical sets of actions within each application using the DESKBENCH.TM. tool 113. As a result, resource utilization data is gathered on a target virtualization server in relation to load intensity in a given application to obtain scaling factors. Aggregate usage of a resource (e.g., CPU) on a target virtualized platform is computed as, e.g., as a linear combination of application usage frequencies and the scaling factors.);
determining a first resource limit for the first application based on the first peak resource usage ([0059] Computing resource requirements for a virtualized system and desktop placement will now be described. To perform proper capacity planning for a desktop cloud 102, scaling factors are used for resource usage and then observed usage is appropriately scaled on legacy systems. These scaling factors are preferably computed by the transformation planner 115. Scaling factors for a given application a and resource r are defined as a ratio of amount of the resource used by an application while executing in the cloud 102 and amount of the resource needed when executing on a legacy desktop 104. The ratio is determined based on comparing resource usages in both environments when executing the same action within the application.; [0066] Accounting for all of these factors in an analytical model is a challenging task. Therefore, we take another approach and benchmark applications (e.g., key actions within those applications) on a target virtualized platform as well as on the legacy desktops. As a result, we can obtain reliable scaling factors for resource usage as well as sensitivity analysis to establish maximum capacities of servers.); and
redeploying [reconstituting] an entity in the [virtual] container hosting environment based on the first resource request and the first resource limit ([0043] The transformation process of moving legacy desktops 104 to a desktop cloud 102; [0051] These resource requirements include system configuration details also gathered by the UPROF.TM. agent 112, such as disk, memory and CPU characteristics to name a few. UPROF.TM. 112 provides the necessary profiling and analysis data of the legacy user desktops 104 to be able to make decisions on how best to reconstitute these desktops 104 in a desktop cloud instance or option (e.g., options 120, 130, 140).; [0060] After resource requirements have been established, virtual desktops on servers are placed in the cloud 102 by the transformation executor 117.).
Beaty teaches transforming legacy services into virtualized cloud services in virtual machines but Beaty does not explicitly teach hosting the application in a container of a container hosting environment and redeploying an entity in the container hosting environment based on the first resource request and the first resource limit.
However, Mahadik teaches hosting an application in a container, evaluate resource utilization with an initial configuration, determine a trigger for scaling and reconfiguration conditions and reconfigures the container based on monitored utilization data. Further Mahadik teaches hosting the application in a container of a container hosting environment (Fig. 1, Within container based computational system 100, Container 162, Application 1 172; Col. 8, lines 11-14: Note that the embodiment shown in FIG. 1 is non-limiting, and the set of containers 160 may include more or less than four containers. Each container may implement one or more applications) and
redeploying an entity in the container hosting environment based on the first resource request and the first resource limit (Col. 9, lines 27-32; Col. 11, lines 28-40; Col. 11, line 60 through Col. 12 line 2; Col. 1, line 64 through Col. 2, line 4: For example, the first set of containers may have been launched with different configurations, but has been reconfigured and/or rescaled with the first configuration since the initial launching of the first set of containers with the different configuration of the set of configurations.; Col. 5, lines 25-34: Once the set of containers is initially launched, the controller implements a control loop for the set of containers. The utilization data provides feedback for the control loop. More specifically, the container controller actively monitors utilization data for the set of containers and adaptively reconfigures (e.g., updates) the set of containers based on an analysis of the utilization data (e.g., the feedback of the control loop). When reconfiguring the set of containers, another configuration from the set of configurations may be selected via the selection algorithm.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Mahadik of utilizing virtualization containers to host applications, wherein the resource utilization is determined and used for redeploying applications into containers having optimal resources with the teachings of Beaty of analyzing legacy application execution in a virtual environment to determine how to allocate resources when transformed/migrated into a virtualized environment. The modification would have been motivated by the desire of implementing the resource allocation methods on known virtualized systems such as virtual machines in containers as it would yield predictable results of optimal resource allocation with proper capacity provisioning. See at least Beaty’s [0007] and Mahadik’s Background that states “Such virtualized resources may include virtual machines (VMs) and containers”
Regarding claim 2, Mahadik teaches wherein redeploying the entity based on the first resource request and the first resource limit comprises: modifying a first configuration associated with the entity (Col. 1, line 64 through Col. 2, line 4: For example, the first set of containers may have been launched with different configurations, but has been reconfigured and/or rescaled with the first configuration since the initial launching of the first set of containers with the different configuration of the set of configurations.; Col. 5, lines 25-34).
Regarding claim 3, Mahadik teaches wherein redeploying the entity based on the first resource request and the first resource limit comprises: redeploying at least one of the first container (Col. 5, lines 25-43 Once the set of containers is initially launched, the controller implements a control loop for the set of containers. The utilization data provides feedback for the control loop. More specifically, the container controller actively monitors utilization data for the set of containers and adaptively reconfigures (e.g., updates) the set of containers based on an analysis of the utilization data (e.g., the feedback of the control loop). When reconfiguring the set of containers, another configuration from the set of configurations may be selected via the selection algorithm. The updated configuration may be the same configuration or a different reconfiguration dependent on an analysis of the utilization data, a stochastic nature of the selection algorithm, and/or estimates for a reward metric corresponding to each configuration in the set of configurations. When the updated configuration is different than the current configuration, the allocation of the resources dedicated to the set of containers may be updated (e.g., a scale-up or a scale-down event may be triggered for the set of containers).), a first pod hosting the first container, or a namespace comprising the first container.
Regarding claim 4, Mahadik teaches comprising:
hosting a second application within a second container of the container hosting environment (Fig. 1 shows Container 2 162 with Application 2 164);
acquiring a second peak resource usage for the second application (Col. 2, lines 59-63: The utilization data may encode a time series of an actual number of processing units of the computing resources that are provided to the first set of containers when the first set of containers implements the application under the first workload; Col. 5, lines 15-20: The set of containers is employed to implement the application, and the application is executed under a temporally varying workload. Under the workload, temporally varying utilization data is generated that encodes the utilization of the resources allocated for the set of containers; Col. 6, lines 58-62: The utilization data encodes a fractional utilization of the allocated resources (e.g., a percentage of the allocated CPUs (as indicated by num_cpu) being utilized, as a function of time). When the current utilization exceeds the upper-utilization threshold);
determining a second resource request [selection] for the second application based on the second peak resource usage (Col. 9, lines 27-32: The MDP engine 216 is generally responsible for selecting a configuration (from set of configurations 220) when the container controller 210 is launching, rescaling, and/or reconfiguring the set of containers 230 via an MDP (e.g., a MAB decision process).; Col. 11, lines 28-40: For instance, a plurality of states may be defined for the set of containers 230 (e.g., states characterized by current and/or previous portions of the utilization data), and the set of actions of the MDP may correspond to the set of configurations 220. The selection of a configuration (e.g., an action to perform via the MDP) may be based on the set of containers' 230 current state, and possibly one or more previous states. The performance of an action (e.g., the reconfiguration of the set of containers) may transition the current state of the set of containers to another available state (e.g., an increase or decrease in the utilization of the allocated resources).);
determining a second resource limit for the second application based on the second peak resource usage (Col. 11, line 60 through Col. 12 line 2: Each configuration of the set of configurations 220 may additionally indicate a trigger condition for initiating a scale-up event (e.g., an upper-utilization threshold) for the set of containers 220, as well as a trigger condition for initiating a scale-down event (e.g., a lower-utilization threshold) for the set of containers 220. The upper-utilization threshold may be a high-water mark (hw) and may be indicated as scal_hi. The lower-threshold may be a low-water mark (lw) and may be indicated as scal_lo. In various embodiments, 0.0≤scal_lo<scal_hi≤1.0.); and
aggregating the first resource request and the second resource request to generate an aggregate resource request, wherein: redeploying the entity comprises redeploying the entity based on the aggregate resource request (Col. 8, line 60 through Col. 9, line 2: Accordingly, container controller 150 may implement a control loop that is similar to control loop 200 to efficiently and adaptively allocate resources for container-based computation. That is, the container controller 150 and the container controller 210 can manage container-based computation by configuring and reconfiguring a set of containers (e.g., set of containers 160 of FIG. 1 and/or set of containers 230) implementing one or more applications (e.g., application_1 162, application_2 164, application_3 176, and/or application_4 224) under one or more workloads.; Mahadik’s teachings of handling containers as a set reasonably teaches aggregating the requests).
Regarding claim 5, Mahadik teaches comprising: generating an aggregate resource limit based on the aggregate resource request, wherein: redeploying the entity comprises redeploying the entity based on the aggregate resource limit (Col. 1, line 64 through Col. 2, line 4: For example, the first set of containers may have been launched with different configurations, but has been reconfigured and/or rescaled with the first configuration since the initial launching of the first set of containers with the different configuration of the set of configurations.; Col. 5, lines 25-34: Once the set of containers is initially launched, the controller implements a control loop for the set of containers. The utilization data provides feedback for the control loop. More specifically, the container controller actively monitors utilization data for the set of containers and adaptively reconfigures (e.g., updates) the set of containers based on an analysis of the utilization data (e.g., the feedback of the control loop). When reconfiguring the set of containers, another configuration from the set of configurations may be selected via the selection algorithm.; Col. 8, line 60 through Col. 9, line 2: Accordingly, container controller 150 may implement a control loop that is similar to control loop 200 to efficiently and adaptively allocate resources for container-based computation. That is, the container controller 150 and the container controller 210 can manage container-based computation by configuring and reconfiguring a set of containers (e.g., set of containers 160 of FIG. 1 and/or set of containers 230) implementing one or more applications (e.g., application_1 162, application_2 164, application_3 176, and/or application_4 224) under one or more workloads.; Mahadik’s teachings of handling containers as a set reasonably teaches aggregating the requests).
Regarding claim 7, Mahadik teaches wherein generating the aggregate resource limit comprises:
determining a first difference between the first resource limit and the first resource request, determining a second difference between the second resource limit and the second resource request, applying a surge ratio to a sum of the first difference and the second difference to generate an adjustment factor, and adding a sum of the first resource request and the second resource request to the adjustment factor to generate the aggregate resource limit (Col. 5, lines 39-47; Col. 14 line 6-61;).
Regarding claim 8, Mahadik teaches wherein generating the aggregate resource limit comprises: limiting decreases in the aggregate resource limit to a predetermined percentage of a previous value of the aggregate resource limit (Col. 5, lines 39-47: When the updated configuration is different than the current configuration, the allocation of the resources dedicated to the set of containers may be updated (e.g., a scale-up or a scale-down event may be triggered for the set of containers). The container controller continues to monitor the utilization data, in view of the updated set of controllers, and continues to adapt the configuration of the set of containers based on the monitored utilization data and the MDP (e.g., a MAB decision process).; Col. 12, line 67 through Col. 13 line 7: Similarly, when the current utilization dips below the lower-utilization threshold (e.g., scal_lo.sub.i), the set of containers may be updated via a scale-down event. In some embodiments, a scaling event may include vertically scaling the set of containers (e.g., increasing or decreasing the number of CPU devices allocated for one or more containers of the set of containers).).
Regarding claim 9, Mahadik teaches wherein determining the first resource request comprises: determining a difference between the first peak resource usage and a previous value of the first resource request, applying a multiplier to the difference to determine an adjustment factor, and applying the adjustment factor to the previous value of the first resource request to determine the first resource request (Col. 6, lines 20-30: For instance, a plurality of states may be defined for the set of containers (e.g., states characterized by current and/or previous portions of the utilization data), and the set of actions of the MDP may correspond to the set of configurations. The selection of a configuration (e.g., an action to perform via the MDP) may be based on the set of containers' current state, and possibly one or more previous states. The performance of an action (e.g., the reconfiguration of the set of containers) may transition the current state of the set of containers to another available state (e.g., an increase or decrease in the utilization of the allocated resources).; Col. 7, lines 24-34: As noted above, a reward (e.g., a reward metric) may be associated with each configuration of the set of configurations. After sufficient utilization data has been acquired for a particular configuration, the container controller may update an estimate for the particular configuration's corresponding reward. In some embodiments, the estimate for a configuration's reward may be updated after a scaling event, or when the controller reconfigures the set of containers. Note that each scaling event may result in a reconfiguration event, because a scaling event results in the value of cpu_num being updated.).
Regarding claim 10, Mahadik teaches wherein applying the multiplier comprises: applying a first value of the multiplier responsive to the difference having a positive value and applying a second value of the multiplier greater than the first value responsive to the difference having a negative value (Col. 6, line 66 through Col. 7, line 5: In some embodiments, a scaling event may include vertically scaling the set of containers (e.g., increasing or decreasing the number of CPU devices allocated for one or more containers of the set of containers). In other embodiments, a scaling event may include horizontally scaling the set of containers (e.g., increasing or decreasing the number of containers included in the set of containers).).
Regarding claim 12, Mahadik teaches wherein redeploying the entity in the container hosting environment comprises: redeploying at least one of a container (Col. 5, lines 25-43 Once the set of containers is initially launched, the controller implements a control loop for the set of containers. The utilization data provides feedback for the control loop. More specifically, the container controller actively monitors utilization data for the set of containers and adaptively reconfigures (e.g., updates) the set of containers based on an analysis of the utilization data (e.g., the feedback of the control loop). When reconfiguring the set of containers, another configuration from the set of configurations may be selected via the selection algorithm. The updated configuration may be the same configuration or a different reconfiguration dependent on an analysis of the utilization data, a stochastic nature of the selection algorithm, and/or estimates for a reward metric corresponding to each configuration in the set of configurations. When the updated configuration is different than the current configuration, the allocation of the resources dedicated to the set of containers may be updated (e.g., a scale-up or a scale-down event may be triggered for the set of containers).), a pod, or a namespace.
Regarding claim 13, it is a system claim having similar limitations as claim 1 above. Therefore it is rejected under the same rationale above.
Regarding claim 14, it is a system claim having similar limitations as claim 4 above. Therefore it is rejected under the same rationale above.
Regarding claim 15, it is a system claim having similar limitations as claim 5 above. Therefore it is rejected under the same rationale above.
Regarding claim 16, it is a system claim having similar limitations as claim 7 above. Therefore it is rejected under the same rationale above.
Regarding claim 17, it is a media/product claim having similar limitations as claim 1 above. Therefore it is rejected under the same rationale above.
Regarding claim 18, it is a media/product claim having similar limitations as claim 4 above. Therefore it is rejected under the same rationale above.
Regarding claim 19, it is a media/product claim having similar limitations as claim 5 above. Therefore it is rejected under the same rationale above.
Claims 6, 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Beaty and Mahadik, in further view of Jain et al. (US 2023/0244392 A1).
Jain was cited in the previous Office Action.
Regarding claim 6, Mahadik teaches wherein generating the aggregate resource limit comprises: applying a surge multiplier to the aggregate resource request to generate the aggregate resource limit (Col. 1, lines 24-29: Thus, an application may be distributed across a set of containers. Furthermore, as the computational workload varies, the resources dedicated to a set of containers may be scaled down (e.g., in response to decreasing workloads) or scaled up (in response to increasing workloads).; Col. 3, lines 41-50: The analysis of the utilization data may include determining a scaling-event metric. Determining the scaling-event metric may be based on an accumulation, summation, integration, and/or time averaging of the time series of the number of scaling events for the first set of containers when the first set of containers implements the application under the first workload. The analysis of the utilization data may further include determining a value for the updated first reward metric based on the scaling-event metric.; Col. 5, lines 39-47: When the updated configuration is different than the current configuration, the allocation of the resources dedicated to the set of containers may be updated (e.g., a scale-up or a scale-down event may be triggered for the set of containers). The container controller continues to monitor the utilization data, in view of the updated set of controllers, and continues to adapt the configuration of the set of containers based on the monitored utilization data and the MDP (e.g., a MAB decision process).).
Beaty nor Mahadik does not explicitly teaches applying a surge multiplier to the request to generate the resource limit.
However, Jain teaches applying a surge multiplier to the request to generate the aggregate resource limit ([0069] When a pod experiences a surge in I/O usage, then there may not be enough resources left in the virtual machine for the pod to consume close to the pod’s limit. For example, a pod P1, which has request = 1 CPU core and limit = 10 CPUs, is hosted on virtual machine V1. The virtual machine V1 has only 3 free CPU cores. If there is a sudden I/O surge in P1, then P1 cannot use more than 4 CPU cores (1 core allocated to P1 + 3 of the free cores of the virtual machine). The virtual pod autoscaler will only recommend (1.15 * 4) = 4.6 cores as the target cores for P1.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jain of determining an additional allocation of resources based on the utilization reaching a threshold and increasing the amount of resources by a surge multiplier (e.g., 1.15). One of ordinary skill in the art would have been motivated by the desire of allocating an additional amount of resources without starving other applications.
Regarding claim 11, Jain teaches wherein determining the first resource limit for the first application comprises: applying a surge multiplier to the first peak resource usage to determine the first resource limit ([0069] When a pod experiences a surge in I/O usage, then there may not be enough resources left in the virtual machine for the pod to consume close to the pod’s limit. For example, a pod P1, which has request = 1 CPU core and limit = 10 CPUs, is hosted on virtual machine V1. The virtual machine V1 has only 3 free CPU cores. If there is a sudden I/O surge in P1, then P1 cannot use more than 4 CPU cores (1 core allocated to P1 + 3 of the free cores of the virtual machine). The virtual pod autoscaler will only recommend (1.15 * 4) = 4.6 cores as the target cores for P1.).
Regarding claim 20, Jain teaches wherein the container hosting environment is a cloud-scale hosting environment (Abstract; containers; [0108] cloud computing environment).
Response to Arguments
Applicant’s arguments, see pages 8-10, filed on 03/15/2026, with respect to the rejections of claims 1-5, 7-10, and 12-19 under Jin and Mahadik have been fully considered and are persuasive in further view of the amendments. Therefore, the rejection has been withdrawn. However, upon further search and consideration, a new grounds of rejection is made in view of Beaty.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
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 J 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.
/JORGE A CHU JOY-DAVILA/
Primary Examiner, Art Unit 2195
Prosecution Insights