DETAILED ACTION
Status of Claims
This action is in reply to the communication filed on 11/13/2025.
Claims 1-3, 7-10, 13 and 19 have been amended.
Claims 1-20 are currently pending and have been examined.
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 11/13/2025 has been entered.
Response to Arguments
Applicant's arguments filed 10/09/2025 and entered 11/13/2025 with respect to the rejections under 35 USC § 101 have been fully considered and found persuasive in combination with Applicant’s amendments; the rejections under 35 USC § 101 have accordingly been withdrawn.
Applicant’s arguments filed 10/09/2025 and entered 11/13/2025 with respect to the rejections under 35 USC § 103 have been fully considered but are moot in view of the new grounds of rejection.
Claim Objections
Claims 9 and 10 are objected to because of the following informalities:
Claim 9 includes an incorrect element label as shown: a second label, the second label represents that the compute module is processing another task at a first execution duration level, and execution duration required by the another.
Claim 10 includes an incorrect element label as shown: a third label, the third label represents that the compute module is processing another task at a second execution duration level, and execution duration required the another
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 7-10, 19, and 20 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor, at the time the application was filed, had possession of the claimed invention.
Claim 7’s parent claim, claim 1, recites sending the second task to the target compute node for execution; and claim 7 recites subsequently sending the second task to another compute node in the plurality of compute nodes when a target compute module of the target compute node cannot execute the second task which is not supported by the written description of Applicant’s as-filed Specification (AppSpec). The nearest subject matter in AppSpec (pg. 20-23) describes making a number of conditional determinations to identify which (single) compute node to send the task for execution and then sending the task to the determined compute node.
AppSpec does not describe sending a task to one (target) node for execution and also sending it to another compute node when the target compute node cannot execute the second task as recited in claim 7.
Claim 19 recites essentially the same limitations, and has the same written description issues, as described above for claim 7.
Any claim listed in the rejection heading not explicitly listed in the body is rejected for being dependent upon a rejected claim.
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-3, 5-15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Reid et al. (US 8,881,142 B1) in view of Li et al. (“An Energy Efficient Resource Management Method in Virtualized Cloud Environment”, 2012).
Claims 1 and 13:
Reid discloses the limitations as shown in the following rejections:
A resource scheduling method, wherein the method comprises…by a scheduling node (server system/“logic 134” of resource environment) in a resource scheduling system (system 100)…wherein the resource scheduling system includes the scheduling node, the plurality of compute nodes (hosts), and a plurality of electronic devices (user systems/clients), and the scheduling node manages compute resources of the plurality of compute nodes requested by the plurality of electronic devices (see at least FIG. 1; col. 2, li. 24-62; col. 3, li. 17-39; col. 5, li. 55-63).
receiving, by the scheduling node, a first task (requested virtual machine (VM)/VM type) from the plurality of electronic devices (user systems/clients) wherein the first task belongs to a target execution duration level (short-term, long-term), wherein the target execution duration level represents a time length (expected lifetime) (see at least col. 5, li. 55 – col. 6, li. 13; col. 7, li. 26-37; col. 9, li. 30-67; col. 10, li. 20-30; FIG. 3:302-304), “server system 106 may receive via network 104a a request 126 from user system 102 for a virtual machine…request 126 may be for a particular type of virtual machine 128 to be instantiated on hosts 110…determine from request 126 whether the user has indicated an expected lifetime for the requested virtual machine” and disclosing the system determines an expected/probable lifetime for the requested VM, which is used to classify the VM as being short or long term (execution duration level)
sending, by the scheduling node based on [host status information and host selection logic, see below in view of regarding correspondence], the first task (instructions/commands to instantiate requested VM) to a target compute node (appropriate host) for execution (col. 9, li. 30-67; col. 12, li. 1-42; FIG. 3:306-310), host selection logic, using the lifetime and host status information, identifies the appropriate computing host to instantiate the VM including an embodiment selecting a host (target node) running VMs with similar lifetimes as a requested VM, e.g. “probable virtual machine lifetime for a requested virtual machine of request 126 may be utilized in order to determine an appropriate host 110 on which to instantiate the requested virtual machine…a host 110 having virtual machines with similar current lifetimes to the determined probable virtual machine lifetime may be selected for the instantiation of the requested virtual machine.”
receiving, by the scheduling node, a second task from the plurality of electronic devices, wherein the second task belongs to the same target execution duration level; and sending, by the scheduling node, the second task to the target compute node for execution (col. 5, li. 55 – col. 6, li. 13; col. 9, li. 30-67; col. 12, li. 1-42; FIG. 3), disclosing Reid receives and processes multiple requests 126. See mapping above regarding first task for further description including running multiple VMs with similar lifetimes (same target execution duration level) at the same host.
[claim 13] the scheduling node (server system) comprises at least one processor and a memory coupled to the at least one processor and storing programming instructions for execution by the at least one processor (col. 3 li. 58 – col. 4, li. 27).
As shown above, Reid discloses an appropriate host for running a requested VM is identified dynamically based on lifetimes of VMs running at the hosts determined from host status information and accordingly does not specifically disclose, prior to receiving a request, establishing correspondence between a plurality of execution duration levels and a plurality of compute nodes.
Li, however, discloses analogous methods for duration-based job/VM (task) scheduling where “[t]he main idea of runtime involved placement strategy is to aggregate VMs with similar runtime in a TIME-sub-cluster” (pg. 4, col. 1, last para.) and discloses establishing correspondence between a plurality of execution duration levels and a plurality of compute nodes (i.e. Time sub-clusters) in at least pg. 2-3, § III-B; pg. 4, col. 2, para. 1-3; and pg. 2, Fig. 1 disclosing “The data center is divided into several Time-sub-clusters to which jobs with similar runtime are assigned...Time-Sub-cluster Partition Manager aggregates VMs with similar runtime to a sub-cluster through dividing server pools into different runtime region (pg. 2-3, § III-B)...TIME-sub-cluster partition The data center is divided into several sub-clusters, each of which corresponds to one or more physical hosts. Further, the runtime of VMs in the same sub-cluster differs within δ, i.e., the width of each sub-cluster is δ” (pg. 4, col. 2).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Reid to pre-partition the nodes into sub-clusters corresponding to runtime ranges/regions as taught by Li because “aggregating VMs with similar runtime to sub-cluster can save more energy by reducing the runtime of the server and the idle power waste” (Li pg. 1, col. 1; pg. 7, § VII).
Claims 2 and 14:
The combination of Reid/Li discloses the limitations as shown in the rejections above. Reid further discloses:
receiving, by the scheduling node, a scheduling request for the first task, wherein the scheduling request comprises the target execution duration level (see at least col. 5, li. 64 – col. 6, li. 13; col. 8, li. 47-57; FIG. 3:302).
parsing, by the scheduling node, the scheduling request to obtain the target execution duration level (see at least col. 8, li. 47-57).
Claims 3 and 15:
The combination of Reid/Li discloses the limitations as shown in the rejections above. Reid further discloses determining, by the scheduling node, an execution duration level corresponding to execution duration of the first task (expected/probable VM lifetime), wherein the determined execution duration level (short/long term) is the target execution duration level (see at least col. 10, li. 20-30: “a predetermined lifetime limit may be configured in computing resources environment 112 to indicate what is considered a short-term lifetime. If the determined probable virtual machine lifetime is within the predetermined limit, it may be considered a short-term lifetime and therefore the requested virtual machine may be instantiated on the particular host 110. If, however, the determined probable virtual machine lifetime is not within the predetermined limit, it may be considered a long-term lifetime”).
Claims 5, 6, 17, and 18:
The combination of Reid/Li discloses the limitations as shown in the rejections above. Reid further discloses wherein the target execution duration level indicates to use a target compute module, and the target compute node has the target compute module (host compute resources, e.g. processor, memory, executing VMs with similar lifetime/duration)…wherein the target compute module is a compute module marked with a first label (in host status data), and the first label represents that the compute module executes another task at the target execution duration level (in host status data specifying running VM with similar lifetime) (see at least col. 6, li. 63 – col. 7, li. 25; col. 9, li. 30-67; FIG. 3:308), “access host status data 138 and determine lifetimes for each running virtual machine 128 on hosts 110. Computing resources environment 112 may then select a host 110 that has current virtual machines 128 with similar lifetimes to the determined probable VMlifetime” (col. 9, li. 50-55).
Examiner notes that hereafter the term “host” as recited in the prior art is construed as also implicitly referring to the computing resources (compute module) of the host (e.g. processor, memory, col. 4, li. 48 – col. 5, li. 35) and is mapped to either/both the recited compute node and its constituent compute module in the rejections below. This interpretation is consistent with the description provided in Applicant’s as-filed Specification1.
Claims 7, 8, 19, and 20:
The combination of Reid/Li discloses the limitations as shown in the rejections above. Reid further discloses sending the second task to another compute node in the plurality of compute nodes when target compute node cannot execute the second task (“a state in which no new virtual machines 128 may be instantiated on the host” (col. 7, li. 8-25)) including sending the second task to a first compute node, wherein the first compute node has a compute module that is not processing a task (sufficient available processing resources) (col. 10, li. 1-10; col. 7, li. 8-25). See also Li pg. 4, col. 2 which teaches the limitation under an alternative interpretation, disclosing that when the host(s) of a sub-cluster cannot accommodate a VM because they are full or all inactive, new hosts (first compute node has a compute module that is not processing a task) will be powered on to accommodate VMs.
Reid additionally discloses (col. 1, li. 57 – col. 2, li. 6) that a VM can be migrated from a host that cannot execute the VM because the host is about to be taken offline for maintenance.
Claims 9 and 10:
The combination of Reid/Li discloses the limitations as shown in the rejections above. Reid further discloses sending, by the scheduling node, the task to a second/third compute node wherein the second/third compute node has a compute module marked with a second/third label (indication host is running a long short/term VM in host status data), the second/third label represents that the compute module is processing another task at a first/second execution duration level, and execution duration required by the task at the first/second execution duration level is shorter/longer than execution duration required by the second task in at least the host selection embodiment described in col. 10, li. 64 – col. 11, li. 13 which restricts each host to only be processing a single long-term VM, and accordingly discloses [claim 9] instantiating (sending) a requested long-term VM (task) at a host processing another task at a first execution duration level, and execution duration required by the task at the first execution duration level is shorter than execution duration required by the task (long-term VM) and discloses [claim 10] instantiating (sending) a requested short-term VM (task) at a host processing another task at a second execution duration level, and execution duration required by the task at the second execution duration level is longer than execution duration required by the second task (short-term VM).
See also Li pg. 4, col. 2 which teaches the limitation under an alternative interpretation, disclosing that when the host(s) of the corresponding/target time-cluster no longer exist due to dynamic conditions, the algorithm first attempts to schedule the VM to a host/sub-cluster [claim 10] processing another task at a second execution duration level, and execution duration required by the task at the second execution duration level is longer than execution duration required by the second task, and if such host/cluster also does not exist, sends the job/VM to a host/sub-cluster [claim 9] processing another task at a first execution duration level, and execution duration required by the task at the first execution duration level is shorter than execution duration required by the task.
See also Reid additionally discloses (col. 1, li. 57 – col. 2, li. 6) that a VM can be migrated from a host that cannot execute the VM because the host is about to be taken offline for maintenance.
Claims 11 and 12:
The combination of Reid/Li discloses the limitations as shown in the rejections above. Reid further discloses marking, by the scheduling node, a target compute module of the target compute node with a first label (in host status data), wherein the first label represents that the target compute module executes a task at the target execution duration level…deleting, by the scheduling node, the first label of the target compute module if execution of the first task ends and the target compute module is not processing another task in at least col. 6, li. 65 – col. 7, li. 25, disclosing the system tracks information concerning the VMs executing on hosts in host status data including “host status data 138 may indicate for each host 110 every virtual machine 128 that is currently running on the host 110…host status data 138 may include an expected lifetime for each virtual machine 128 currently running on a host 110.” Since the information specifies “every virtual machine 128 that is currently running on the host”, maintaining the host status information implicitly includes deleting the information for VMs which complete execution and are no longer running on the host(s).
Claims 4 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Reid in view of Li in further view of Aladwani (“Impact of Tasks Classification and Virtual Machines Categorization on Tasks Scheduling Algorithms in Cloud Computing” (2017), included with IDS dated 06/27/2023).
Claims 4 and 16:
The combination of Reid/Li discloses the limitations as shown in the rejections above. Reid further discloses wherein the target execution duration level is one of [two] execution duration levels, and the [two] execution duration levels comprise long execution duration…and short execution duration, and wherein: the long execution duration is greater than or equal to a first threshold…and the short execution duration is less than or equal to the [first] threshold (see at least col. 10, li. 20-30: “a predetermined lifetime limit may be configured in computing resources environment 112 to indicate what is considered a short-term lifetime. If the determined probable virtual machine lifetime is within the predetermined limit, it may be considered a short-term lifetime and therefore the requested virtual machine may be instantiated on the particular host 110. If, however, the determined probable virtual machine lifetime is not within the predetermined limit, it may be considered a long-term lifetime”).
Li discloses creating a plurality of time regions for the sub-clusters defined by a parameter δ, but does not specifically disclose qualifying them as short, medium, long, etc. Accordingly, the combination of Reid/Li does not specifically disclose a third medium execution duration level between long-term and short-term.
However, it was known art of resource scheduling and allocation to use three duration categories when classifying tasks based on their length as shown by Aladwani who discloses (pg. 2, col. 2; pg. 3, col. 2) wherein the target execution duration level is one of three execution duration levels, and the three execution duration levels comprise long execution duration, medium execution duration, and short execution duration, and wherein: the long execution duration is greater than or equal to a first threshold; the medium execution duration is less than the first threshold and greater than a second threshold; and the short execution duration is less than or equal to the second threshold. Exemplary quotation “we classify tasks into three classes based on tasks’ length. Three classes are chosen in order to have small tasks together, medium tasks together and long tasks together” (pg. 2, col. 2).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Reid/Li to have a medium duration category as taught by Aladwani to facilitate greater precision when selecting hosts optimally configured to handle tasks/VMs of a particular duration/ lifetime category, facilitating improved performance (Aladwani pg. 7, § 6).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
“Exploiting Spatio-Temporal Tradeoffs for Energy-Aware MapReduce in the Cloud” discloses grouping jobs by duration during scheduling.
“Analysis of Task Assignment with Cycle Stealing under Central Queue” and “On Choosing a Task Assignment Policy for a Distributed Server System”, and US 6223205 B1 disclose methods of “Size Interval Task Assignment” (SITA) scheduling.
US 20190317788 A1 is directed to longevity based resource provisioning.
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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.
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.
/P. M./
Paul Mills
12/27/2025
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
1 “The compute node 302 is a device configured to provide a computing service, and may be an entity device such as a host or a server…The compute node 302 includes one or more compute modules, configured to provide a compute resource. The compute module may include…a compute resource such as a CPU and memory.” (AppSpec ¶0079)