Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This Office Action is in response to the amendment filed 07/09/2026.
Claims 1-20 are pending in this application.
Claims 1,11 and 20 are independent claims.
Claims 1,3,5,6 and 11-20 are currently amended.
This Office Action is made final.
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 of this title, 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 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-6 and 11-16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US 2023/0236897 A1) in view of Aronovich (US 2023/0176918 A1) in further view of Zhu (US 2010/0115095 A1).
As per claim 1, Kumar teaches A method comprising:
receiving, by a controller, a first set of tasks, wherein each task in the first set of tasks has a task type that is one of a plurality of task types; assigning, by the controller, each of the tasks in the first set of tasks to worker nodes for processing by the worker nodes; (Kumar [0004] In a first mode, the method learns resources and execution times needed to process incoming workloads of a first workload type and a second workload type in a set of one or more clusters in a container-based computing environment [0053] As will be further described herein, intelligent resource calculator 414 identifies the need for on-demand clusters and resources required based on collected resource data from an initial run [receiving the tasks] of a seasonal workload in a regular cluster. Prediction model 416 collects resource data against time for regular cluster 408, and predicts available resources for a regular cluster for a specified time).
receiving, by the controller and for at least some of the tasks in the first set of tasks, feedback information about the processing by the worker nodes; determining, by the controller and based on the feedback information, an expected amount of processing associated with each task type in the plurality of task types; (Kumar 0070] FIG. 14 illustrates a methodology 1400 for on-demand cluster management according to an illustrative embodiment. As shown, in a first mode, step 1402 learns resources and execution times needed to process incoming workloads of a first workload type and a second workload type [feedback based on execution results in learning knowing resource requirement of workloads of various types for subsequent execution] in a set of one or more clusters in a container-based computing environment. In a second mode, based on the learning of resources and execution times in the first mode, step 1404 determines whether a subsequent incoming workload of the second workload type can be executed by one of the set of one or more clusters or whether an additional cluster should be created to process the subsequent incoming workload and then removed after processing the subsequent incoming workload is completed).
Kumar does not teach receiving, by the controller, a second set of tasks, wherein each task in the second set of tasks has a task type that is one of the plurality of task types and assigning a specific task in the second set of tasks, by the controller and based on the expected amount of processing associated with the specific task to a specific worker node of the worker nodes for processing.
However, Aronovich teaches receiving, by the controller, a second set of tasks, wherein each task in the second set of tasks has a task type that is one of the plurality of task types; (Aronovich [0061] For example, via a classification machine-learning model, scheduler 112 determines a resource usage rate for each workload (process 206). Each profile indicates an expected amount of resources the workload [profile is the same as type in the prior art of Kumar] will utilize per a given unit of time (e.g., amount of resources used per minute). Additionally, scheduler 112 determines a remaining time for completion (process 206). Based on workload profiles, scheduler 112 identifies an expected completion time for each type of workload. For pending workloads [second set of tasks], scheduler 112 uses the total expected completion time indicated in the workload profile of workload data 116)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Aronovich with the system of Kumar to enable task distribution. One having ordinary skill in the art would have been motivated to use Aronovich into the system of Kumar for the purpose of calculating resource quotas in a shared computing environment. (Aronovich paragraph 04).
Kumar and Aronovich do not teach assigning a specific task in the second set of tasks, by the controller and based on the expected amount of processing associated with the specific task to a specific worker node of the worker nodes for processing.
However, Zhu teaches assigning a specific task in the second set of tasks, by the controller and based on the expected amount of processing associated with the specific task to a specific worker node of the worker nodes for processing. (Zhu [0020] The assignment of the pods 140a-140n to one or more pod sets 150 may be based upon various factors, such as, physical configurations of the nodes 132a-132n contained in the pods 140a-140n, workload types assigned to the nodes 132a-132n contained in the pods 140a-140n, etc. and [0054] Continuing on to FIG. 3B, at step 314, the pod controller 114 determines an assignment of the workloads among nodes in a particular pod 140a based upon the resource demands of the workloads received from the node controller 112, the resource consumptions and capacities of the nodes received from the resource consumption and capacity sensors 126, and the common service policies received at step 302. And [claim 6] … determine an assignment of the workloads among one or more nodes contained in one of the plurality of pods based upon the detected resource consumptions and capacities of the nodes, the service policy information, and the resource demands of the workloads received from the node controller..)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Zhu with the system of Kumar and Aronovich to enable task distribution based on resource capabilities. One having ordinary skill in the art would have been motivated to use Zhu into the system of Kumar and Aronovich for the purpose of maximizing efficiencies in combining long-term demand patterns. (Zhu paragraph 12)
As per claim 2, Kumar teaches storing, by the controller, information about tasks assigned to each of the plurality of worker nodes. (Kumar [0068] Further details of prediction model 416 will now be explained in the context of system architecture 1300 in FIG. 13. Recall from FIG. 4 and as now depicted in FIG. 13, regular cluster 408, on-demand cluster 410, resource usage store 412, and prediction model 416. As shown in FIG. 13, prediction model 416 comprises a random forest time series forecaster 1302, a linear regression-based smoother 1304, and an API 1306. Prediction model 416 takes the history of the available resources and execution time (time duration) of different workloads in a cluster (transformed to time series data by resource usage store 412), and generates a predicted value indicating the predicted resource availability using machine learning algorithms comprising random forest time series forecaster 1302 and a linear regression-based smoother 1304. API 1306 is used to communicate inputs and outputs to the machine learning algorithms).
As per claim 3, Zhu teaches assigning the specific task in the second set of tasks further based on the information about tasks assigned to each of the plurality of worker nodes (Zhu [0020] The assignment of the pods 140a-140n to one or more pod sets 150 may be based upon various factors, such as, physical configurations of the nodes 132a-132n contained in the pods 140a-140n, workload types assigned to the nodes 132a-132n contained in the pods 140a-140n, etc. and [0054] Continuing on to FIG. 3B, at step 314, the pod controller 114 determines an assignment of the workloads among nodes in a particular pod 140a based upon the resource demands of the workloads received from the node controller 112, the resource consumptions and capacities of the nodes received from the resource consumption and capacity sensors 126, and the common service policies received at step 302. And [claim 6] … determine an assignment of the workloads among one or more nodes contained in one of the plurality of pods based upon the detected resource consumptions and capacities of the nodes, the service policy information, and the resource demands of the workloads received from the node controller..)
As per claim 4, Aronovich teaches storing information about the type associated with each of the tasks assigned to each of the plurality of worker nodes. (Aronovich [0050] In various embodiments, workload data 116 also includes a workload profile indication for each current or pending workload in workload data 116. Workload profiles indicate the type of workload that is, or will be, provisioned by the tenant. Workload profiles provide a framework to define expected resource consumption based on the type of workload to be provisioned, and the corresponding amount of resources needed to provision for workloads of each type. Example workload profiles include, but are not limited to, batch profile, streaming profile, interactive profile, and server profile. Each profile indicates the resource usage patterns that are typical with regard to the identified profile [0052] For example, in batch workloads, scheduler 112 retrieves previous workload data 116 recorded from previous workload from the tenant or from similar workload types, then determines average runtimes for the prior similar workloads.).
As per claim 5, Aronovich teaches assigning the specific task in the second set of tasks further based on the information about the type associated with each of the tasks assigned to each of the plurality of worker nodes. (Aronovich 0052] In various embodiments, scheduler 112 determines an expected resource consumption for each workload, current or pending, across all tenants 120a-n. Based on the determined or user-provided workload profile, scheduler 112 determines an expected resource consumption that indicates the number of resources to be consumed over an expected runtime of the workload. In addition to the resource usage of the workload, workload data 116 also includes expected completion times for each workload. In some scenarios, a tenant includes in the request to initiate a workload a completion time. In other scenarios, based on the workload profile, scheduler 112 determines the expected completion time. For example, in batch workloads, scheduler 112 retrieves previous workload data 116 recorded from previous workload from the tenant or from similar workload types, then determines average runtimes for the prior similar workloads. Also see paragraph 53 for more details about scheduling based on workload characteristics).
As per claim 6, Aronovich teaches wherein the worker nodes are included within a multitenant computing environment, wherein the tasks in the first set of tasks are each associated with one of the tenants in the multitenant computing environment, and wherein assigning specific tasks in the second set of tasks further includes:
assigning the specific tasks in the second set of tasks further based on information about the tenant associated with specific tasks assigned to each of the plurality of worker nodes to ensure access to worker nodes by each of the tenants in the multitenant computing environment. (Aronovich [0004] Embodiments of the present invention provide a method, system, and program product to calculate resource quotas in a shared computing environment are provided. A processor retrieves workload data regarding a plurality of workloads in a shared computing environment, where the plurality of workloads are executing or pending execution within the shared computing environment. A processor identifies a plurality of tenants of the shared computing environment associated with the plurality of workloads. A processor determines an expected resource usage for the plurality of tenants. A processor determines a ratio of resource usage for the plurality of tenants. A processor determines a resource limit for the plurality of tenants. A processor adjusts at least one aspect of the shared computing environment based on a determination that a total expected resource usage for both executing and pending workloads of a tenant exceeds a resource limit associated with the tenant [0023] Resource pooling: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant mode [0050] In various embodiments, workload data 116 also includes a workload profile indication for each current or pending workload in workload data 116. Workload profiles indicate the type of workload that is, or will be, provisioned by the tenant. Workload profiles provide a framework to define expected resource consumption based on the type of workload to be provisioned, a).
As to claims 11 and 20, they are rejected based on the same reason as claim 1.
With respect to claim 20 Kumar teaches computer-readable media ( claim 19 mentions non-transitory processor-readable storage medium and [0082] Articles of manufacture comprising such processor-readable storage media are considered illustrative embodiments. A given such article of manufacture may comprise, for example, a storage array, a storage disk or an integrated circuit containing RAM, ROM, flash memory or other electronic memory, or any of a wide variety of other types of computer program products. The term “article of manufacture” as used herein should be understood to exclude transitory, propagating signals. Numerous other types of computer program products comprising processor-readable storage media can be used).
As to claim 12, it is rejected based on the same reason as claim 2.
As to claim 13, it is rejected based on the same reason as claim 3.
As to claim 14, it is rejected based on the same reason as claim 4.
As to claim 15, it is rejected based on the same reason as claim 5.
As to claim 16, it is rejected based on the same reason as claim 6.
Claim 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US 2023/0236897 A1) in view of Aronovich (US 2023/0176918 A1) in further view of Zhu (US 2010/0115095 A1) and Habdank (US 2016/0019094 Al).
As per claim 7, Kumar and Aronovich and Zhu do not teach determining, by the controller and based on the feedback information and the second set of tasks, that instantiating an additional worker node will enable more efficient processing of the second set of tasks; and instantiating, by the controller, the additional worker node.
However, Habdank teaches determining, by the controller and based on the feedback information and the second set of tasks, that instantiating an additional worker node will enable more efficient processing of the second set of tasks; and instantiating, by the controller, the additional worker node. (Habdank Fig 2 and [0028] As shown in FIG. 2, the method200 further includes estimating a maximum server consumption per server for each task type associated with the current queue distribution (block 208) and determining a number of servers to allocate for the time period (block 210). In embodiments, estimating an average maximum task consumption per server may include determining a current number of instantiated servers, determining an historical backlog, determining an historical task consumption rate, and providing the inputs to another nonlinear estimator. In embodiments, the nonlinear estimator may be configured to optimize a function that defines a relationship between backlog and consumption. In embodiments, maximum server consumption may be measured in other ways such as, for example, maximum task consumption per server for all task types, maximum task consumption per task type for all servers, and/or the like. As shown in FIG. 2, embodiments of the method 200 further include adding or removing servers prior to the time period so as to allocate the determined number of servers (block 212)).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Habdank with the system of Kumar and Aronovich and Zhu to instantiate additional workers. One having ordinary skill in the art would have been motivated to use Habdank into the system of Kumar and Aronovich and Zhu for the purpose of facilitating more precise and efficient server resource allocation. (Habdank paragraph 02)
As to claim 17, it is rejected based on the same reason as claim 7.
Claim 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US 2023/0236897 A1) in view of Aronovich (US 2023/0176918 A1) in further view of Zhu (US 2010/0115095 A1) and Rao (US 2021/0117425 A1).
As per claim 8, Kumar and Aronovich and Zhu do not teach determining, by the controller and based on the feedback information and the second set of tasks, that processing of the second set of tasks can be performed efficiently with fewer worker nodes; and deallocating, by the controller, one of the worker nodes.
However, Rao teaches determining, by the controller and based on the feedback information and the second set of tasks, that processing of the second set of tasks can be performed efficiently with fewer worker nodes; and deallocating, by the controller, one of the worker nodes. (Rao [0721] Throughout the execution of the query, the query coordinator 3304 can monitor the worker nodes 3306 or processors 3406 processing partitions in the intake layer 3604, processing layer 3606, collector layer 3608, branch layer 3610, and storage layer 3612. If a worker node 3306 or processor 3406 becomes unavailable or becomes overloaded, the query coordinator 3304 can allocate additional resources or redistribute tasks or partitions. Similarly, if a worker node 3306 or processor 3406 is not being utilized, the query coordinator 3304 can deallocate it from a layer or redistribute the tasks or partitions. For example, if a partition on the external data source becomes unavailable, a corresponding worker node 3306 or processor 3406 in the intake layer 3604 may no longer receive any data. As such, the query coordinator 3304 can deallocate that worker node 3306 or processor 3406 from the intake layer 3604. In some embodiments, any change in state of a worker node 3306 or processor 3406 can be reported to the node monitor module 3314, which can be used by the query coordinator to allocate resources.)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Rao with the system of Kumar and Aronovich and Zhu to have fewer nodes. One having ordinary skill in the art would have been motivated to use Rao into the system of Kumar and Aronovich and Zhu for the purpose of enabling scalability in a distributed system (Rao paragraph 111).
As to claim 18, it is rejected based on the same reason as claim 8.
Claim 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US 2023/0236897 A1) in view of Aronovich (US 2023/0176918 A1) in further view of Zhu (US 2010/0115095 A1) and Sundaresan (US 2009/0254914 A1).
As per claim 9, Kumar and Aronovich and Zhu do not teach wherein determining an expected amount of processing associated with each task type includes: determining a weight associated with each task type.
However, Sundaresan teaches wherein determining an expected amount of processing associated with each task type includes: determining a weight associated with each task type. (Sundaresan [0018] (b) providing a set of network task types to a High Level Collector, wherein each type of task comprises a weight and priority)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Sundaresan with the system of Kumar and Aronovich and Zhu to determine a weight for each task type. One having ordinary skill in the art would have been motivated to use Sundaresan into the system of Kumar and Aronovich and Zhu for the purpose of implementing optimized usage of performance statistics. (Sundaresan paragraph 02)
As to claim 19, it is rejected based on the same reason as claim 9.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US 2023/0236897 A1) in view of Aronovich (US 2023/0176918 A1) in further view of Zhu (US 2010/0115095 A1) and Singh (US 2025/0016009 A1).
As per claim 10, Kumar and Aronovich and Zhu do not teach wherein receiving the first set of tasks includes: receiving a set of tasks associated with collection of data from a plurality of application performance monitoring systems
However, Singh teaches wherein receiving the first set of tasks includes:
receiving a set of tasks associated with collection of data from a plurality of application performance monitoring systems. (Singh [0032] Further, each of endpoints 102C and 102D may include an application monitoring agent (e.g., 124A and 124B) to monitor applications, services, and/or programs running in respective endpoints 102C and 102D. In an example, application monitoring agents 124A and 124B may be installed in respective endpoints 102C and 102D to fetch the metrics from various components of endpoints 102C and 102D. For example, application monitoring agents 124A and 124B may real-time monitor respective endpoints 102C and 102D to collect the metrics (e.g., telemetry data) associated with an application or an operating system running in endpoints 102C and 102D. An example application monitoring agent may be Telegraf agent, Collectd agent, or the like. Example metrics may include performance metric values associated with at least one of central processing unit (CPU), memory, storage, graphics, network traffic, applications, or the like).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Singh with the system of Kumar and Aronovich and Zhu to receive tasks based on collection of data. One having ordinary skill in the art would have been motivated to use Singh into the system of Kumar and Aronovich and Zhu for the purpose of receiving performance metrics from the monitoring agents and transmitting the performance metrics to a monitoring tool or a monitoring application for metric analysis. (Singh paragraph 16)
Response to Arguments
Applicant's arguments filed on 07/09/2026 have been fully considered but they are not persuasive.
Applicant’s arguments with respect to claims 1, 11 and 20 have been considered but are moot because the arguments do not apply because of the introduction of new art by Zhu.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEHRAN KAMRAN whose telephone number is (571)272-3401. The examiner can normally be reached on 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor April Blair, can be reached on (571)270-1014. 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.
/MEHRAN KAMRAN/Primary Examiner, Art Unit 2196
Prosecution Insights