Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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.
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.
Claim Rejections - 35 USC § 103
Claim(s) 1, 8, and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over KOCHURA (US PUBLICATION 20220027778) in view of “Migration Modeling and Learning Algorithms for Containers in Fog Computing” by Zhiqing Tang (TANG).
In regards to claim 1, KOCHURA teaches a system comprising: a processing device; and a memory device that includes instructions executable by the processing device for causing the processing device to perform operations comprising: determining that the energy consumption of the container meets or exceeds an energy consumption threshold; (P.0020) “Controller 110 may include a computing device, such as computing system 200 of FIG. 2 that includes a processor communicatively coupled to a memory that includes instructions that, when executed by the processor, causes controller 110 to execute one or more operations described below.” (P.0026) “controller 110 may monitor the usage of a central processing unit, memory usage, input/output usage, a number of times that software container 120 is accessed/modified by a user during runtime, or the like.” (P.0028) “Controller 110 may determine that one of runtime environments 130 matches software container 120 when a performance of software container 120 satisfies a threshold, and/or when a cost (e.g., a billable resource usage, such as a usage of memory or processing power) of software container 120 as executed within the assigned runtime environment 130 satisfies a threshold.” (P.0029) “controller 110 may determine that a processing usage and/or memory usage of software container 120 within runtime environment 130A spikes, such that a performance (and/or cost) fails a threshold. In response to this, controller 110 may analyze whether another of runtime environments 130 better matches software container 120, such that a performance (and/or cost) of runtime may satisfy the threshold when executed in this different runtime environment 130. If controller 110 determines that a different runtime environment runtime environment 130B will match the static and/or runtime parameters in this way, controller 110 may cause software container 120 to instead run in this different runtime environment 130B.” in response to determining that the energy consumption meets or exceeds the energy consumption threshold, executing a multi-objective optimization algorithm configured to identify a second node from the plurality of nodes usable to execute the container based at least in part on a current workload of each node of the plurality of nodes and the energy consumption of the container (P.0027) “Controller 110 then utilizes a second machine learning model to determine whether or not this monitored performance indicates that software container 120 as quantified by runtime parameters matches runtime environment 130A. This second machine learning model may or may not include or reflect any static parameters. In some examples, the second machine learning model may include some static parameters, such as a size of software container 120. In other examples, the second machine learning model may include all static parameters as well as runtime parameters, and by finding correlations using the performance of software container 120 in an already assigned (by the first machine learning model) runtime environment 130A, controller 110 may improve an ability to quickly identify whether or not runtime environment 130A matches software container 120, and/or whether another of runtime environments 130 may better match software container 120.” (P.0045) “If controller 110 determines that the model indicates that one (or both) of the parameters match the assigned runtime environment 130A, controller 110 may continue to run software container 120 in selected runtime environment 130A (310). Alternatively, if controller 110 determines that there is not a match as discussed herein, controller 110 may move software container 120 to a different runtime environment 130B that is determined to have an improved match with the parameters using the second model (312). Similarly, if controller 110 determines that there is not a match as discussed herein, but that the match score is better between software container 120 and the assigned runtime environment 130A than between other runtime environments 130, then controller 110 may determine to keep software container 120 in assigned runtime environment 130A until one or more improved runtime environments 130 is found, brought online, created, or the like.” and in response to identifying the second node, deploying the container at the second node. (P.0048) “controller 110 migrates software container 120 to this other runtime environment 130, and causes software container 120 to run in this different runtime environment 130”
However, KOCHURA doesn’t teach determining that the energy consumption estimate of the container meets or exceeds an energy consumption threshold.
TANG teaches determining that the energy consumption estimate of the container meets or exceeds an energy consumption threshold; (Pg. 715, Ex. (5)) “Power Consumption. The total power consumption ptotal is equivalent to the addition of each node’s power consumption. If Fi is switched off or set in sleep mode, its power consumption ptotali = 0 [13]. Otherwise, its power consumption is proportional to resource utilization as indicated in[23]”
PNG
media_image1.png
67
397
media_image1.png
Greyscale
(Pg. 718, Ex. (17)) “After selecting the migrated containers, we apply allocation policy to determine the destination node of each container…
PNG
media_image2.png
286
406
media_image2.png
Greyscale
”
Therefore, it would be obvious for one of ordinary skill in the art before the effective filing date to apply the teachings of Tangs known per-container energy estimation technique as one of the metrics of Kochuras controller monitors and compares against a threshold, and as one of the parameters Kochuras machine learning models use to identify better matched run time environment motivated by Tangs own stated purpose of reducing power consumption.
Claims 8 and 15 correspond to claim 1 in method and non-transitory computer readable medium format and therefore are rejected for the same reasons.
Claim(s) 2-3, 9-10, 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over KOCHURA (US PUBLICATION 20220027778) in view of “Migration Modeling and Learning Algorithms for Containers in Fog Computing” by Zhiqing Tang (TANG) and in further view of GATTA (US PUBLICATION 20150052373)
In regards to claim 2, KOCHURA and TANG teach the claim substantially but don’t teach in response to determining that the energy consumption estimate exceeds the energy consumption threshold, modifying at least one network protocol associated with the container to limit energy consumption by the container.
GATTA teaches a known algorithm that in response to determining that the energy consumption estimate exceeds the energy consumption threshold, modifying at least one network protocol associated with the container to limit energy consumption by the container. (P.0109, 0112-0113) “the keep alive interval 1302 may be calculated based on the server timeout interval of the endpoint 1306, the network timeout interval of intermediary devices 1308, and even both intervals. The keep alive interval 1302, for example, may be calculated by the keep alive manager module 128 to efficiently utilize resources of the computing device 102 in maintaining the notification channels.”; EN: wherein a device limits keep alive network communication based on the devices energy consumption; see also (P.0009; 0045, 0074-0080).
It would have been obvious to one of ordinary skill in the art before the effective filing date to apply the teachings of Gatta to the combination of Kochura and Tang in order to reduce the energy consumed in maintaining the network connections already disclosed by Tangs architecture.
In regards to claim 3, KOCHURA and TANG teach the claim substantially but don’t teach wherein modifying the at least one network protocol associated with the container comprises: modifying a transmission frequency of a keep-alive mechanism; and modifying a data transfer frequency.
GATTA teaches wherein modifying the at least one network protocol associated with the container comprises: modifying a transmission frequency of a keep-alive mechanism; and modifying a data transfer frequency. (P.0109) “the keep alive manager module 128 may determine that the network timeout interval is 15 seconds and the server timeout interval is 20 seconds. Therefore, the keep alive manager module 128 may wake the network interface device 112 at fifteen second intervals”
Same motivation as claim 2.
Claims 9-10, 16-17 correspond to claims 2 and 3 and are rejected for the same reasons stated above.
Claim(s) 4-5, 11-12, and 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over KOCHURA (US PUBLICATION 20220027778) in view of “Migration Modeling and Learning Algorithms for Containers in Fog Computing” by Zhiqing Tang (TANG) and in further view of MAGENHEIMER (US PUBLICATION 20080104587)
In regards to claim 4, KOCHURA and TANG teach the claims substantially but don’t teach wherein the multi-objective optimization algorithm is further configured to identify the second node from the plurality of nodes based on a respective predicted workload of each node of the plurality of nodes and a respective energy level of each node of the plurality of nodes.
MAGENHEIMER teaches wherein the multi-objective optimization algorithm is further configured to identify the second node from the plurality of nodes based on a respective predicted workload of each node of the plurality of nodes and a respective energy level of each node of the plurality of nodes. (P.0056) “the VM layout selector 144 searches (at 408) for a better layout that represents another placement of virtual machines on physical machines.” (P.0054) “when considering alternative layouts (which are trial layouts not yet implemented) to compare to the current layout, the parameters for the alternative layouts may have to be estimated (using an internal model provided with the VM layout selector 144), where the model can be generated based on historical information.”; Further note TANG pg. 718.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply the teachings of Magenheimer and Tang to Kochuras run time environment matching framework in order to inform the identification of a better matching environment with each candidate nodes predicted workload and energy level.
In regards to claim 5, KOCHURA and TANG teach the claims substantially but don’t teach in response to determining that the first energy level of the second node is below the energy level threshold, identifying a third node from the plurality of nodes with a second energy level exceeding the energy level threshold.
MAGENHEIMER teaches in response to determining that the first energy level of the second node is below the energy level threshold, identifying a third node from the plurality of nodes with a second energy level exceeding the energy level threshold (P.0032) “the migration engine of each of the other physical machines makes a determination of whether the physical machine has sufficient resource (CPU, I/O, memory) availability to accommodate the virtual machine(s). If migration of a virtual machine from the origination physical machine would cause an overload condition of any resource or of the overall physical machine, then that physical machine would send an indication that it is unable to accommodate any virtual machine.” (P.0043) “there are various different physical resources (e.g., CPU, memory, network interface, storage network, etc.), there are different loading criteria to consider. The different loading criteria thus include a loading criterion relating to the CPU usage, a loading criterion relating to memory usage, a loading criterion relating to network interface usage, a loading criterion relating to storage network usage, and any other loading criteria relating to usage of other resources.”
However MAGENHEIMER doesn’t teach detecting a first energy level of the second node; determining that the first energy level of the second node is below an energy level threshold; and in response to identifying the third node, deploying the container at the third node.
TANG teaches detecting a first energy level of the second node; determining that the first energy level of the second node is below an energy level threshold; and in response to identifying the third node, deploying the container at the third node. (Pg. 715, Ex. (5)) “Power Consumption. The total power consumption ptotal is equivalent to the addition of each node’s power consumption. If Fi is switched off or set in sleep mode, its power consumption ptotali = 0 [13]. Otherwise, its power consumption is proportional to resource utilization as indicated in[23]”
PNG
media_image1.png
67
397
media_image1.png
Greyscale
(Pg. 717, Section 3.2) “F is classified as under-utilization, normal-utilization, and over-utilization groups according to the under threshold thunder and over threshold thover.1) For under-utilization nodes, the purpose is to migrate all containers located in them to other nodes, without any over-utilization nodes addition. So that a lot of power consumption can be saved by powering off these nodes.” (Pg. 719,) “If no feasible nodes available, we power on one node with minimal migration cost. Moreover, if no other nodes in shut down mode, we randomly select a node as the destination.”
Therefore, it would be obvious for one of ordinary skill in the art before the effective filing date to apply the teachings of Magenheimer to Tangs node under utilization classification and fallback reselection mechanism in order to identify an alternate node whose available energy capacity exceeds the level needed to accommodate the container.
Claims 11-12, 18-19 correspond to claims 4-5 and are rejected for the same reasons stated above
Claim(s) 6-7, 13-14, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over KOCHURA (US PUBLICATION 20220027778) in view of “Migration Modeling and Learning Algorithms for Containers in Fog Computing” by Zhiqing Tang (TANG) and in further view of CHENCHEV (US PUBLICATION 20190235605)
In regards to claim 6, KOCHURA and TANG teach the claims substantially but don’t teach wherein the container is a first container, and wherein the operations further comprise: in response to determining that the energy consumption estimate of the container meets or exceeds the energy consumption threshold, analyzing historical energy profiles of each container of a plurality of containers, the plurality of containers comprising at least the first container and a second container, and the historical energy profiles being indicative of energy consumption of each container of the plurality of containers; and determining, based on the historical energy profiles, that energy consumption by the second container is less than energy consumption by the first container.
CHENCHEV teaches wherein the container is a first container, and wherein the operations further comprise: in response to determining that the energy consumption estimate of the container meets or exceeds the energy consumption threshold, analyzing historical energy profiles of each container of a plurality of containers, the plurality of containers comprising at least the first container and a second container, and the historical energy profiles being indicative of energy consumption of each container of the plurality of containers; and determining, based on the historical energy profiles, that energy consumption by the second container is less than energy consumption by the first container. (P.0049) “the power profile may be selected based on previous instantiations of containers using a particular container template. For example, embodiments may include functionality to monitor power consumption by containers. A determination may be made that well-behaved instances of containers instantiated using a particular container template are expected to have certain power consumption characteristics.” (P.0099) “information related to typical power by previously deployed container instances created based on the container template. For example, embodiments may store information related to the amount of power consumed by well-behaved instances of containers…” (P.0047) “he power profile can be selected based on other containers running on the host system 100. For example, if there is a relatively large number of other containers running on the host system 100, then the power profile for a container to be instantiated may be selected to have a lower power consumption threshold than if there were fewer other containers running on the host system 100. Alternatively or additionally, if other containers running on the host system 100 consume relatively large amounts of power, then a power profile may be selected with a lower power consumption threshold…”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply Chenchev’s historical per container power profile analysis to the Kochura and Tang combination in order to identify a lower energy consuming container as a migration candidate using historically observed, per-container power consumption data.
In regards to claim 7, KOCHURA and TANG teach the claims substantially but don’t teach wherein the operations further comprise: subsequent to deploying the first container at the second node, deploying the second container at the second node and transferring at least one workload of the first container to the second container.
CHENCHEV teaches wherein the operations further comprise: subsequent to deploying the first container at the second node, deploying the second container at the second node and transferring at least one workload of the first container to the second container. (P.0082) “ the power policy manager 124 can group containers into swarms and can manage power and performance for them with group policies. It can also identify virtual environments that may not be able to function appropriately with the current power profile of the host and can propose these virtual environments be migrated to another host with a more appropriate power profile.” (P.0063) “the power manager 120 and/or power manager 120′ can detect the situation and cause the host 108 to offload operations performed for the container 110 to a remote service. This may be implemented in an application-specific manner (e.g. a version of the app runs in the cloud and locally and is informed by power usage). There may be a distributed app framework that enables the app to run both locally and in the cloud and share data. In some embodiments, this may be implemented manually with a user notification for the user to switch applications. For example, an email application running locally would use a web browser to access the same email account as the cloud offload. Alternatively, some embodiments may implement this automatically in a fashion that is seamless or nearly seamless to a user. For example, an app may be configured to use a local backend or a remote backend. When a power consumption threshold is exceeded, then processing would automatically switch to the remote backend. The results of the offloaded operations may be accessible through a web browser, streamed to the container 110 or relayed to the container via network I/O”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply Chenchev’s power driven container/workload relocation mechanism to the combination of Kochura and Tang to deploy the identified lower energy consuming container at the destination node and transfer the higher energy consuming containers workload to it.
Claims 13-14 correspond to claims 6 and 7 and are rejected for the same reasons stated above.
Claim 20 corresponds to claims 6 and 7 and is rejected for the same reasons stated above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SELMAN MOHAMED ABDULLAHI whose telephone number is (571)272-8556. The examiner can normally be reached 7:30-5:00 (Fri alternating).
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, LEWIS BULLOCK can be reached at (571) 272-3759. 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.
/SELMAN MOHAMED ABDULLAHI/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights