RESOURCE SCHEDULING METHOD AND RELATED APPARATUS

DETAILED ACTION Status of Claims This action is in reply to the communication filed on 08/04/2026. Claims 1, 13, and 21 have been amended. Claims 1-19 and 21 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 08/04/2026 and the after-final amendments filed 07/14/2026, have been entered. Response to Arguments Applicant’s arguments filed 07/14/2026 with respect to the rejections under 35 USC § 103 have been fully considered but are not persuasive and/or moot as described below. On pg. 2 of the Remarks, Applicant essentially argues: “Applicant respectfully submits that these, as well as the other cited portions of Reid, merely refer to receiving a request for a particular type of virtual machine to be instantiated on hosts. See id. In contrast to the claims, Reid does not teach or suggest that the request…identifies computing power for performing the first task. Li has not been shown to, and does not, remedy at least this deficiency of Reid.” Regarding “identifies computing power for performing…”, Reid discloses at least “request 126 may indicate that a VM 128 is to be instantiated that has a particular computing and/or memory capacity” (col. 6). See also Li pg. 2, sect. III and pg. 3, col. 2 disclosing each Job is associated with a “resource capacity R. Applicant’s remaining arguments are moot in view of the new grounds of rejection. 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-19 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) in further view of Filiz et al. (US 11,392,422 B1). 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/configuration) from the plurality of electronic devices (user systems/clients), wherein the first task specifies [one or more applications] and identifies computing power (computing and/or memory capacity) for performing the first task (running the VM), 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) that the first task is executed [until ended] (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), disclosing the scheduling logic receives a request from user system to run a particular VM type/configuration wherein “request 126 may indicate a configuration or type of a particular VM…request 126 may indicate that a VM 128 is to be instantiated that runs a particular operating system and one or more particular applications, such as a web server…request 126 may indicate that a VM 128 is to be instantiated that has a particular computing and/or memory capacity” (col. 6) 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). See below in view of Li regarding obtain a task result. See below in view of Filiz regarding a program package for executing the first task. sending, by the scheduling node based on [host status information and host selection logic, see below in view of Li 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. Furthermore, Reid’s exemplary workloads (e.g. web server) are not discrete computations that obtain a task result when ended. 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.), wherein the type of workload of the jobs are MapReduce workloads (pg. 1, § I, para. 1; pg. 1, § II, para. 2; pg. 2, § III, para. 3; pg. 3, § IV-A, para. 1-3) which are bounded computations that process a set of input data to produce output data, thus the job’s runtime represents a time length (expected lifetime) that the first task is executed to obtain a task result. Li further 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). Additionally, Li discloses the job identifies computing power (resource capacity) for performing the first task "Each of VM type has the same resource capacity denoted as {R1…Rs}...The VMs assigned to each job are of the same type...The runtime T of a job can be estimated by a function of the VM resources allocated to it" (pg. 2, sect. III); "When a job Ji of data size DS arrives, administrator or applicant predefines the VM type Ri allocated to the job according to job type" (pg. 3, 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); and to extend Reid’s lifetime/runtime-aware scheduling to both ‘always on’ and bounded workloads as taught by Li as it represents the application of a known technique to improve similar workload environments in the same way (Li pg. 1, § II, para. 2; pg. 3, § IV-A, para. 1-3). Regarding the limitation reciting the first task specifies a program package for executing the first task, as noted above, Reid specifies an application for execution but the combination of Reid/Li does not specifically disclose specifies a program package for executing the first task. Filiz, however, discloses an analogous cloud scheduling system wherein user submit a request to execute a containerized application/pod (task) wherein “a containerized application (e.g., a user's application code, configurations, and dependencies packaged into a single object)” (col. 3, li. 25-27) and discloses the first task (containerized application/pod/task) specifies a program package (container image) for executing the first task and identifies computing power (resource requirements) for performing the first task in at least col. 3, li. 25-36; col. 4, li. 65 – col. 5, li. 55; col. 6, li. 12-19; col. 7, li. 44-55; col. 10, li. 1-43; col. 14, li. 45 – col. 15, li. 4). Exemplary quotations: “A container, as referred to herein, packages up code and all its dependencies so an application (also referred to as a task, pod, or cluster in various container platforms) can run quickly and reliably from one computing environment to another. A container image is a standalone, executable package of software that includes everything needed to run an application process: code, runtime, system tools, system libraries, and settings. Container images become containers at runtime…a task refers to a container, or multiple containers working together, running to execute the functionality of a software application or a particular component of that application. In some implementations, tasks can also include virtual machines, for example, virtual machines running within instance(s) hosting the container(s). A task definition can enable container images to be run in a hosted computing network to execute a task. A task definition can specify parameters including which container image to use with each container in the task…what quantities of different hardware resources should be allocated to the task or to specific containers” (col. 5). “a task definition specifying the information needed to instantiate the container(s) associated with the task. The information may include, for example, a set of resource parameters (e.g., a CPU specification, a memory specification, a network specification, and/or a hardware specification), a container image (e.g., an image or snapshot of a previously instantiated container or as an image specification that may be used to instantiate an image). An image specification and/or an image may be specified by the container orchestration service 130, the customer of the container orchestration service” (col. 10). 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 implement the applications/job workloads using container images as taught by Filiz because “Containers allow for easily running and managing applications across a cluster of servers or virtual machines. Applications packaged as containers can be deployed across a variety of environments, such as locally and within a compute service” (Filiz col. 1, li. 10-16; col. 5, li. 1-21). Claims 2 and 14: The combination of Reid/Li/Filiz 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/Filiz 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/Filiz 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, and 19: The combination of Reid/Li/Filiz 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/Filiz 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 another 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 current host to another host when the current host cannot execute the VM because it is about to be taken offline for maintenance. Claims 11 and 12: The combination of Reid/Li/Filiz 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 view of Filiz 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/Filiz 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/Filiz 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/Filiz 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). Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Reid in view of Li in view of Filiz in further view of Sun (“Large-scale Artificial Neural Network: MapReduce-based Deep Learning”, 2015). Claim 21: The combination of Reid/Li/Filiz discloses the limitations as shown in the rejections above. Li further discloses “MapReduce jobs running in the cloud process and analyze large-scale data like data mining applications and HPC” (pg. 3). Although deep learning model training task falls under the genus of high-performance computing (HPC), the combination of Reid/Li/Filiz do not specifically disclose wherein the first task includes a deep learning model training task. Sun, however, discloses it was known to implement deep learning model training tasks as MapReduce jobs (pg. 1, Abstract; pg. 2, sect. III). 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/Filiz jobs to perform deep learning model training functions because deep learning allows computers to produce complex behaviors for advanced tasks and is a rapidly expanding filed where computer resources are in high demand (Sun pg. 1, 7). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure: US 11385919 B1, US 10606660 B1, and US 20140068599 A1 each disclose platforms to executed requested workloads in the form software packages or bundles. 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 09/27/2026 /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)