METHOD AND SYSTEM FOR PRIORITY-BASED RESOURCE SCHEDULING WITH LOAD BALANCING

Application No. 18/361,688

• Filed: Jul 28, 2023
• Priority: Jul 30, 2022 — IN 202211043744
• Examiner: ALAM, SHIHAB
• Art Unit: 2197
• Tech Center: 2100 — Computer Architecture & Software
• Assignee: Waterlabs AI Technologies Private Limited
• OA Round: 2 (Final)

Office Action

DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed 05/12/2026.
Claims 1, 6-15 and 20 are amended.
Claims 1-20 are pending.
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in India on 07/30/2022. It is noted, however, that applicant has not filed a certified copy of the IN202211043744 application as required by 37 CFR 1.55.

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-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Bahramshahry et al. (US 20200026569 A1) (hereinafter Bahramshahry), in view of Rojas-Cessa et al. (WO 2009029833 A1) (hereinafter Cessa).
Regarding Claim 1 Bahramshahry teaches:
A method for priority-based resource scheduling with load balancing,
“A scheduler responsible for performing the scheduling processes and generally will seek to perform a variety of functions in addition to scheduling work, such as optimizing utilizing of resources through a load balancing process which thus permits multiple users to share system resources more effectively.”, (Bahramshahry: ¶006), “scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources based on the information requested from the local cache”, (Bahramshahry: ¶278), “rating the pending workload tasks based on one or more of a workload type, a specified priority, and current available compute capacity”, (Bahramshahry: ¶687).
the method comprising: receiving, by a processor associated with a resource scheduling system, from a plurality of client devices,
“a hosted computing environment 111 is communicably interfaced with a plurality of user client devices”, (Bahramshahry: ¶063), “customer organizations (104A, 104B, and 104C) which utilize web services and other service offerings as provided by the host organization 150 by communicably interfacing to the host organization 150 via network 195”, (Bahramshahry: ¶ 066), “executing a scheduler via the processor of the system, wherein the scheduler performs at least the following operations”, (Bahramshahry: ¶660).
one or more client requests to execute one or more tasks on one or more servers associated with one or more Virtual Machines,
“identifying, via a workload discovery engine, pending workload tasks to be scheduled for execution from one or more workload queues”, (Bahramshahry: ¶ 317), “scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources based on the information requested from the local cache”, (Bahramshahry: ¶278), “scheduling the selected workload task for execution with the computing resource and allocating the virtual resource exclusively to the computing resource for the duration of execution of the selected workload task”, (Bahramshahry: ¶678), “virtual machine 685 having mapped computing resources such as vCPU, RAM, a base image, a virtual image, IP space and network links, etc. The virtual machine 685 executes the workload tasks 641 in conjunction with memory 695”, (Bahramshahry: ¶221, Figure 6).
wherein the one or more client requests comprises request parameters;
“the workload discovery engine is to further identify a plurality of associated workload task requirements for each of the pending workload tasks”, (Bahramshahry: ¶290), “the scheduler is to evaluate a specified customer preference for executing workload tasks at a specified one of the plurality of computing resources as represented within the SLT for the respective workload task”, (Bahramshahry: ¶295), “in which the cloud-based service receives inputs from the client device at the user interface 626 to configure use of the scheduling service”, (Bahramshahry: ¶223).
determining, by the processor, usage-related information of each server associated with one or more VMs, upon receiving the one or more client requests;
“discovery engine 192 capable of discovering available compute resources by which to complete workloads and further capable to discover pending workloads awaiting assignment to compute resources”, (Bahramshahry: ¶073), “identifying, via a compute resource discovery engine, one or more computing resources available to execute workload tasks”, (Bahramshahry: ¶278), “the scheduler is to schedule the pending workload tasks based further on the associated workload task requirements and which of the plurality of computing resources available to execute workload tasks satisfies the associated workload task requirements”, (Bahramshahry: ¶290), “the scheduler is to evaluate pricing data represented within the local cache by the plurality of resource characteristics identified for each of the plurality of computing resources”, (Bahramshahry: ¶ 294), “identifying, via a workload discovery engine, pending workload tasks to be scheduled for execution”, (Bahramshahry: ¶317). Examiner Notes: because pending workload tasks arise from received client requests, this reinforces that resource determination occurs after receipt of the request.
prioritizing, by the processor, the received one or more client requests, based on the request parameters associated with the one or more client requests;
“based on how the scheduler allocates resources and prioritizes competing needs”, (Bahramshahry: ¶007), “the SLT is identified by the policy engine based further on a customer identifier or an organizational identifier or a service tier associated with each respective workload task”, (Bahramshahry: ¶292), “the SLT identified for each of the workload tasks defines a Quality of Service (QoS) expectation for each workload task; in which the scheduler does not guarantee or commit to meeting the QoS expectation for any individual workload task”, (Bahramshahry: ¶293), “and associate each pending workload task within the local cache with a priority marker, a QoS indicator, and/or the SLT based on the workload queue from which the task was retrieved”, (Bahramshahry: ¶0289), “rating the pending workload tasks based on one or more of a workload type, a specified priority, and current available compute capacity”, (Bahramshahry: ¶ 687).
assigning, by the processor, computing resources in the one or more servers to execute one or more tasks for the one or more client devices using a dynamic programming technique, based on the determined usage-related information and the prioritized one or more client requests;
“identifying, via a compute resource discovery engine, one or more computing resources available to execute workload tasks”, (Bahramshahry: ¶278), “scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources”, (Bahramshahry: ¶278), “schedule the pending workload tasks based further on the associated workload task requirements and which of the plurality of computing resources available to execute workload tasks satisfies the associated workload task requirements”, (Bahramshahry: ¶290), “scheduler will adjust one or more of re-try logic, priority, end-to-end execution time, preferred resource allocation range, and aging for each workload task”, (¶293), “dynamically allocate compute capacity (any of CPU, RAM, IP addresses, etc.) via which to perform a specific type of work according to needs”, (Bahramshahry ¶377), “Such adaptability is realized via a scheduler which determines independently where the resources should be allocated on an iteration by iteration basis, be it minute by minute, or some other time span for each iterative cycle (refer to the iterative cycle at FIG. 1C). Such a scheduler, by design, embraces the concept of eventual consistency, thus permitting a very decoupled solution”, (Bahramshahry: ¶380).
monitoring dynamically, by the processor, the usage-related information of the one or more servers;
“the scheduler 125 is enabled to utilize the local cache 140 to make decisions on resource allocation while leveraging the various services to monitor external resources”…” resource pools or third party clouds may go online and offline or may become available to perform work or be wholly consumed and therefore unavailable to perform work”…“There are additional factors which may change such as pricing and preference and performance metrics, each of which may likewise be monitored and updated by the compute resource”, (Bahramshahry: ¶077), “the workload discovery 135 component will then query that discovered compute cloud requesting all running tasks and completed tasks”, (Bahramshahry: ¶079), “Such adaptability is realized via a scheduler which determines independently where the resources should be allocated on an iteration by iteration basis, be it minute by minute, or some other time span for each iterative cycle (refer to the iterative cycle at FIG. 1C). Such a scheduler, by design, embraces the concept of eventual consistency, thus permitting a very decoupled solution”, (Bahramshahry: ¶380).
migrating, by the processor, from a first server to a second server of the one or more servers, the one or more tasks using at least one of a round-robin technique and graph theory technique, based on the monitored usage-related information,
“even when the service outage has ended or in the instance of the external service dependency having since been restored, the scheduling service may nevertheless migrate the workload execution to the different cloud to avoid repeating the same problem”, (Bahramshahry: ¶644), “The capacity round implements a round-robin resource allocation which singularly focuses on available capacity”… “If resources are available to allocation another instance of a pending task, then the round-robin capacity round process simply allocates that instance”, (Bahramshahry: ¶110), “The scheduler's 125 planning 127 operation then proceeds to specifically delineate which task will be performed by which compute cloud from the list of selected workload tasks”… “a first priority 1 workload task may be sent to a first third party cloud 199 with other priority 2 tasks being sent to different third-party compute clouds”, (Bahramshahry: ¶126), “query various computing clouds to check whether they are accessible and available and what workload tasks they are presently executing or have completed, with such auxiliary services then updating the local cache”, (Bahramshahry: ¶102), “The scheduler 125 then iterates through as many rounds as required to either exhaust all available resources or exhaust all produced tasks”, (Bahramshahry: 110), “identifying” … “a plurality of computing resources currently executing scheduled workload tasks”, (Bahramshahry: ¶349).
wherein the first server is executing the one or more tasks for the one or more client devices;
“a hosted computing environment 111 is communicably interfaced with a plurality of user client devices 106A-C (e.g., such as mobile devices, smart phones, tablets, PCs, etc.)”, (Bahramshahry: ¶063), “to schedule at least a portion of the plurality of workload tasks 640 for execution via the one or more computing resources 628”, (Bahramshahry: ¶224), “identifies, via a compute resource discovery engine, a plurality of computing resources currently executing scheduled workload tasks”, (Bahramshahry: ¶340).
and initiating, by the processor, the one or more tasks on the second server, in response to migrating the one or more tasks,
“scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources based on the information requested from the local cache”, (Bahramshahry: ¶278), “The scheduler's 125 planning 127 operation then proceeds to specifically delineate which task will be performed by which compute cloud from the list of selected workload tasks”, (Bahramshahry: ¶126), “scheduling one of the pending workload tasks into capacity within the plurality of computing resources freed up by the terminated workload task”, (Bahramshahry: ¶346), “scheduling the workload tasks potentially affected by the failure condition of the external service for a repeated execution on the plurality of computing resources”, (Bahramshahry: ¶712), “scheduling the multiple workload copies for execution on different computing resources”, (Bahramshahry: ¶687), “even when the service outage has ended or in the instance of the external service dependency having since been restored, the scheduling service may nevertheless migrate the workload execution to the different cloud to avoid repeating the same problem”, (Bahramshahry: ¶644).
wherein initiating the one or more tasks on the second server is to balance a load for resource utilization of the first server and the second server.
“such as optimizing utilizing of resources through a load balancing process”, (Bahramshahry: ¶006), “the planner 127 may be utilized to allocate resource for the most efficient utilization or for best performance”, (Bahramshahry: ¶114), “the capacity round implements a round-robin resource allocation which singularly focuses on available capacity”, (Bahramshahry: ¶110), “first third party cloud 199 with other priority 2 tasks being sent to different third-party compute clouds”, (Bahramshahry: ¶126), “the scheduler 125 then iterates through as many rounds as required to either exhaust all available resources or exhaust all produced tasks”, (Bahramshahry: ¶110), “a scheduler 1242 to schedule one of the pending workload tasks 1239 into capacity within the plurality of computing resources 1240 freed up by the terminated workload task 1241”, (Bahramshahry: ¶319).
Further regarding Claim 1, Bahramshahry fails to teach:
migrating, by the processor, from a first server to a second server of the one or more servers, the one or more tasks using at least one of a round-robin technique and graph theory technique, based on the monitored usage-related information,
However, Cessa teaches: “In one embodiment, a graph coloring theory can be used to facilitate a measurement- task scheduling algorithm for network measurement system 100”, (Cessa: ¶023), “This problem can be described as a vertex coloring problem. For a conflict graph G(V,E) with vertices V = V(G), each vertex can be assigned a color out of k (e.g., integers 1, ..., k) colors such that no two adjacent vertices have the same color”… “the color set to be used in the conflict graph can represent a total number of time slots in a measurement cycle”, (Cessa: ¶029).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine “the graph theory comprises K-colour set problem technique which is used for task scheduling” of Cessa with the methods and systems of Bahramshahry in order to schedule tasks by assigning colors to items so conflicting items don’t get the same color and loads are spread as evenly as possible. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of resolving “measurement contention and to provide efficient task processing”, (Cessa: ¶023).

Regarding Claim 2 Bahramshahry teaches:
the request parameters comprise at least one of a demand comprising several tasks, a timeline, a pricing category, and a Service Level Agreement (SLA).
“the produce 126 phase prepares a comprehensive list of all pending work for a single workload type”, (Bahramshahry: ¶109), “not all tasks will be selected and planned for execution, thus causing them to age in terms of time since submission as well as possibly increase in priority for subsequent scheduling rounds”, (Bahramshahry: ¶127), “There are additional factors which may change such as pricing and preference and performance metrics”, (Bahramshahry: ¶077), “Other considerations may likewise be employed, such as the lowest cost resources or the most preferred among two or more resources from competing clouds”, (Bahramshahry: ¶114), “the producer 126 additionally specifies the importance or priority for every task created according to the workload type's SLT or required QoS”, (Bahramshahry: ¶109).

Regarding Claim 3 Bahramshahry teaches:
the usage-related information comprises at least one of an active time, a running time, and a load level.
“query various computing clouds to check whether they are accessible and available and what workload tasks they are presently executing or have completed”, (Bahramshahry: ¶102), “the capacity round implements a round-robin resource allocation which singularly focuses on available capacity”, (Bahramshahry: ¶110), “not all tasks will be selected and planned for execution, thus causing them to age in terms of time since submission as well as possibly increase in priority for subsequent scheduling rounds”, (Bahramshahry: ¶127), “which causes the workload, while executing, to take much longer to execute than normal due to the test failures”, (Bahramshahry: ¶607), “based further on execution of the workload tasks overlapping in time with a time frame associated with the failure condition”, (Bahramshahry: ¶711), “allocating the virtual resource exclusively to the computing resource for the duration of execution of the selected workload task”, (Bahramshahry: ¶677).
Regarding Claim 4 Bahramshahry fails to teach:
the graph theory comprises K-colour set problem technique which is used for task scheduling.
However, Cessa teaches: “In one embodiment, a graph coloring theory can be used to facilitate a measurement- task scheduling algorithm for network measurement system 100”, (Cessa: ¶023), “This problem can be described as a vertex coloring problem. For a conflict graph G(V,E) with vertices V = V(G), each vertex can be assigned a color out of k (e.g., integers 1, ..., k) colors such that no two adjacent vertices have the same color”… “the color set to be used in the conflict graph can represent a total number of time slots in a measurement cycle”, (Cessa: ¶029).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine “the graph theory comprises K-colour set problem technique which is used for task scheduling” of Cessa with the methods and systems of Bahramshahry in order to schedule tasks by assigning colors to items so conflicting items don’t get the same color and loads are spread as evenly as possible. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of resolving “measurement contention and to provide efficient task processing”, (Cessa: ¶023).

Regarding Claim 5 Bahramshahry teaches:
the round-robin technique is used for time-based server utilization, is based on a round-robin time scheduler report provided by the round-robin technique
“The capacity round implements a round-robin resource allocation which singularly focuses on available capacity”… “the scheduler 125 then iterates through as many rounds as required to either exhaust all available resources or exhaust all produced tasks”, (Bahramshahry: ¶110), “For a next capacity round, the scheduler then proceeds to calculate the next capacity round by taking into account the recently planned tasks at phase 127 and then the scheduling cycle is optionally finalized 131. A subsequent analyze 132 phase then applies post-scheduling analysis to check any decisions made during the scheduler's allocation rounds”, (Bahramshahry: ¶108). Examiner notes: the scheduler report is being interpreted as which tasks were allocated, how much capacity was consumed, what capacity remains available, and which tasks were deferred to later rounds.

Regarding Claim 6 Bahramshahry teaches:
the round-robin technique and the dynamic programming technique is used to prioritize Service Level Agreement (SLA) requirements of the one or more client devices.
“The capacity round implements a round-robin resource allocation”, (Bahramshahry: ¶110), “the producer 126 additionally specifies the importance or priority for every task created according to the workload type's SLT or required QoS”, (Bahramshahry: ¶109), “calculate an allocation route based on the service level targets and capacity that is known to be available”, (Bahramshahry: ¶124), “scheduling the pending workload tasks to execute via the one or more computing resources in compliance with the selected SLT specified for each of the pending workload tasks”, (Bahramshahry: ¶695).
Regarding Claim 7, Bahramshahry teaches:
A resource scheduling system for priority-based resource scheduling with load balancing,
“A scheduler responsible for performing the scheduling processes and generally will seek to perform a variety of functions in addition to scheduling work, such as optimizing utilizing of resources through a load balancing process which thus permits multiple users to share system resources more effectively.”, (Bahramshahry: ¶006), “scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources based on the information requested from the local cache”, (Bahramshahry: ¶278), “rating the pending workload tasks based on one or more of a workload type, a specified priority, and current available compute capacity”, (Bahramshahry: ¶687).
the method comprising: a processor; a memory coupled to the processor, wherein the memory comprises processor-executable instructions,
“a processor and a memory to execute instructions at the system”, (Bahramshahry: Abstract), “executing a scheduler via the processor of the system”, (Bahramshahry: ¶660), “supported by a processor and a memory to execute such functionality”, (Bahramshahry: ¶221).
which on execution causes the processor to: receive, from a plurality of client devices,
“a hosted computing environment 111 is communicably interfaced with a plurality of user client devices”, (Bahramshahry: ¶063), “customer organizations (104A, 104B, and 104C) which utilize web services and other service offerings as provided by the host organization 150 by communicably interfacing to the host organization 150 via network 195”, (Bahramshahry: ¶ 066), “executing a scheduler via the processor of the system, wherein the scheduler performs at least the following operations”, (Bahramshahry: ¶660).
one or more client requests to execute one or more tasks on one or more servers associated with one or more Virtual Machines (VMs),
“identifying, via a workload discovery engine, pending workload tasks to be scheduled for execution from one or more workload queues”, (Bahramshahry: ¶ 317), “scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources based on the information requested from the local cache”, (Bahramshahry: ¶278), “scheduling the selected workload task for execution with the computing resource and allocating the virtual resource exclusively to the computing resource for the duration of execution of the selected workload task”, (Bahramshahry: ¶678), “virtual machine 685 having mapped computing resources such as vCPU, RAM, a base image, a virtual image, IP space and network links, etc. The virtual machine 685 executes the workload tasks 641 in conjunction with memory 695”, (Bahramshahry: ¶221, Figure 6).
wherein the one or more client requests comprises request parameters;
“the workload discovery engine is to further identify a plurality of associated workload task requirements for each of the pending workload tasks”, (Bahramshahry: ¶290), “the scheduler is to evaluate a specified customer preference for executing workload tasks at a specified one of the plurality of computing resources as represented within the SLT for the respective workload task”, (Bahramshahry: ¶295), “in which the cloud-based service receives inputs from the client device at the user interface 626 to configure use of the scheduling service”, (Bahramshahry: ¶223).
determine usage-related information of each server associated with one or more VMs, upon receiving the one or more client requests;
“discovery engine 192 capable of discovering available compute resources by which to complete workloads and further capable to discover pending workloads awaiting assignment to compute resources”, (Bahramshahry: ¶073), “identifying, via a compute resource discovery engine, one or more computing resources available to execute workload tasks”, (Bahramshahry: ¶278), “the scheduler is to schedule the pending workload tasks based further on the associated workload task requirements and which of the plurality of computing resources available to execute workload tasks satisfies the associated workload task requirements”, (Bahramshahry: ¶290), “the scheduler is to evaluate pricing data represented within the local cache by the plurality of resource characteristics identified for each of the plurality of computing resources”, (Bahramshahry: ¶ 294), “identifying, via a workload discovery engine, pending workload tasks to be scheduled for execution”, (Bahramshahry: ¶317). Examiner Notes: because pending workload tasks arise from received client requests, this reinforces that resource determination occurs after receipt of the request.
prioritize the received one or more client requests, based on the request parameters associated with the one or more client requests;
“based on how the scheduler allocates resources and prioritizes competing needs”, (Bahramshahry: ¶007), “the SLT is identified by the policy engine based further on a customer identifier or an organizational identifier or a service tier associated with each respective workload task”, (Bahramshahry: ¶292), “the SLT identified for each of the workload tasks defines a Quality of Service (QoS) expectation for each workload task; in which the scheduler does not guarantee or commit to meeting the QoS expectation for any individual workload task”, (Bahramshahry: ¶293), “and associate each pending workload task within the local cache with a priority marker, a QoS indicator, and/or the SLT based on the workload queue from which the task was retrieved”, (Bahramshahry: ¶0289), “rating the pending workload tasks based on one or more of a workload type, a specified priority, and current available compute capacity”, (Bahramshahry: ¶ 687).
assign computing resources in the one or more servers to execute one or more tasks for the one or more client devices using a dynamic programming technique, based on the determined usage-related information and the prioritized one or more client requests;
“identifying, via a compute resource discovery engine, one or more computing resources available to execute workload tasks”, (Bahramshahry: ¶278), “scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources”, (Bahramshahry: ¶278), “schedule the pending workload tasks based further on the associated workload task requirements and which of the plurality of computing resources available to execute workload tasks satisfies the associated workload task requirements”, (Bahramshahry: ¶290), “scheduler will adjust one or more of re-try logic, priority, end-to-end execution time, preferred resource allocation range, and aging for each workload task”, (¶293), “dynamically allocate compute capacity (any of CPU, RAM, IP addresses, etc.) via which to perform a specific type of work according to needs”, (Bahramshahry ¶377), “Such adaptability is realized via a scheduler which determines independently where the resources should be allocated on an iteration by iteration basis, be it minute by minute, or some other time span for each iterative cycle (refer to the iterative cycle at FIG. 1C). Such a scheduler, by design, embraces the concept of eventual consistency, thus permitting a very decoupled solution”, (Bahramshahry: ¶380).
monitor dynamically, the usage-related information of the one or more servers;
“the scheduler 125 is enabled to utilize the local cache 140 to make decisions on resource allocation while leveraging the various services to monitor external resources”…” resource pools or third party clouds may go online and offline or may become available to perform work or be wholly consumed and therefore unavailable to perform work”…“There are additional factors which may change such as pricing and preference and performance metrics, each of which may likewise be monitored and updated by the compute resource”, (Bahramshahry: ¶077), “the workload discovery 135 component will then query that discovered compute cloud requesting all running tasks and completed tasks”, (Bahramshahry: ¶079), “Such adaptability is realized via a scheduler which determines independently where the resources should be allocated on an iteration by iteration basis, be it minute by minute, or some other time span for each iterative cycle (refer to the iterative cycle at FIG. 1C). Such a scheduler, by design, embraces the concept of eventual consistency, thus permitting a very decoupled solution”, (Bahramshahry: ¶380).
migrate from a first server to a second server of the one or more servers, the one or more tasks using at least one of a round-robin technique and graph theory technique, based on the monitored usage-related information,
“even when the service outage has ended or in the instance of the external service dependency having since been restored, the scheduling service may nevertheless migrate the workload execution to the different cloud to avoid repeating the same problem”, (Bahramshahry: ¶644), “The capacity round implements a round-robin resource allocation which singularly focuses on available capacity”… “If resources are available to allocation another instance of a pending task, then the round-robin capacity round process simply allocates that instance”, (Bahramshahry: ¶110), “The scheduler's 125 planning 127 operation then proceeds to specifically delineate which task will be performed by which compute cloud from the list of selected workload tasks”… “a first priority 1 workload task may be sent to a first third party cloud 199 with other priority 2 tasks being sent to different third-party compute clouds”, (Bahramshahry: ¶126), “query various computing clouds to check whether they are accessible and available and what workload tasks they are presently executing or have completed, with such auxiliary services then updating the local cache”, (Bahramshahry: ¶102), “The scheduler 125 then iterates through as many rounds as required to either exhaust all available resources or exhaust all produced tasks”, (Bahramshahry: 110), “identifying” … “a plurality of computing resources currently executing scheduled workload tasks”, (Bahramshahry: ¶349).
wherein the first server is executing the one or more tasks for the one or more client devices;
“a hosted computing environment 111 is communicably interfaced with a plurality of user client devices 106A-C (e.g., such as mobile devices, smart phones, tablets, PCs, etc.)”, (Bahramshahry: ¶063), “to schedule at least a portion of the plurality of workload tasks 640 for execution via the one or more computing resources 628”, (Bahramshahry: ¶224), “identifies, via a compute resource discovery engine, a plurality of computing resources currently executing scheduled workload tasks”, (Bahramshahry: ¶340).
and initiate the one or more tasks on the second server, in response to migrating the one or more tasks,
“scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources based on the information requested from the local cache”, (Bahramshahry: ¶278), “The scheduler's 125 planning 127 operation then proceeds to specifically delineate which task will be performed by which compute cloud from the list of selected workload tasks”, (Bahramshahry: ¶126), “scheduling one of the pending workload tasks into capacity within the plurality of computing resources freed up by the terminated workload task”, (Bahramshahry: ¶346), “scheduling the workload tasks potentially affected by the failure condition of the external service for a repeated execution on the plurality of computing resources”, (Bahramshahry: ¶712), “scheduling the multiple workload copies for execution on different computing resources”, (Bahramshahry: ¶687), “even when the service outage has ended or in the instance of the external service dependency having since been restored, the scheduling service may nevertheless migrate the workload execution to the different cloud to avoid repeating the same problem”, (Bahramshahry: ¶644).
wherein initiating the one or more tasks on the second server is to balance a load for resource utilization of the first server and the second server.
“such as optimizing utilizing of resources through a load balancing process”, (Bahramshahry: ¶006), “the planner 127 may be utilized to allocate resource for the most efficient utilization or for best performance”, (Bahramshahry: ¶114), “the capacity round implements a round-robin resource allocation which singularly focuses on available capacity”, (Bahramshahry: ¶110), “first third party cloud 199 with other priority 2 tasks being sent to different third-party compute clouds”, (Bahramshahry: ¶126), “the scheduler 125 then iterates through as many rounds as required to either exhaust all available resources or exhaust all produced tasks”, (Bahramshahry: ¶110), “a scheduler 1242 to schedule one of the pending workload tasks 1239 into capacity within the plurality of computing resources 1240 freed up by the terminated workload task 1241”, (Bahramshahry: ¶319).
Further regarding Claim 7, Bahramshahry fails to teach:
migrate from a first server to a second server of the one or more servers, the one or more tasks using at least one of a round-robin technique and graph theory technique, based on the monitored usage-related information,
However, Cessa teaches: “In one embodiment, a graph coloring theory can be used to facilitate a measurement- task scheduling algorithm for network measurement system 100”, (Cessa: ¶023), “This problem can be described as a vertex coloring problem. For a conflict graph G(V,E) with vertices V = V(G), each vertex can be assigned a color out of k (e.g., integers 1, ..., k) colors such that no two adjacent vertices have the same color”… “the color set to be used in the conflict graph can represent a total number of time slots in a measurement cycle”, (Cessa: ¶029).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine “the graph theory comprises K-colour set problem technique which is used for task scheduling” of Cessa with the methods and systems of Bahramshahry in order to schedule tasks by assigning colors to items so conflicting items don’t get the same color and loads are spread as evenly as possible. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of resolving “measurement contention and to provide efficient task processing”, (Cessa: ¶023).
Regarding Claim 8, Bahramshahry teaches:
the request parameters comprise at least one of a demand comprising several tasks, a timeline, a pricing category, and a Service Level Agreement (SLA).
“the produce 126 phase prepares a comprehensive list of all pending work for a single workload type”, (Bahramshahry: ¶109), “not all tasks will be selected and planned for execution, thus causing them to age in terms of time since submission as well as possibly increase in priority for subsequent scheduling rounds”, (Bahramshahry: ¶127), “There are additional factors which may change such as pricing and preference and performance metrics”, (Bahramshahry: ¶077), “Other considerations may likewise be employed, such as the lowest cost resources or the most preferred among two or more resources from competing clouds”, (Bahramshahry: ¶114), “the producer 126 additionally specifies the importance or priority for every task created according to the workload type's SLT or required QoS”, (Bahramshahry: ¶109).
Regarding Claim 9, Bahramshahry teaches:
the usage-related information comprises at least one of an active time, a running time, and a load level.
“query various computing clouds to check whether they are accessible and available and what workload tasks they are presently executing or have completed”, (Bahramshahry: ¶102), “the capacity round implements a round-robin resource allocation which singularly focuses on available capacity”, (Bahramshahry: ¶110), “not all tasks will be selected and planned for execution, thus causing them to age in terms of time since submission as well as possibly increase in priority for subsequent scheduling rounds”, (Bahramshahry: ¶127), “which causes the workload, while executing, to take much longer to execute than normal due to the test failures”, (Bahramshahry: ¶607), “based further on execution of the workload tasks overlapping in time with a time frame associated with the failure condition”, (Bahramshahry: ¶711), “allocating the virtual resource exclusively to the computing resource for the duration of execution of the selected workload task”, (Bahramshahry: ¶677).
Regarding Claim 10 Bahramshahry fails to teach:
the graph theory comprises K-colour set problem technique which is used for task scheduling.
However, Cessa teaches: “In one embodiment, a graph coloring theory can be used to facilitate a measurement- task scheduling algorithm for network measurement system 100”, (Cessa: ¶023), “This problem can be described as a vertex coloring problem. For a conflict graph G(V,E) with vertices V = V(G), each vertex can be assigned a color out of k (e.g., integers 1, ..., k) colors such that no two adjacent vertices have the same color”… “the color set to be used in the conflict graph can represent a total number of time slots in a measurement cycle”, (Cessa: ¶029).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine “the graph theory comprises K-colour set problem technique which is used for task scheduling” of Cessa with the methods and systems of Bahramshahry in order to schedule tasks by assigning colors to items so conflicting items don’t get the same color and loads are spread as evenly as possible. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of resolving “measurement contention and to provide efficient task processing”, (Cessa: ¶023).
Regarding Claim 11, Bahramshahry teaches:
the round-robin technique is used for time-based server utilization, based on a round-robin time scheduler report provided by the round-robin technique.
“The capacity round implements a round-robin resource allocation which singularly focuses on available capacity”… “the scheduler 125 then iterates through as many rounds as required to either exhaust all available resources or exhaust all produced tasks”, (Bahramshahry: ¶110), “For a next capacity round, the scheduler then proceeds to calculate the next capacity round by taking into account the recently planned tasks at phase 127 and then the scheduling cycle is optionally finalized 131. A subsequent analyze 132 phase then applies post-scheduling analysis to check any decisions made during the scheduler's allocation rounds”, (Bahramshahry: ¶108). Examiner notes: the scheduler report is being interpreted as which tasks were allocated, how much capacity was consumed, what capacity remains available, and which tasks were deferred to later rounds.
Regarding Claim 12, Bahramshahry teaches:
the round-robin technique and the dynamic programming technique is used to prioritize Service Level Agreement (SLA) requirements of the one or more client devices.
“The capacity round implements a round-robin resource allocation”, (Bahramshahry: ¶110), “the producer 126 additionally specifies the importance or priority for every task created according to the workload type's SLT or required QoS”, (Bahramshahry: ¶109), “calculate an allocation route based on the service level targets and capacity that is known to be available”, (Bahramshahry: ¶124), “scheduling the pending workload tasks to execute via the one or more computing resources in compliance with the selected SLT specified for each of the pending workload tasks”, (Bahramshahry: ¶695).
Regarding Claim 13, Bahramshahry teaches:
A system for priority-based resource scheduling with load balancing,
“A scheduler responsible for performing the scheduling processes and generally will seek to perform a variety of functions in addition to scheduling work, such as optimizing utilizing of resources through a load balancing process which thus permits multiple users to share system resources more effectively.”, (Bahramshahry: ¶006), “scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources based on the information requested from the local cache”, (Bahramshahry: ¶278), “rating the pending workload tasks based on one or more of a workload type, a specified priority, and current available compute capacity”, (Bahramshahry: ¶687).
comprising: an input port configured to receive requests to execute one or more tasks;
“request interface 176”, (Bahramshahry: Fig 1A), “requesting, at a scheduler, information from the local cache specifying the one or more computing resources available to execute workload tasks and the plurality of workload tasks to be scheduled for execution”, (Bahramshahry: ¶278), “a hosted computing environment 111 is communicably interfaced with a plurality of user client devices 106A-C (e.g., such as mobile devices, smart phones, tablets, PCs, etc.)”, (Bahramshahry: ¶063), “he computer system 800 also may include a user interface 810 (such as a video display unit, a liquid crystal display, etc.), an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse), and a signal generation device 816 (e.g., an integrated speaker)”, (Bahramshahry: ¶266). Examiner notes: “Input port” is being interpreted as a request interface configured to receive requests from in this case client devices.
at least one automated processor associated with a resource scheduling system, configured to: receive from a plurality of client devices,
“a hosted computing environment 111 is communicably interfaced with a plurality of user client devices”, (Bahramshahry: ¶063), “customer organizations (104A, 104B, and 104C) which utilize web services and other service offerings as provided by the host organization 150 by communicably interfacing to the host organization 150 via network 195”, (Bahramshahry: ¶ 066), “executing a scheduler via the processor of the system, wherein the scheduler performs at least the following operations”, (Bahramshahry: ¶660).
one or more client requests to execute one or more tasks on one or more servers associated with one or more Virtual Machines (VMs),
“identifying, via a workload discovery engine, pending workload tasks to be scheduled for execution from one or more workload queues”, (Bahramshahry: ¶ 317), “scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources based on the information requested from the local cache”, (Bahramshahry: ¶278), “scheduling the selected workload task for execution with the computing resource and allocating the virtual resource exclusively to the computing resource for the duration of execution of the selected workload task”, (Bahramshahry: ¶678), “virtual machine 685 having mapped computing resources such as vCPU, RAM, a base image, a virtual image, IP space and network links, etc. The virtual machine 685 executes the workload tasks 641 in conjunction with memory 695”, (Bahramshahry: ¶221, Figure 6).
wherein the one or more client requests comprises request parameters;
“the workload discovery engine is to further identify a plurality of associated workload task requirements for each of the pending workload tasks”, (Bahramshahry: ¶290), “the scheduler is to evaluate a specified customer preference for executing workload tasks at a specified one of the plurality of computing resources as represented within the SLT for the respective workload task”, (Bahramshahry: ¶295), “in which the cloud-based service receives inputs from the client device at the user interface 626 to configure use of the scheduling service”, (Bahramshahry: ¶223).
determine usage-related information of each server associated with one or more VMs, upon receiving the one or more client requests;
“discovery engine 192 capable of discovering available compute resources by which to complete workloads and further capable to discover pending workloads awaiting assignment to compute resources”, (Bahramshahry: ¶073), “identifying, via a compute resource discovery engine, one or more computing resources available to execute workload tasks”, (Bahramshahry: ¶278), “the scheduler is to schedule the pending workload tasks based further on the associated workload task requirements and which of the plurality of computing resources available to execute workload tasks satisfies the associated workload task requirements”, (Bahramshahry: ¶290), “the scheduler is to evaluate pricing data represented within the local cache by the plurality of resource characteristics identified for each of the plurality of computing resources”, (Bahramshahry: ¶ 294), “identifying, via a workload discovery engine, pending workload tasks to be scheduled for execution”, (Bahramshahry: ¶317). Examiner Notes: because pending workload tasks arise from received client requests, this reinforces that resource determination occurs after receipt of the request.
prioritize the received one or more client requests, based on the request parameters associated with the one or more client requests;
“based on how the scheduler allocates resources and prioritizes competing needs”, (Bahramshahry: ¶007), “the SLT is identified by the policy engine based further on a customer identifier or an organizational identifier or a service tier associated with each respective workload task”, (Bahramshahry: ¶292), “the SLT identified for each of the workload tasks defines a Quality of Service (QoS) expectation for each workload task; in which the scheduler does not guarantee or commit to meeting the QoS expectation for any individual workload task”, (Bahramshahry: ¶293), “and associate each pending workload task within the local cache with a priority marker, a QoS indicator, and/or the SLT based on the workload queue from which the task was retrieved”, (Bahramshahry: ¶0289), “rating the pending workload tasks based on one or more of a workload type, a specified priority, and current available compute capacity”, (Bahramshahry: ¶ 687).
assign computing resources in the one or more servers to execute one or more tasks for the one or more client devices using a dynamic programming technique, based on the determined usage-related information and the prioritized one or more client requests;
“identifying, via a compute resource discovery engine, one or more computing resources available to execute workload tasks”, (Bahramshahry: ¶278), “scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources”, (Bahramshahry: ¶278), “schedule the pending workload tasks based further on the associated workload task requirements and which of the plurality of computing resources available to execute workload tasks satisfies the associated workload task requirements”, (Bahramshahry: ¶290), “scheduler will adjust one or more of re-try logic, priority, end-to-end execution time, preferred resource allocation range, and aging for each workload task”, (¶293), “dynamically allocate compute capacity (any of CPU, RAM, IP addresses, etc.) via which to perform a specific type of work according to needs”, (Bahramshahry ¶377), “Such adaptability is realized via a scheduler which determines independently where the resources should be allocated on an iteration by iteration basis, be it minute by minute, or some other time span for each iterative cycle (refer to the iterative cycle at FIG. 1C). Such a scheduler, by design, embraces the concept of eventual consistency, thus permitting a very decoupled solution”, (Bahramshahry: ¶380).
dynamically monitor the usage-related information of the one or more servers;
“the scheduler 125 is enabled to utilize the local cache 140 to make decisions on resource allocation while leveraging the various services to monitor external resources”…” resource pools or third party clouds may go online and offline or may become available to perform work or be wholly consumed and therefore unavailable to perform work”…“There are additional factors which may change such as pricing and preference and performance metrics, each of which may likewise be monitored and updated by the compute resource”, (Bahramshahry: ¶077), “the workload discovery 135 component will then query that discovered compute cloud requesting all running tasks and completed tasks”, (Bahramshahry: ¶079), “Such adaptability is realized via a scheduler which determines independently where the resources should be allocated on an iteration by iteration basis, be it minute by minute, or some other time span for each iterative cycle (refer to the iterative cycle at FIG. 1C). Such a scheduler, by design, embraces the concept of eventual consistency, thus permitting a very decoupled solution”, (Bahramshahry: ¶380).
migrate the one or more tasks from a first server to a second server of the one or more servers using at least one of a round-robin technique and graph theory technique, based on the monitored usage-related information,
“even when the service outage has ended or in the instance of the external service dependency having since been restored, the scheduling service may nevertheless migrate the workload execution to the different cloud to avoid repeating the same problem”, (Bahramshahry: ¶644), “The capacity round implements a round-robin resource allocation which singularly focuses on available capacity”… “If resources are available to allocation another instance of a pending task, then the round-robin capacity round process simply allocates that instance”, (Bahramshahry: ¶110), “The scheduler's 125 planning 127 operation then proceeds to specifically delineate which task will be performed by which compute cloud from the list of selected workload tasks”… “a first priority 1 workload task may be sent to a first third party cloud 199 with other priority 2 tasks being sent to different third-party compute clouds”, (Bahramshahry: ¶126), “query various computing clouds to check whether they are accessible and available and what workload tasks they are presently executing or have completed, with such auxiliary services then updating the local cache”, (Bahramshahry: ¶102), “The scheduler 125 then iterates through as many rounds as required to either exhaust all available resources or exhaust all produced tasks”, (Bahramshahry: 110), “identifying” … “a plurality of computing resources currently executing scheduled workload tasks”, (Bahramshahry: ¶349).
wherein the first server executes the one or more tasks for the one or more client devices;
“a hosted computing environment 111 is communicably interfaced with a plurality of user client devices 106A-C (e.g., such as mobile devices, smart phones, tablets, PCs, etc.)”, (Bahramshahry: ¶063), “to schedule at least a portion of the plurality of workload tasks 640 for execution via the one or more computing resources 628”, (Bahramshahry: ¶224), “identifies, via a compute resource discovery engine, a plurality of computing resources currently executing scheduled workload tasks”, (Bahramshahry: ¶340).
and initiate the one or more tasks on the second server, in response to migrating the one or more tasks,
“scheduling at least a portion of the plurality of workload tasks for execution via the one or more computing resources based on the information requested from the local cache”, (Bahramshahry: ¶278), “The scheduler's 125 planning 127 operation then proceeds to specifically delineate which task will be performed by which compute cloud from the list of selected workload tasks”, (Bahramshahry: ¶126), “scheduling one of the pending workload tasks into capacity within the plurality of computing resources freed up by the terminated workload task”, (Bahramshahry: ¶346), “scheduling the workload tasks potentially affected by the failure condition of the external service for a repeated execution on the plurality of computing resources”, (Bahramshahry: ¶712), “scheduling the multiple workload copies for execution on different computing resources”, (Bahramshahry: ¶687), “even when the service outage has ended or in the instance of the external service dependency having since been restored, the scheduling service may nevertheless migrate the workload execution to the different cloud to avoid repeating the same problem”, (Bahramshahry: ¶644).
wherein the one or more tasks are initiated on the second server to balance a load for resource utilization of the first server and the second server;
“such as optimizing utilizing of resources through a load balancing process”, (Bahramshahry: ¶006), “the planner 127 may be utilized to allocate resource for the most efficient utilization or for best performance”, (Bahramshahry: ¶114), “the capacity round implements a round-robin resource allocation which singularly focuses on available capacity”, (Bahramshahry: ¶110), “first third party cloud 199 with other priority 2 tasks being sent to different third-party compute clouds”, (Bahramshahry: ¶126), “the scheduler 125 then iterates through as many rounds as required to either exhaust all available resources or exhaust all produced tasks”, (Bahramshahry: ¶110), “a scheduler 1242 to schedule one of the pending workload tasks 1239 into capacity within the plurality of computing resources 1240 freed up by the terminated workload task 1241”, (Bahramshahry: ¶319).
and an output port configured communicate control information the first server and the second server.
“the external cloud interface 627 provides a communications link to third party private and public computing clouds 628 on behalf of the scheduling service 665”, (Bahramshahry: ¶222), “FIG. 7B shows that user system 712 may include a processor system 712A, memory system 712B, input system 712C, and output system 712D”, (Bahramshahry: ¶253), “user system 712 might include an HTTP client commonly referred to as a “browser” for sending and receiving HTTP messages to and from an HTTP server at system 716”… “such as round-robin HTTP request distributors to balance loads and distribute incoming HTTP requests evenly over a plurality of servers”, (Bahramshahry: ¶247).
Further regarding Claim 13, Bahramshahry fails to teach:
migrate the one or more tasks from a first server to a second server of the one or more servers using at least one of a round-robin technique and graph theory technique, based on the monitored usage-related information,
However, Cessa teaches: “In one embodiment, a graph coloring theory can be used to facilitate a measurement- task scheduling algorithm for network measurement system 100”, (Cessa: ¶023), “This problem can be described as a vertex coloring problem. For a conflict graph G(V,E) with vertices V = V(G), each vertex can be assigned a color out of k (e.g., integers 1, ..., k) colors such that no two adjacent vertices have the same color”… “the color set to be used in the conflict graph can represent a total number of time slots in a measurement cycle”, (Cessa: ¶029).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine “the graph theory comprises K-colour set problem technique which is used for task scheduling” of Cessa with the methods and systems of Bahramshahry in order to schedule tasks by assigning colors to items so conflicting items don’t get the same color and loads are spread as evenly as possible. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of resolving “measurement contention and to provide efficient task processing”, (Cessa: ¶023).
Regarding Claim 14, Bahramshahry teaches:
the at least one automated processor is configured to migrate the one or more tasks from a first server to a second server of the one or more servers using a round-robin technique.
“even when the service outage has ended or in the instance of the external service dependency having since been restored, the scheduling service may nevertheless migrate the workload execution to the different cloud to avoid repeating the same problem”, (Bahramshahry: ¶644), “The capacity round implements a round-robin resource allocation which singularly focuses on available capacity”… “If resources are available to allocation another instance of a pending task, then the round-robin capacity round process simply allocates that instance”, (Bahramshahry: ¶110), “The scheduler's 125 planning 127 operation then proceeds to specifically delineate which task will be performed by which compute cloud from the list of selected workload tasks”… “a first priority 1 workload task may be sent to a first third party cloud 199 with other priority 2 tasks being sent to different third-party compute clouds”, (Bahramshahry: ¶126), “query various computing clouds to check whether they are accessible and available and what workload tasks they are presently executing or have completed, with such auxiliary services then updating the local cache”, (Bahramshahry: ¶102), “The scheduler 125 then iterates through as many rounds as required to either exhaust all available resources or exhaust all produced tasks”, (Bahramshahry: 110), “identifying” … “a plurality of computing resources currently executing scheduled workload tasks”, (Bahramshahry: ¶349).
Regarding Claim 15 Bahramshahry fails to teach:
the at least one automated processor is configured to migrate the one or more tasks from a first server to a second server of the one or more servers a graph theory technique.
However, Cessa teaches: “In one embodiment, a graph coloring theory can be used to facilitate a measurement- task scheduling algorithm for network measurement system 100”, (Cessa: ¶023), “This problem can be described as a vertex coloring problem. For a conflict graph G(V,E) with vertices V = V(G), each vertex can be assigned a color out of k (e.g., integers 1, ..., k) colors such that no two adjacent vertices have the same color”… “the color set to be used in the conflict graph can represent a total number of time slots in a measurement cycle”, (Cessa: ¶029).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine “the graph theory comprises K-colour set problem technique which is used for task scheduling” of Cessa with the methods and systems of Bahramshahry in order to schedule tasks by assigning colors to items so conflicting items don’t get the same color and loads are spread as evenly as possible. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of resolving “measurement contention and to provide efficient task processing”, (Cessa: ¶023).
Regarding Claim 16, Bahramshahry teaches:
the request parameters comprise at least one of a demand comprising several tasks, a timeline, a pricing category, and a Service Level Agreement (SLA).
“the produce 126 phase prepares a comprehensive list of all pending work for a single workload type”, (Bahramshahry: ¶109), “not all tasks will be selected and planned for execution, thus causing them to age in terms of time since submission as well as possibly increase in priority for subsequent scheduling rounds”, (Bahramshahry: ¶127), “There are additional factors which may change such as pricing and preference and performance metrics”, (Bahramshahry: ¶077), “Other considerations may likewise be employed, such as the lowest cost resources or the most preferred among two or more resources from competing clouds”, (Bahramshahry: ¶114), “the producer 126 additionally specifies the importance or priority for every task created according to the workload type's SLT or required QoS”, (Bahramshahry: ¶109).
Regarding Claim 17, Bahramshahry teaches:
the usage-related information comprises at least one of an active time, a running time, and a load level.
“query various computing clouds to check whether they are accessible and available and what workload tasks they are presently executing or have completed”, (Bahramshahry: ¶102), “the capacity round implements a round-robin resource allocation which singularly focuses on available capacity”, (Bahramshahry: ¶110), “not all tasks will be selected and planned for execution, thus causing them to age in terms of time since submission as well as possibly increase in priority for subsequent scheduling rounds”, (Bahramshahry: ¶127), “which causes the workload, while executing, to take much longer to execute than normal due to the test failures”, (Bahramshahry: ¶607), “based further on execution of the workload tasks overlapping in time with a time frame associated with the failure condition”, (Bahramshahry: ¶711), “allocating the virtual resource exclusively to the computing resource for the duration of execution of the selected workload task”, (Bahramshahry: ¶677).
Regarding Claim 18, Bahramshahry fails to teach:
the graph theory comprises K-colour set problem technique which is used for task scheduling.
However, Cessa teaches: “In one embodiment, a graph coloring theory can be used to facilitate a measurement- task scheduling algorithm for network measurement system 100”, (Cessa: ¶023), “This problem can be described as a vertex coloring problem. For a conflict graph G(V,E) with vertices V = V(G), each vertex can be assigned a color out of k (e.g., integers 1, ..., k) colors such that no two adjacent vertices have the same color”… “the color set to be used in the conflict graph can represent a total number of time slots in a measurement cycle”, (Cessa: ¶029).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine “the graph theory comprises K-colour set problem technique which is used for task scheduling” of Cessa with the methods and systems of Bahramshahry in order to schedule tasks by assigning colors to items so conflicting items don’t get the same color and loads are spread as evenly as possible. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of resolving “measurement contention and to provide efficient task processing”, (Cessa: ¶023).
Regarding Claim 19, Bahramshahry teaches:
the round-robin technique is used for time-based server utilization, is based on a round-robin time scheduler report provided by the round-robin technique.
“The capacity round implements a round-robin resource allocation which singularly focuses on available capacity”… “the scheduler 125 then iterates through as many rounds as required to either exhaust all available resources or exhaust all produced tasks”, (Bahramshahry: ¶110), “For a next capacity round, the scheduler then proceeds to calculate the next capacity round by taking into account the recently planned tasks at phase 127 and then the scheduling cycle is optionally finalized 131. A subsequent analyze 132 phase then applies post-scheduling analysis to check any decisions made during the scheduler's allocation rounds”, (Bahramshahry: ¶108). Examiner notes: the scheduler report is being interpreted as which tasks were allocated, how much capacity was consumed, what capacity remains available, and which tasks were deferred to later rounds.
Regarding Claim 20, Bahramshahry Teaches:
the round-robin technique and the dynamic programming technique is used to prioritize Service Level Agreement (SLA) requirements of the one or more client devices.
“The capacity round implements a round-robin resource allocation”, (Bahramshahry: ¶110), “the producer 126 additionally specifies the importance or priority for every task created according to the workload type's SLT or required QoS”, (Bahramshahry: ¶109), “calculate an allocation route based on the service level targets and capacity that is known to be available”, (Bahramshahry: ¶124), “scheduling the pending workload tasks to execute via the one or more computing resources in compliance with the selected SLT specified for each of the pending workload tasks”, (Bahramshahry: ¶695).

Response to Arguments
In light of applicants amendments, all Claim objections, interpretations of 35 U.S.C. 112(f) and rejections under 35 U.S.C. 112(a) and 35 U.S.C. 112(b) have been with withdrawn.
Regarding rejections made under 35 U.S.C. 103:
Applicant argues: “claim 1 recites "determining, by the processor, usage-related information of each server associated with one or more VMs, upon receiving the one or more client requests," (emphasis added) which is not taught or suggested, either alone or in combination, by Bahramshahry and Cessa” … “Applicant respectfully traverses and submits that Bahramshahry, in the cited portions and elsewhere, describes a scheduling service architecture in which the compute resource discovery engine and workload discovery engine operate as autonomous background processes that constantly monitor and update a local cache independently of the scheduler and independently of any client request receipt.” … “At best, Bahramshahry describes that compute resource information is continuously gathered by autonomous discovery engines and stored in a local cache, which the scheduler then reads during its iterative scheduling cycles. The discovery engines operate on their own timing cycles, wholly independently of when any client request is received. Accordingly, Bahramshahry's architecture is fundamentally different: the continuous, decoupled, asynchronous nature of Bahramshahry's discovery engines is the antithesis of the "upon receiving" limitation.”
Examiner respectfully disagrees, Bahramshahry teaches: “a scheduler to request information from the cache specifying the one or more computing resources available to execute workload tasks and the plurality of workload tasks to be scheduled for execution; and further in which the scheduler is to schedule at least a portion of the plurality of workload tasks for execution via the one or more computing resources based on the information requested”, (Bahramshahry: Abstract), “producing a list of the workload tasks to be executed based on the information requested from the local cache; computing available capacity to execute workload tasks at each of the one or more computing resources based on the information requested from the local cache;”, (Bahramshahry: ¶226), “the cloud-based service receives inputs from the client device at the user interface 626 to configure use of the scheduling service 665 and identify workload tasks to be performed on behalf of the user device or on behalf of a customer organization, developer, business customer, or another user”, (Bahramshahry: ¶223, “the hosted computing environment 111 is the scheduling service 145 having therein both a scheduler 191 and also a discovery engine 192”, (Bahramshahry: ¶73). The citations indicates that client requests configure the scheduling service that works in conjunction (not independently as argued by applicant) with the scheduler and discovery engine to determine usage related information of compute resources. The scheduler requests information from cache pertaining to resources needed to execute workload tasks and computation of available capacity to execute tasks is performed responsive to information requested from cache. Thus, determining usage-related information is responsive to client requests to execute the workload tasks and the rejection under 35 U.S.C. 103 is upheld.
Applicant argues: “claim 1 recites "migrating, by the processor, from a first server to a second server of the one or more servers, the one or more tasks using at least one of a round- robin technique and graph theory technique, based on the monitored usage-related information, wherein the first server is executing the one or more tasks for the one or more client devices," which is not taught or suggested, either alone or in combination, by Bahramshahry and Cessa” … “As to migration, Bahramshahry at paragraph [0644] explains that "the scheduling service may nevertheless migrate the workload execution to the different cloud to avoid repeating the same problem." However, this migration is triggered by failure conditions - specifically, service outages, bad execution results, or hardware constraints.” … “Bahramshahry's migration is therefore not "based on the monitored usage-related information" as recited in amended independent claim 1, but rather is a reactive response to failure conditions and bad execution results.”
Examiner respectfully disagrees, it is noted that applicant argues in point (a) that Bahramshahry teaches autonomous usage monitoring as opposed to request based gathering of usage information and now argues that isn’t the case. Nevertheless, Bahramshahry teaches: “there is a monitor operating for each workload executing via any one of the compute resources and based on the monitoring, and based on historical data, it is known that anytime a particular log-line is observed from any one of these monitors, it is known that an outage or a failure mode has occurred”, (Bahramshahry: ¶641), “the scheduling service may nevertheless migrate the workload execution to the different cloud to avoid repeating the same problem. Similarly, a workload that fails due to hardware constraints, for example, exhausting memory and triggering performance problems or triggering a failure, may cause the scheduling service to react to the failure condition, such as an “out of memory” error and move the repeated execution of the workload to a larger VM with, for example, more available memory.”, (Bahramshahry: ¶644). The citation indicates that a failure occurs when usage of a cloud is too high or exceeds capacity and migrates the workload to a cloud with available memory. Applicant asserts that migration occurs as a “reactive response to failure conditions and bad execution results” however those failures arise from a monitored lack of resources to process workloads. Bahramshahry proactively monitors usage information to avoid failures via migration. Thus, migration occurs as a response to monitored usage related information. Therefore, the rejection under 35 U.S.C. 103 is upheld.
Applicant argues: “This round-robin is used for initial allocation of new pending tasks to available capacity - not for migrating already-executing tasks from one server to another. Bahramshahry contains no disclosure of using a round-robin technique to migrate tasks between servers. As evident from the above, Bahramshahry discloses failure-driven migration (without round-robin or graph theory) and round-robin allocation of new tasks (without migration). At no point does Bahramshahry teach or suggest using a round-robin technique for migration of tasks from a first server to a second server based on monitored usage-related information.”
Examiner respectfully disagrees, Bahramshahry teaches: “If resources are available to allocation another instance of a pending task, then the round-robin capacity round process simply allocates that instance. The scheduler 125 then iterates through as many rounds as required to either exhaust all available resources or exhaust all produced tasks”, (Bahramshahry: ¶110), “the local cache is updated to indicate the poor quality results for an executing or completed workload and where a failure condition is known (based on logs or error messages), the scheduler will reschedule the workload based further in consideration of the information in the local cache, including the failure condition if known”, (Bahramshahry: ¶644). The citations indicate that failed workloads are rescheduled and that the round-robin scheduling technique is used repeatedly until all workloads are completed. Therefore, the failed workloads, or workloads that must be migrated because the usage-related information indicate they would fail, are subject to rescheduling. Rescheduling uses the described scheduling techniques which include round-robin. Thus, the migration uses round-robin techniques. The rejection under 35 U.S.C. 103 is upheld.
Applicant argues: “Regarding Cessa, the Office Action relies on Cessa to supply the graph theory technique. However, Cessa is directed to an entirely different technical field - scheduling measurement tasks for active network measurement.” … “At best, Cessa describes using graph coloring to assign measurement tasks to time slots so that conflicting measurement tasks are not executed simultaneously. Cessa's graph coloring is a temporal scheduling technique for avoiding conflicts between network measurement probes - it contains no disclosure of migrating tasks from one server to another. Therefore, Cessa contains no disclosure of using graph theory to migrate already-executing tasks between servers based on monitored usage-related information.”
In response to applicant's argument that Cessa is nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, Bahramshahry and Cessa both fall under the analogous art of scheduling, and a person of ordinary skill in the art would look to another scheduling art to solve a problem relating to scheduling. Furthermore, Cessa is being used to teach using graph theory to improve the scheduling method of Bahramshahry. Therefore, the rejection under 35 U.S.C. 103 is upheld.
Applicant argues: “Furthermore, the Office Action's motivation to combine - "to schedule tasks by assigning colors to items so conflicting items don't get the same color and loads are spread as evenly as possible" for the purpose of resolving "measurement contention and to provide efficient task processing" - does not address the feature of using graph theory for migration of tasks between servers. Cessa's graph coloring resolves measurement contention between network probing tasks that compete for network resources such as bandwidth and memory at measurement points. Active measurement tools may compete for network resources as they are carrying out their tasks. Without correct regulation, the competition and resulting conflicts may adversely affect network measurement results. A person of ordinary skill in the art would not look to a network measurement scheduling reference to solve a cloud workload migration problem, as the two problems are fundamentally different in nature.”
Examiner respectfully disagrees, the two problems are not fundamentally in nature as the decision to migrate and where to migrate depends heavily on system utilization and “to schedule tasks by assigning colors to items so conflicting items don't get the same color and loads are spread as evenly as possible" directly tackles that problem by spreading workloads across resources so that tasks can be processed more efficiently leading to an improvement of Bahramshahry’s scheduling method particularly regarding cloud workload migration. Therefore, a person of ordinary skill in the art would know to look to Cessa to improve the scheduling method of Bahramshahry by evenly spreading workloads across resources so that tasks may be processed much more efficiently. Thus, the rejection under 35 U.S.C. 103 is upheld.
Applicant argues: “Dependent claims 2-6, 8-12, and 14-20 It is respectfully submitted that claims 2-6, 8-12, and 14-20 are also allowable at least by virtue of their dependency on corresponding amended independent claims 1, 7, and 13, which have been shown to be allowable above, and as well as for their additional claimed features.”
Examiner respectfully disagrees, the 35 U.S.C. 103 rejections were upheld and therefore all claims dependent on independent Claims 1, 7 and 13 are still rejected under 35 U.S.C. 103.
Conclusion
THIS ACTION IS MADE FINAL. 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 concerning this communication or earlier communications from the examiner should be directed to SHIHAB ALAM whose telephone number is [phone]. The examiner can normally be reached Mon - Fri 7:30am-5pm.
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, Bradley Teets can be reached at [phone]. 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.

/S.A./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197

Prosecution Timeline

• Jul 28, 2023: Application Filed
• Feb 12, 2026: Non-Final Rejection mailed — §103
• May 12, 2026: Response Filed
• Aug 03, 2026: Final Rejection mailed — §103 (current)