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 .
Response to Amendment
The amendment filed on 7/7/2026 has been entered. Claims 1-20 remain pending in this application. Applicant’s amendments to claims 2-6 have overcome the claim objections previously set forth in the Non-Final Office Action. Accordingly, Examiner withdraws the claim objections of claims 2-6. Applicant’s amendments to the claims have overcome the 35 U.S.C. § 112(b) rejection previously set forth in the Non-Final Office Action. Accordingly, Examiner withdraws the 35 U.S.C. § 112(b) rejection of claims 7-20.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) recite(s) sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitation(s) is/are: "means for adjusting..."; “monitor module executing logic”; “scaling module”; “worker controller” in claims 1 and 2. Claim 2 recites sufficient structure, materials, or acts to entirely perform the recited function.
Because this/these claim limitation(s) is/are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are not being interpreted to cover only the corresponding structure, material, or acts described in the specification as performing the claimed function, and equivalents thereof.
If applicant intends to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to remove the structure, materials, or acts that performs the claimed function; or (2) present a sufficient showing that the claim limitation(s) does/do not recite sufficient structure, materials, or acts to perform the claimed function.
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.
Claim(s) 1-4, 6-9, 12-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Markevics (US Patent No. 9,847,950 B1) in view of Bhadauria et al. (US Patent No. 10,761,893 B1 hereinafter Bhadauria).
As per claim 1, Markevics teaches a system for worker entity management (See Abstract and Col. 3, lines 10-22, “In embodiments of the invention, thread pooling involves a thread manager that periodically looks at all threads to determine status, e.g. Is the thread busy? The QueueManager keeps track of which queues have an actively polling worker thread.”), comprising: a data store comprising multiple queues for queueing respective sets of tasks (Col. 3, lines 42-67, “Each tenant's thread is assigned to a queue from a thread pool. Each consumer thread polls the queues in a round-robin fashion. As noted above, with a round-robin approach each consumer thread is assigned to a queue in equal portions and in circular order, handling all threads without priority. If a queue has any messages, that consumer thread processes the data…FIG. 5 is a block schematic diagram showing a messaging environment in which a message 52 is processed. In FIG. 5, a queue manager 50 controls the number of active threads for a plurality of queues 54 associated with a plurality of tenants 55a-55c. Each consumer thread polls the queues round-robin, i.e., it skips a thread if another thread is already processing. The thread manager 51 controls the number of active threads in the worker thread pool 53.”); for each queue of the multiple queues, a respective pool of worker entities for executing the respective set of tasks for the queue (Col. 2 & 3, lines 62-67 & 1-22, “FIG. 4 shows a messaging environment, such as a RabbitMQ environment, having one queue per tenant with a thread pool of consumers 40a, 40b that poll the queues according to the invention. A traditional model using RabbitMQ spins up a single thread per queue per consumer. Because this is not practical, as discussed above, embodiments of the invention skip the thread if another thread is already processing. A thread manager (discussed below) controls the number of active threads…In embodiments of the invention, thread pooling involves a thread manager that periodically looks at all threads to determine status, e.g. Is the thread busy? The QueueManager keeps track of which queues have an actively polling worker thread. The thread manager periodically checks this count and compares it against the total number of threads in the pool. If the counts are equal, then all threads are busy and the system can then spin up another thread, if the maximum number of allowed threads has not been reached. If all currently existing threads are busy, then the thread manager adds a thread; if the currently existing threads are not all busy, then the thread manager takes no action.”); periodically obtain statuses of worker entities in the respective pool of the worker entities for the given queue (Col. 3, lines 10-22, “In embodiments of the invention, thread pooling involves a thread manager that periodically looks at all threads to determine status, e.g. Is the thread busy? The QueueManager keeps track of which queues have an actively polling worker thread. The thread manager periodically checks this count and compares it against the total number of threads in the pool.” Col. 3, lines 42-59, “The thread manager periodically monitors the state of all running consumer threads and, if all consumer threads are busy, e.g., connected to a queue and processing data, then it spins up another thread to help with the current load. Conversely, if a worker thread makes it round-robin through the entire queue list twice without finding any data, then it shuts down, unless it is the last consumer thread, which never shuts down.”); and means for adjusting at least a size of the respective pool of worker entities for the given queue based on the current busyness of the respective pool of worker entities (Col. 3, lines 10-22, “In embodiments of the invention, thread pooling involves a thread manager that periodically looks at all threads to determine status, e.g. Is the thread busy? The QueueManager keeps track of which queues have an actively polling worker thread. The thread manager periodically checks this count and compares it against the total number of threads in the pool.” Col. 3, lines 42-59, “The thread manager periodically monitors the state of all running consumer threads and, if all consumer threads are busy, e.g., connected to a queue and processing data, then it spins up another thread to help with the current load. Conversely, if a worker thread makes it round-robin through the entire queue list twice without finding any data, then it shuts down, unless it is the last consumer thread, which never shuts down.”).
Markevics fails to explicitly teach a monitor module that calculates a current busyness of the pools of worker entities.
However, Bhadauria teaches a monitor module executing logic to, for a given queue of the multiple queues: calculate a busyness of the respective pool of worker entities based on the statuses (Col. 6 & 7, lines 58-67 & 1-7, “In an embodiment, at the circle labeled “1A” in FIG. 1, some or all of the compute instances supporting the services 116A-116C the application 114 periodically obtain and send worker pool utilization metrics to the data monitoring service 104. A “worker pool” generally corresponds to an amount of parallelization designed for each instance of a service, where a worker in a worker pool can process an incoming request if the worker is not presently busy. For example, if the software implementing service 116A is designed with a worker pool including a maximum of five total workers, each instance of the service can process up to five separate requests in parallel. If all five workers are busy and an additional request is received, the additional request is queued until one of the workers becomes available. In most cases, the size of a worker thread pool is static, but a worker pool can also be adaptive in size in some applications.” Col. 7, lines 32-50, “As indicated above, some or all of the compute instances implementing a service of the application 114 emits an instance utilization metric, which indicates a number of “busy” threads relative to a total size of the worker pool. A worker is counted as busy if the worker is currently processing a request. In some embodiments, the compute instances 118 can obtain and send worker pool utilization metrics to a data monitoring service 104 or other system component in association with a “namespace” that identifies the service to which the metric relates (for example, compute instances 118A executing the service 116A can be configured to emit metrics 122A to a “Service A” namespace, compute instances 118B can be configured to emit metrics 122B to the “Service B” namespace, and so forth).”).
Markevics and Bhadauria are considered to be analogous to the claimed invention because they are in the same field of task management and resource allocation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of managing worker entities of Markevics with the worker pool utilization thresholds of Bhadauria to arrive at the claimed invention. The motivation to modify Markevics with the teachings of Bhadauria is that being able to define busyness thresholds which dictate scaling operations allows a user to customize scaling operations to coincide with the resource usage of an application (See Bhadauria Col. 3, lines 39-54.).
Bhadauria also teaches means for adjusting at least a size of the respective pool of worker entities for the given queue based on the current busyness of the respective pool of worker entities (Col. 9, lines 42-57, “In one embodiment, for services which do not include any dependent services, an auto scaling policy can be configured to monitor an obtained worker pool utilization metric for the service and to take scaling actions if the metric exceeds or falls below one or more defined thresholds. For example, a scaling policy for a service can be configured to ensure that an average worker pool utilization metric for a service stays at or below 80% and, if the metric exceeds the defined threshold, the auto scaling service 106 can cause additional compute instances to be added to the fleet of compute instances executing the service. As another example, a scaling policy can additionally be configured so that if the average worker pool utilization metric for a service falls below a defined threshold (for example, 50% utilization), the auto scaling service 106 can cause compute instances to be removed from the associated fleet of compute instances.”).
As per claim 2, Markevics and Bhadauria teach the system of claim 1. Bhadauria teaches wherein the means for adjusting comprises: a scaling module configured to compare the current busyness of the respective pool of worker entities for the given queue to a target threshold; and a worker controller configured to adjust the size of the respective pool of worker entities for the given queue (Col. 9, lines 42-57, “In one embodiment, for services which do not include any dependent services, an auto scaling policy can be configured to monitor an obtained worker pool utilization metric for the service and to take scaling actions if the metric exceeds or falls below one or more defined thresholds. For example, a scaling policy for a service can be configured to ensure that an average worker pool utilization metric for a service stays at or below 80% and, if the metric exceeds the defined threshold, the auto scaling service 106 can cause additional compute instances to be added to the fleet of compute instances executing the service. As another example, a scaling policy can additionally be configured so that if the average worker pool utilization metric for a service falls below a defined threshold (for example, 50% utilization), the auto scaling service 106 can cause compute instances to be removed from the associated fleet of compute instances.” Col. 11, lines 9-40, “As indicated above, the fleet utilization metric can be calculated in various ways including aggregating the worker pool utilization metrics by each compute instance, averaging the worker pool utilization metrics, calculating a median worker pool utilization metric for the fleet, factoring in a pending requests metric (for example, as obtained from a load balancer or request queue 212 or other source), processed requests metrics, or combinations thereof. In the example shown in FIG. 2, the fleet utilization metric aggregates the worker pool utilization metrics emitted by each of the compute instances, for example, to obtain a value of 0.9 indicating that the worker pools collectively are at 90% utilization for the measured time period. In an embodiment, at the circle labeled “4,” the auto scaling service 106 generates a sends a scaling request 210 to the hardware virtualization service 102 based at least in part of the metrics obtained and calculated at circle “3.” For example, the fleet of compute instances 200 may be associated with an auto scaling policy that causes the auto scaling service 106 to maintain a maximum fleet utilization of 80% and, thus, the scaling request can instruct the hardware virtualization service 102 to launch one or more additional compute instances 208 to increase the capacity available to the application 202 because the currently calculated utilization exceeds the defined threshold.”).
Refer to claim 2 for reason to combine.
As per claim 3, Markevics and Bhadauria teach the system of claim 1. Markevics teaches wherein for the given queue, the statuses of worker entities comprise: (Col. 3, lines 42-67, “Each tenant's thread is assigned to a queue from a thread pool. Each consumer thread polls the queues in a round-robin fashion. As noted above, with a round-robin approach each consumer thread is assigned to a queue in equal portions and in circular order, handling all threads without priority. If a queue has any messages, that consumer thread processes the data…FIG. 5 is a block schematic diagram showing a messaging environment in which a message 52 is processed. In FIG. 5, a queue manager 50 controls the number of active threads for a plurality of queues 54 associated with a plurality of tenants 55a-55c. Each consumer thread polls the queues round-robin, i.e., it skips a thread if another thread is already processing. The thread manager 51 controls the number of active threads in the worker thread pool 53.”); and a total number of the worker entities in the respective pool of worker entities; and a number of the worker entities in the respective pool of worker entities that are currently processing tasks from the queue of the respective set of tasks for the given queue (Col. 3, lines 10-22, “In embodiments of the invention, thread pooling involves a thread manager that periodically looks at all threads to determine status, e.g. Is the thread busy? The QueueManager keeps track of which queues have an actively polling worker thread. The thread manager periodically checks this count and compares it against the total number of threads in the pool. If the counts are equal, then all threads are busy and the system can then spin up another thread, if the maximum number of allowed threads has not been reached.”). Bhadauria teaches a total number of the worker entities in the respective pool of worker entities and a number of the worker entities in the respective pool of worker entities that are currently processing tasks of the respective set of tasks for the given queue (Col. 7, lines 32-50, “As indicated above, some or all of the compute instances implementing a service of the application 114 emits an instance utilization metric, which indicates a number of “busy” threads relative to a total size of the worker pool. A worker is counted as busy if the worker is currently processing a request. In some embodiments, the compute instances 118 can obtain and send worker pool utilization metrics to a data monitoring service 104 or other system component in association with a “namespace” that identifies the service to which the metric relates (for example, compute instances 118A executing the service 116A can be configured to emit metrics 122A to a “Service A” namespace, compute instances 118B can be configured to emit metrics 122B to the “Service B” namespace, and so forth).”).
Refer to claim 1 for reason to combine.
As per claim 4, Markevics and Bhadauria teach the system of claim 1. Bhadauria teaches wherein, for the given queue, the current busyness of the respective pool of worker entities identifies a percentage of the worker entities in the respective pool of worker entities that are processing tasks of the respective set of tasks for the given queue (Col. 8 & 9, lines 57-67 & 1-11, “In an embodiment, at circle “2A” in FIG. 1, an auto scaling service 106 obtains one or more of the following metrics for a service for a past time window: a worker pool utilization metric, a processed requests metric, and a dependent service latency metric. The auto scaling service 106 can be configured to obtain the metrics on a periodic basis (which can be based on a default period, configured by a user, and/or adaptively based on a service's workload over time) or in response to a request to measure a current status of a service.” Col. 11, lines 9-28, “As indicated above, the fleet utilization metric can be calculated in various ways including aggregating the worker pool utilization metrics by each compute instance, averaging the worker pool utilization metrics, calculating a median worker pool utilization metric for the fleet, factoring in a pending requests metric (for example, as obtained from a load balancer or request queue 212 or other source), processed requests metrics, or combinations thereof. In the example shown in FIG. 2, the fleet utilization metric aggregates the worker pool utilization metrics emitted by each of the compute instances, for example, to obtain a value of 0.9 indicating that the worker pools collectively are at 90% utilization for the measured time period.”).
Refer to claim 1 for reason to combine.
As per claim 6, Markevics and Bhadauria teach the system of claim 1. Markevics teaches wherein the current busyness of the respective pool of worker entities does not depend on a number of tasks of the respective set of tasks in the given queue (Col. 3, lines 42-59, “There is always a minimum of two threads, one manager and one consumer thread. The thread manager periodically monitors the state of all running consumer threads and, if all consumer threads are busy, e.g., connected to a queue and processing data, then it spins up another thread to help with the current load. Conversely, if a worker thread makes it round-robin through the entire queue list twice without finding any data, then it shuts down, unless it is the last consumer thread, which never shuts down. Thus, the number of threads dynamically scales up and down proportional to the volume of traffic, while still processing each queue in FIFO order.”).
As per claim 7, Markevics teaches a method of worker entity management (See Abstract and Col. 3, lines 10-22, “In embodiments of the invention, thread pooling involves a thread manager that periodically looks at all threads to determine status, e.g. Is the thread busy? The QueueManager keeps track of which queues have an actively polling worker thread.”), the method comprising: for a given queue of multiple queues: (Col. 2 & 3, lines 62-67 & 1-22, “FIG. 4 shows a messaging environment, such as a RabbitMQ environment, having one queue per tenant with a thread pool of consumers 40a, 40b that poll the queues according to the invention. A traditional model using RabbitMQ spins up a single thread per queue per consumer. Because this is not practical, as discussed above, embodiments of the invention skip the thread if another thread is already processing. A thread manager (discussed below) controls the number of active threads…In embodiments of the invention, thread pooling involves a thread manager that periodically looks at all threads to determine status, e.g. Is the thread busy? The QueueManager keeps track of which queues have an actively polling worker thread. The thread manager periodically checks this count and compares it against the total number of threads in the pool. If the counts are equal, then all threads are busy and the system can then spin up another thread, if the maximum number of allowed threads has not been reached. If all currently existing threads are busy, then the thread manager adds a thread; if the currently existing threads are not all busy, then the thread manager takes no action.” ); the pool of worker entities configured for executing a set of tasks stored in the given queue (Col. 2 & 3, lines 62-67 & 1-22, “FIG. 4 shows a messaging environment, such as a RabbitMQ environment, having one queue per tenant with a thread pool of consumers 40a, 40b that poll the queues according to the invention. A traditional model using RabbitMQ spins up a single thread per queue per consumer. Because this is not practical, as discussed above, embodiments of the invention skip the thread if another thread is already processing. A thread manager (discussed below) controls the number of active threads…In embodiments of the invention, thread pooling involves a thread manager that periodically looks at all threads to determine status, e.g. Is the thread busy? The QueueManager keeps track of which queues have an actively polling worker thread. The thread manager periodically checks this count and compares it against the total number of threads in the pool. If the counts are equal, then all threads are busy and the system can then spin up another thread, if the maximum number of allowed threads has not been reached. If all currently existing threads are busy, then the thread manager adds a thread; if the currently existing threads are not all busy, then the thread manager takes no action.”), determining a current busyness of the pool of worker entities (Col. 3, lines 10-22, “In embodiments of the invention, thread pooling involves a thread manager that periodically looks at all threads to determine status, e.g. Is the thread busy? The QueueManager keeps track of which queues have an actively polling worker thread. The thread manager periodically checks this count and compares it against the total number of threads in the pool.”); when the current busyness is greater than a first target busyness threshold of the one or more target busyness thresholds, increasing a number of worker entities in the pool of worker entities for the given queue (Col. 3, lines 10-22, “If the counts are equal, then all threads are busy and the system can then spin up another thread, if the maximum number of allowed threads has not been reached. If all currently existing threads are busy, then the thread manager adds a thread; if the currently existing threads are not all busy, then the thread manager takes no action.”); and when the current busyness threshold is less than a second target busyness threshold of the one or more target busyness thresholds, decreasing a number of worker entities in the pool of worker entities for the given queue (Col. 3, lines 42-59, “Conversely, if a worker thread makes it round-robin through the entire queue list twice without finding any data, then it shuts down, unless it is the last consumer thread, which never shuts down. Thus, the number of threads dynamically scales up and down proportional to the volume of traffic, while still processing each queue in FIFO order.”).
Markevics fails to explicitly teach setting one or more target busyness thresholds for the pools of worker entities.
However, Bhadauria teaches setting one or more target busyness thresholds for a pool of worker entities assigned to the given queue (Col. 3, lines 39-54, “For example, a user can configure an auto scaling policy to monitor a resource load metric for a user's application (for example, based on CPU utilization, GPU utilization, or I/O latency) and can scale when average utilization of a selected resource for the fleet exceeds a defined threshold. If load changes for an application are predictable, users can also schedule scaling activities (for example, to increase capacity during weekdays but decrease capacity during weekends).”).
Markevics and Bhadauria are considered to be analogous to the claimed invention because they are in the same field of task management and resource allocation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of managing worker entities of Markevics with the worker pool utilization thresholds of Bhadauria to arrive at the claimed invention. The motivation to modify Markevics with the teachings of Bhadauria is that being able to define busyness thresholds which dictate scaling operations allows a user to customize scaling operations to coincide with the resource usage of an application (See Bhadauria Col. 3, lines 39-54.).
Bhaduria also teaches determining a current busyness of the pool of worker entities; when the current busyness is greater than a first target busyness threshold of the one or more target busyness thresholds, increasing a number of worker entities in the pool of worker entities for the given queue; and when the current busyness threshold is less than a second target busyness threshold of the one or more target busyness thresholds, decreasing a number of worker entities in the pool of worker entities for the given queue (Col. 9, lines 42-57, “In one embodiment, for services which do not include any dependent services, an auto scaling policy can be configured to monitor an obtained worker pool utilization metric for the service and to take scaling actions if the metric exceeds or falls below one or more defined thresholds. For example, a scaling policy for a service can be configured to ensure that an average worker pool utilization metric for a service stays at or below 80% and, if the metric exceeds the defined threshold, the auto scaling service 106 can cause additional compute instances to be added to the fleet of compute instances executing the service. As another example, a scaling policy can additionally be configured so that if the average worker pool utilization metric for a service falls below a defined threshold (for example, 50% utilization), the auto scaling service 106 can cause compute instances to be removed from the associated fleet of compute instances.”).
As per claim 8, Markevics and Bhadauria teach the method of claim 7. Markevics teaches periodically determining a percentage of worker entities, In the pool of worker entities assigned to the given queue that are currently processing tasks of the set of tasks stored in the given queue (Col. 3, lines 10-59, “In embodiments of the invention, thread pooling involves a thread manager that periodically looks at all threads to determine status, e.g. Is the thread busy? The QueueManager keeps track of which queues have an actively polling worker thread. The thread manager periodically checks this count and compares it against the total number of threads in the pool… The thread manager periodically monitors the state of all running consumer threads and, if all consumer threads are busy, e.g., connected to a queue and processing data, then it spins up another thread to help with the current load.”). Bhadauria teaches obtaining a plurality of percentages based on periodically determining a percentage of worker entities, in the pool of worker entities assigned to the given queue that are currently processing tasks of the set of tasks stored in the given queue; and combining the plurality of percentages (Col. 6 & 7, lines 58-67 & 1-31, “In an embodiment, at the circle labeled “1A” in FIG. 1, some or all of the compute instances supporting the services 116A-116C the application 114 periodically obtain and send worker pool utilization metrics to the data monitoring service 104. A “worker pool” generally corresponds to an amount of parallelization designed for each instance of a service, where a worker in a worker pool can process an incoming request if the worker is not presently busy. For example, if the software implementing service 116A is designed with a worker pool including a maximum of five total workers, each instance of the service can process up to five separate requests in parallel. If all five workers are busy and an additional request is received, the additional request is queued until one of the workers becomes available. In most cases, the size of a worker thread pool is static, but a worker pool can also be adaptive in size in some applications…In an embodiment, the process for each compute instance 118 obtaining and sending a threat utilization metric to a data monitoring service 104 can thus depend on the nature of the service. For example, logic for periodically obtaining and sending a worker pool utilization metric can be built into the code for some services, for example, either directly in the code or indirectly via a wrapper or software developer's kit (SDK). In other embodiments, a process external to the service (for example, an operating system component, hypervisor component, or other component of a host computing device upon which the service is executing) or external to the host computing device can be used to obtain the worker pool metric, for example, by periodically polling each instance of the service for its current worker pool utilization.” Col. 8 & 9, lines 57-67 & 1-11, “In an embodiment, at circle “2A” in FIG. 1, an auto scaling service 106 obtains one or more of the following metrics for a service for a past time window: a worker pool utilization metric, a processed requests metric, and a dependent service latency metric. The auto scaling service 106 can be configured to obtain the metrics on a periodic basis (which can be based on a default period, configured by a user, and/or adaptively based on a service's workload over time) or in response to a request to measure a current status of a service.” Col. 11, lines 9-28, “As indicated above, the fleet utilization metric can be calculated in various ways including aggregating the worker pool utilization metrics by each compute instance, averaging the worker pool utilization metrics, calculating a median worker pool utilization metric for the fleet, factoring in a pending requests metric (for example, as obtained from a load balancer or request queue 212 or other source), processed requests metrics, or combinations thereof. In the example shown in FIG. 2, the fleet utilization metric aggregates the worker pool utilization metrics emitted by each of the compute instances, for example, to obtain a value of 0.9 indicating that the worker pools collectively are at 90% utilization for the measured time period.”).
Refer to claim 7 for reason to combine.
As per claim 9, Markevics and Bhadauria teach the method of claim 7. Bhadauria teaches obtaining a plurality of percentages based on periodically determining a percentage of worker entities, in the pool of worker entities assigned to the given queue, that are idle; and combining the plurality of percentages (Col. 6 & 7, lines 58-67 & 1-31, “In an embodiment, at the circle labeled “1A” in FIG. 1, some or all of the compute instances supporting the services 116A-116C the application 114 periodically obtain and send worker pool utilization metrics to the data monitoring service 104. A “worker pool” generally corresponds to an amount of parallelization designed for each instance of a service, where a worker in a worker pool can process an incoming request if the worker is not presently busy. For example, if the software implementing service 116A is designed with a worker pool including a maximum of five total workers, each instance of the service can process up to five separate requests in parallel. If all five workers are busy and an additional request is received, the additional request is queued until one of the workers becomes available. In most cases, the size of a worker thread pool is static, but a worker pool can also be adaptive in size in some applications…In an embodiment, the process for each compute instance 118 obtaining and sending a threat utilization metric to a data monitoring service 104 can thus depend on the nature of the service. For example, logic for periodically obtaining and sending a worker pool utilization metric can be built into the code for some services, for example, either directly in the code or indirectly via a wrapper or software developer's kit (SDK). In other embodiments, a process external to the service (for example, an operating system component, hypervisor component, or other component of a host computing device upon which the service is executing) or external to the host computing device can be used to obtain the worker pool metric, for example, by periodically polling each instance of the service for its current worker pool utilization.” Col. 8 & 9, lines 57-67 & 1-11, “In an embodiment, at circle “2A” in FIG. 1, an auto scaling service 106 obtains one or more of the following metrics for a service for a past time window: a worker pool utilization metric, a processed requests metric, and a dependent service latency metric. The auto scaling service 106 can be configured to obtain the metrics on a periodic basis (which can be based on a default period, configured by a user, and/or adaptively based on a service's workload over time) or in response to a request to measure a current status of a service.” Col. 11, lines 9-28, “As indicated above, the fleet utilization metric can be calculated in various ways including aggregating the worker pool utilization metrics by each compute instance, averaging the worker pool utilization metrics, calculating a median worker pool utilization metric for the fleet, factoring in a pending requests metric (for example, as obtained from a load balancer or request queue 212 or other source), processed requests metrics, or combinations thereof. In the example shown in FIG. 2, the fleet utilization metric aggregates the worker pool utilization metrics emitted by each of the compute instances, for example, to obtain a value of 0.9 indicating that the worker pools collectively are at 90% utilization for the measured time period.” Examiner Note: One of ordinary skill in the art would recognize that the percentage of worker entities that are idle is simply 100 – the % of worker entities currently busy. Therefore, calculating the percentage of worker entities that are currently processing tasks would also indicate the percentage of worker entities that are currently idle.).
Refer to claim 7 for reason to combine.
As per claim 12, Markevics and Bhadauria teach the method of claim 7. Bhadauria teaches the number of worker entities currently in the pool of worker entities for the given queue (Col. 7, lines 32-50, “As indicated above, some or all of the compute instances implementing a service of the application 114 emits an instance utilization metric, which indicates a number of “busy” threads relative to a total size of the worker pool. A worker is counted as busy if the worker is currently processing a request.” Col. 9, lines 42-57, “In one embodiment, for services which do not include any dependent services, an auto scaling policy can be configured to monitor an obtained worker pool utilization metric for the service and to take scaling actions if the metric exceeds or falls below one or more defined thresholds. For example, a scaling policy for a service can be configured to ensure that an average worker pool utilization metric for a service stays at or below 80% and, if the metric exceeds the defined threshold, the auto scaling service 106 can cause additional compute instances to be added to the fleet of compute instances executing the service. As another example, a scaling policy can additionally be configured so that if the average worker pool utilization metric for a service falls below a defined threshold (for example, 50% utilization), the auto scaling service 106 can cause compute instances to be removed from the associated fleet of compute instances.”) and a number of tasks, of the set of tasks, within the given queue that are currently being processed by the worker entities (Col. 9, lines 12-41, “Thus, in some embodiments, at circle “2B,” an auto scaling service 106 optionally obtains data indicating a number of pending requests for a service (for example, requests pending for service 116A in the example of FIG. 1). The example shown in FIG. 1 depicts a scaling service 116 obtaining a pending requests metric from a load balancer or request queue 124A that may be configured to balance requests directed to the service 116A; in general, an auto scaling service 106 can obtain the pending requests metric from any one or more of: a load balancer, a request queue, a network device, an upstream service, or any other system component that can provide information about a number of pending requests for a service… In an embodiment, at circle “3,” the auto scaling service 106 calculates a fleet utilization metric (indicating worker pool utilization across an entire fleet of instances) and/or fleet load metric (indicating worker pool utilization in combination with other metrics) based on the obtained worker pool utilization metric and, optionally, further based on one or more of an obtained processed requests metric, dependent service latency metric, pending requests metric, or any other related metrics.” Col. 10 & 11, lines 63-67 & 1-8, “As illustrated by the circle labeled “1,” each of the compute instances 206A-206C obtains and sends to a data monitoring service 104 metrics 204 including worker pool utilization metrics and, optionally, pending requests metrics, processed requests metrics, dependent service latency metrics, and so forth, as described above.”).
Refer to claim 7 for reason to combine.
As per claim 13, Markevics and Bhadauria teach the method of claim 7. Bhadauria teaches wherein the first target busyness threshold and the second target busyness threshold comprise a same target busyness threshold of the one or more target busyness thresholds (Col. 9, lines 42-57, “In one embodiment, for services which do not include any dependent services, an auto scaling policy can be configured to monitor an obtained worker pool utilization metric for the service and to take scaling actions if the metric exceeds or falls below one or more defined thresholds. For example, a scaling policy for a service can be configured to ensure that an average worker pool utilization metric for a service stays at or below 80% and, if the metric exceeds the defined threshold, the auto scaling service 106 can cause additional compute instances to be added to the fleet of compute instances executing the service. As another example, a scaling policy can additionally be configured so that if the average worker pool utilization metric for a service falls below a defined threshold (for example, 50% utilization), the auto scaling service 106 can cause compute instances to be removed from the associated fleet of compute instances.”).
Refer to claim 7 for reason to combine.
As per claim 14, it is a computer-readable medium claim comprising similar limitations to claim 7, so it is rejected for similar reasons. Markevics also teaches a non-transitory computer-readable medium storing instructions (Col. 5, lines 53-64, “The memory 91 and storage devices 92 are computer-readable storage media that may store instructions that implement at least portions of the various embodiments of the invention. Thus, computer readable media can include computer-readable storage media, e.g. non-transitory media, and computer-readable transmission media.”).
As per claim 15, it is a computer-readable medium claim comprising similar limitations to claim 8, so it is rejected for similar reasons.
As per claim 16, it is a computer-readable medium claim comprising similar limitations to claim 9, so it is rejected for similar reasons.
As per claim 19, it is a computer-readable medium claim comprising similar limitations to claim 12, so it is rejected for similar reasons.
As per claim 20, it is a computer-readable medium claim comprising similar limitations to claim 13, so it is rejected for similar reasons.
Claim(s) 5, 10-11, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Markevics and Bhadauria as applied to claims 1, 7, and 14 above, and further in view of Arguelles et al. (US Patent No. 9,396,039 B1 hereinafter Arguelles).
As per claim 5, Markevics and Bhadauria teach the system of claim 1.
Markevics and Bhadauria fail to teach measuring the rate of addition of new tasks to the queue and using the measured rate to determine worker busyness.
However, Arguelles teaches the data store executes logic to periodically measure, for at least the given queue, a rate of addition of new tasks to the given queue (Col. 2 & 3, lines 55-67 & 1-3, “The controller may determine whether the workers are collectively applying the prescribed amount of load by monitoring the queue size. For example, if the queue size is growing, then the controller may be putting load jobs in the queue at a rate faster than the workers are able to dequeue. In some embodiments, the controller can perform a fast emergency shutdown or request additional hardware to be provisioned.” Col. 14, lines 45-54, “Accordingly, both performance metrics for workers and the size of the job queue may be monitored to determine whether auto-scaling of the workers would be beneficial. Monitoring both the metrics and the length of the job queue may ensure that resources are used effectively. Additionally, predictive auto-scaling may be based on anticipated performance metrics for workers (e.g., based on observed rates of change) and/or the anticipated size of the job queue (e.g., based on observed rates of change).”); and for the given queue, the current busyness of the respective pool of worker entities reflects a sequence of measured rates of addition of new tasks to the given queue (Col. 14 & 15, lines 55-67 & 1-7, “As indicated in 900, the queue size information may be accessed. The size of the queue may indicate whether the number of workers is sufficient to execute the test jobs generated based on the load step(s). In a properly provisioned load testing system 100, the number of jobs in the job queue may be very small at most times. As indicated in 910, if the number of taken jobs (i.e., jobs marked as taken but remaining in the queue) exceeds a given threshold, then auto-shutdown may occur, as indicated in 990. As indicated in 920, if the number of taken jobs has not exceeded the threshold, then the number of untaken jobs may be evaluated to determine if another threshold has been exceeded. If the threshold for untaken jobs has been exceeded, then auto-shutdown may occur, as indicated in 990. If neither threshold has been exceeded, then the queue size may continue to be monitored, as indicated in 900.”).
Markevics, Bhadauria, and Arguelles are all considered to be analogous to the claimed invention because they are all in the same field of task scheduling and resource allocation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system for managing automated worker entities of Markevics and Bhadauria with the logic for determining rate of addition of new tasks to a queue as taught by Arguelles to arrive at the claimed invention. The motivation to modify Markevics and Bhadauria with the teachings of Arguelles is that monitoring the rate of change in the size of a queue will help in determining whether or not the current amount of worker entities are sufficient for completing the pending tasks in the queue (See Arguelles Col. 14 & 15, lines 55-67 & 1-7.).
As per claim 10, Markevics and Bhadauria teach the method of claim 7.
Markevics and Bhadauria fail to teach measuring the rate of addition of new tasks to the queue and using the measured rate to determine worker busyness.
However, Arguelles teaches obtaining a plurality of rates of changes based on periodically determining a rate of change in a size of the given queue; and identifying a sequence of successive increases in the size of the given queue over multiple time periods based on the plurality of rates of changes (Col. 14 & 15, lines 45-67 & 1-17, “Accordingly, both performance metrics for workers and the size of the job queue may be monitored to determine whether auto-scaling of the workers would be beneficial. Monitoring both the metrics and the length of the job queue may ensure that resources are used effectively. Additionally, predictive auto-scaling may be based on anticipated performance metrics for workers (e.g., based on observed rates of change) and/or the anticipated size of the job queue (e.g., based on observed rates of change). In one embodiment, an auto-shutdown may be initiated (e.g., by auto-shutdown module 180 in FIG. 1) if any of various criteria are met during a load test. As indicated in 900, the queue size information may be accessed. The size of the queue may indicate whether the number of workers is sufficient to execute the test jobs generated based on the load step(s). In a properly provisioned load testing system 100, the number of jobs in the job queue may be very small at most times. As indicated in 910, if the number of taken jobs (i.e., jobs marked as taken but remaining in the queue) exceeds a given threshold, then auto-shutdown may occur, as indicated in 990. As indicated in 920, if the number of taken jobs has not exceeded the threshold, then the number of untaken jobs may be evaluated to determine if another threshold has been exceeded. If the threshold for untaken jobs has been exceeded, then auto-shutdown may occur, as indicated in 990. If neither threshold has been exceeded, then the queue size may continue to be monitored, as indicated in 900. In one embodiment, the number of compute instances in the load test may be monitored. In one embodiment, monitoring the number of compute instances may be performed in parallel with monitoring the queue size as discussed above. As indicated in 930, the number of controllers and/or workers may be determined. If the number of controllers and/or workers exceeds a threshold, as indicated in 940, then auto-shutdown may occur, as indicated in 990. If the number has not exceeded the threshold, then the number of controllers and/or workers may continue to be monitored, as indicated in 930.”).
Refer to claim 5 for reason to combine.
As per claim 11, Markevics and Bhadauria teach the method of claim 7.
Markevics and Bhadauria fail to teach measuring the rate of addition of new tasks to the queue and using the measured rate to determine worker busyness.
However, Arguelles teaches obtaining a plurality of rates of changes based on periodically determining a rate of change in a size of the given queue; and identifying a sequence of successive decreases in the size of the given queue over multiple time periods based on the plurality of rates of changes (Col. 2 & 3, lines 55-67 & 1-3, “The controller may determine whether the workers are collectively applying the prescribed amount of load by monitoring the queue size. For example, if the queue size is growing, then the controller may be putting load jobs in the queue at a rate faster than the workers are able to dequeue. In some embodiments, the controller can perform a fast emergency shutdown or request additional hardware to be provisioned.” Col. 14 & 15, lines 45-67 & 1-17, “Accordingly, both performance metrics for workers and the size of the job queue may be monitored to determine whether auto-scaling of the workers would be beneficial. Monitoring both the metrics and the length of the job queue may ensure that resources are used effectively. Additionally, predictive auto-scaling may be based on anticipated performance metrics for workers (e.g., based on observed rates of change) and/or the anticipated size of the job queue (e.g., based on observed rates of change). In one embodiment, an auto-shutdown may be initiated (e.g., by auto-shutdown module 180 in FIG. 1) if any of various criteria are met during a load test. As indicated in 900, the queue size information may be accessed. The size of the queue may indicate whether the number of workers is sufficient to execute the test jobs generated based on the load step(s). In a properly provisioned load testing system 100, the number of jobs in the job queue may be very small at most times. As indicated in 910, if the number of taken jobs (i.e., jobs marked as taken but remaining in the queue) exceeds a given threshold, then auto-shutdown may occur, as indicated in 990. As indicated in 920, if the number of taken jobs has not exceeded the threshold, then the number of untaken jobs may be evaluated to determine if another threshold has been exceeded. If the threshold for untaken jobs has been exceeded, then auto-shutdown may occur, as indicated in 990. If neither threshold has been exceeded, then the queue size may continue to be monitored, as indicated in 900. In one embodiment, the number of compute instances in the load test may be monitored. In one embodiment, monitoring the number of compute instances may be performed in parallel with monitoring the queue size as discussed above. As indicated in 930, the number of controllers and/or workers may be determined. If the number of controllers and/or workers exceeds a threshold, as indicated in 940, then auto-shutdown may occur, as indicated in 990. If the number has not exceeded the threshold, then the number of controllers and/or workers may continue to be monitored, as indicated in 930.”).
Refer to claim 5 for reason to combine.
As per claim 17, it is a computer-readable medium claim comprising similar limitations to claim 10, so it is rejected for similar reasons.
As per claim 18, it is a computer-readable medium claim comprising similar limitations to claim 11, so it is rejected for similar reasons.
Response to Arguments
Applicant's arguments filed 7/7/2026 have been fully considered but they are not persuasive. Regarding claims 1-4, 6-9, 12-16, and 19-20, Applicant argues that Markevics and Bhadauria teach a thread pool of consumers that is shared across a plurality of queues; rather than, a first queue having a first respective pool and a second queue having a second respective pool. Examiner disagrees with this statement and directs Applicant to an annotated version of Fig. 4 of Markevics, as shown below.
PNG
media_image1.png
534
804
media_image1.png
Greyscale
The annotated version of Fig. 4 from Markevics clearly depicts a first queue having a first respective pool of worker entities and a second queue having a second respective pool of worker entities. According to Col. 6 – lines 13-18 of Markevics, “Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention.” Thus, one of ordinary skill in the art would recognize that the embodiment illustrated in the annotated version of Fig. 4 is an embodiment that renders Applicant’s arguments unpersuasive and reads upon a “respective pool of worker entities for that queue” as claimed in the instant application. One of ordinary skill in the art will also recognize that the limitations regarding determining busyness of the pool of workers and adding or removing workers based on the current busyness of the pool workers for a given queue are also met by the embodiment of Fig. 4, as shown above. Additionally, regarding claim 8, Applicant argues that Bhadauria calculates utilization metrics across a fleet of worker pools rather than per-worker pool. Examiner disagrees with this argument and directs Applicant to the rejection of claim 8 which includes citations showing how metrics for each worker pool are calculated and used in determining when to scale up or down.
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 JOHN ROBERT DAKITA EWALD whose telephone number is (703)756-1845. The examiner can normally be reached Monday-Friday: 9:00-5:30 ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at (571)272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.D.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
