DETAILED ACTION
Status of Claims
This action is in reply to the communication filed on 03/23/2026.
Claims 1, 8-10, and 13 have been amended.
Claim 20 has been cancelled.
Claim 21 has been added.
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 .
Response to Arguments
Applicant's arguments filed 3/23/2026 with respect to the rejections under 35 USC § 112(a) have been fully considered and found persuasive; the rejections under 35 USC § 112 have accordingly been withdrawn.
Applicant’s arguments filed 03/23/2026 with respect to the rejections under 35 USC § 103 have been fully considered but are not persuasive.
On pg. 8 of the Remarks, Applicant essentially argues:
“Applicant respectfully submits that these, as well as the other cited portions of Reid, refer to an expected lifetime of a virtual machine to be instantiated on hosts. See id ln contrast to the claims, Reid does not teach or suggest a time length that a task is executed on the hosts to obtain a task result. Li has not been shown to, and does not, remedy at least this deficiency of Reid.
Therefore, Applicant respectfully submits that the proposed combination of Reid and Li does not teach or suggest that "the target execution duration level represents a time length that the first task is executed to obtain a task result" as recited in amended claim 1.”
Examiner respectfully disagrees at least as it relates to Li. Li’s jobs are MapReduce workloads which are bounded computations that process a set of input data to produce output data; Li specifically contrasts them with ‘always on’ type tasks such as the web server tasks of Reid (“The cloud data center bears multiple workloads, such as “always-on” Web applications and distributed MapReduce applications. Opposite to always-on Web applications, MapReduce applications have a bounded runtime” (pg. 1). Thus, Li’s job runtime “represents a time length that the first task is executed to obtain a task result”. Examiner additionally refers to ¶0003 of Applicant’s Specification which provides MapReduce as an exemplary execution model, and “Statistical Workloads for Energy Efficient MapReduce”, citation [14] of reference Li, for background information regarding MapReduce task characteristics.
Examiner additionally notes the amended subject matter is arguably non-functional descriptive as it merely describes what the duration “represents” which does not affect any of the functions of the claimed system, see MPEP § 2111.05(III); Ex parte Nehls, (BPAI 2008) (precedential). In other words, the recited execution duration level that “represents a time length that the first task is executed to obtain a task result” are arguably functionally indistinguishable from Reid’s long-term/short-term lifetime levels that represent a time length the VM task is executed until it is ended.
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).
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) that the first task is executed [until ended, see below in view of Li regarding obtain a task result] (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 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).
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).
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, and 19:
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 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 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).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Reid in view of Li in further view of Ryu (“Extensible Video Processing Framework in Apache Hadoop”, 2013).
Claim 21:
The combination of Reid/Li 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 each of facial recognition task, a video decoding task, or a deep learning model training task fall under the genus of high-performance computing (HPC), the combination of Reid/Li do not specifically disclose wherein the first task includes a facial recognition task, a video decoding task, or a deep learning model training task.
Ryu, however, discloses it was known to implement facial recognition tasks and video decoding tasks as MapReduce jobs (pg. 305).
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 jobs to perform facial recognition task functions because "automatic face recognition can be an attractive application" (Ryu pg. 305).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
“Statistical Workloads for Energy Efficient MapReduce”, cited by reference Li relied upon in the rejections above, discloses background information regarding the characteristics of MapReduce workloads: “A brief overview of MapReduce is helpful at this point. At its core, MapReduce has two user-defined functions. The Map function takes in a key-value pair, and generates a set of intermediate key-value pairs. The Reduce function takes in all intermediate pairs associated with a particular key, and emits a final set of key-value pairs. Both the input pairs to Map and the output pairs of Reduce reside in an underlying distributed file system (DFS). The run-time system takes care of reading input from and writing output to the DFS…We can describe a single MapReduce job by several dimensions - the inter-job arrival time, the input, shuffle, and output data size, and the computation done for the map and reduce functions”.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry 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
04/24/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)
Prosecution Insights