DETAILED ACTION
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 .
Claims 1-20 are presented for the examination.
§ 101 2. 35 U.S.C. 101 reads as follows
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 2, 8, 15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As to Claims 1, 2, 8, 15 have been rejected under 35 USC 101 for abstract idea without significantly more. Under Step 2A, Prong 1, the “ specifying quantities of cloud-based resources requested ”, “observing feedback signals from the quota service”, “ detecting an overload indicator” recite a mental process since “specifying ” and “observing”, “detecting” are functions that can be reasonably performed in the human mind with the aid of pen and paper through observation, evaluation, judgment, opinion.
Under Prong 2, the additional element “ the feedback signals each indicating whether grant of a corresponding one of the lease requests would cause the tenant to exceed a resource quota limit allocated to the tenant; and dynamically decreasing parallelism of active tasks being processed by the cloud-based resources on behalf of the workload if the feedback signals satisfy overload criteria within a given time interval; and dynamically increasing parallelism of the active tasks being processed by the cloud-based resources on behalf of the workload if the feedback signals do not satisfy the overload criteria within the given time interval” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic computer or generic computer components to perform the judicial exception, Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f).
Under Step 2B, the additional elements “ the feedback signals each indicating whether grant of a corresponding one of the lease requests would cause the tenant to exceed a resource quota limit allocated to the tenant” - this generally have been a mental process although the tenant could be a generic computer component if the spec describes it software in actual computer hardware,
“dynamically decreasing parallelism of active tasks being processed by the cloud-based resources on behalf of the workload if the feedback signals satisfy overload criteria within a given time interval; and dynamically increasing parallelism of the active tasks being processed by the cloud-based resources on behalf of the workload if the feedback signals do not satisfy the overload criteria within the given time interval.” - this is mere instructions to apply the mental process under mpep 2106.05(f), amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
5. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application. See MPEP 2106.05(d). Thus, the claim is not patent eligible.
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, 2, 3 , 15 are rejected under 35 U.S.C. 103 as being unpatentable over Richter( US 20020194251 A1 ) in view of Wada( US 11474877 B1) in view of Rehman( US 20130103641 A1) and further in view of Lewis( US 20170339196 A1).
As to claim 1, Richter teaches transmitting lease requests on behalf of a tenant to the shared resource pool( such systems include those described elsewhere herein having multiple subsystems (e.g., processing engines) performing distinctive functions with each subsystem having different resource principals (e.g., memory, compute, I/O, bandwidth, number of buffers, number of connections, interfaces, etc.), para[0368], ln 6-15/ in FIG. 1A, network interface processing engine 1030 interfaces with network 1020 by receiving and processing requests for content and delivering requested content to network 1020. Network interface processing engine 1030 may be any hardware or hardware/software subsystem suitable for connections utilizing TCP (Transmission Control Protocol) IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), Internet Protocol (IP), Wireless Application Protocol (WAP) as well as other networking protocols, para[0089], ln 1-10/ Shared resources subsystem module 255 is shown provided for access by each of the other subsystem modules and may include, for example, additional processing resources, additional memory resources such as RAM, etc., para[0188], ln 6-12/ differentially managing an individual information processing request relative to other such requests allows provisioning of shared resources on a request-by-request, user-by-user, subscriber-by-subscriber or tenant-by-tenant basis based on SLA terms or other priority level information. Differentially monitoring or tracking resource usage for a particular request or particular user/customer allows reporting and verification of actual system performance relative to SLA terms or other standards set for the particular user or customer, para[0262])
the lease requests being associated with various processing tasks ( track resource provisioning and/or shared resource usage associated with particular information manipulation tasks such as may be associated with processing of particular requests for information, para[0270], ln 1-8/ As described elsewhere herein, such parameters may be defined and provisioned based on virtually any characteristic or combinations of characteristic associated with a particular information manipulation task including, but not limited to, identity or class of user or request, type of request, resource requirement associated with a particular request, etc, para[0335], ln 15-23)
and specifying quantities resources requested from the shared resource pool( tracking resource usage for a particular request or particular user/customer allows reporting and verification of actual system performance relative to SLA terms or other standards set for the particular user or customer, and/or allows billing for shared resource usage to be based on the differential use of such resources by a particular user/customer relative to other users/customers, para[0262], ln 7-15),
observing feedback signals from the quota service for a time interval( a "debounce" capability may be implemented to avoid flooding a system administrator with threshold alerts. Such a debounce capability be implemented, for example by algorithm/s, to ensure that an application processing engine remains in a state that exceeds or recedes below a given alert threshold state for a pre-defined amount of time to ensure that it is not a transient state, para[05290) .
the feedback signals each indicating whether grant of a corresponding one of the lease requests would cause the tenant to exceed a resource quota limit allocated to the tenant( a software plug-in that is capable of checking the availability of application processing resources upon each stream request[lease request] (e.g., content transaction) received by the content delivery system. Such a plug-in may either grant or deny each stream request based on the availability of application processing engine resources, para[0526], ln 7-15/ For example, the plug-in may be configured to prevent over-utilization of total available resource capacity utilization units, and in a manner that guarantees that an accepted stream request[grant of a corresponding one of the lease requests] is satisfied by delivery of the stream in a reliable manner. The plug-in may monitor or track the number of allocated or used resource capacity utilization units per application processing engine in relation to one or more pre-defined "water marks" or thresholds, and may also generate alerts, para[0527], ln 5-16/ Alert issued when red alert threshold exceeded indicating that application processing engine resource utilization level is at maximum capacity, and although the system is continuing to function reliably with current accepted stream requests[grant of a corresponding one of the lease requests], para[0528], ln 9-16/ individual processing engine resource state threshold that represents the highest resource utilization of each of the processing engines implemented by the requested information management task (e.g., requested content/information delivery), para[0385], ln 6-12).
Wada teaches congestion control that increases utilization of compute resources, specifying quantities of cloud-based resources requested ( The cloud bursting scales out a public cloud (adds (increases) the number of computers (computer resources) that execute data processing). , col 1, n 20-25/ , resources in the on-premises 101, col 5, ln 10-12/ a hybrid cloud configuration data processing infrastructure system 200 shown in FIG. 1. Hereinafter, the hybrid cloud configuration data processing infrastructure system 200 is simply referred to as a “data processing infrastructure system 200.” The data processing infrastructure system 200 includes data processing systems 201 built on-premises 101, col 4, ln 25-35 / in the case where the communication bandwidth of the first network 103 between the on-premises 101 and the public cloud 102 is insufficient (congested), the data processing system 201 reduces the transfer amount of the first network 103 by switching the Worker DB node that performs data processing, to the Worker DB node 106b2 that has a cache and that caches frequently accessed data, col 24, ln 35-45/ resources (server resources) in the on-premises 101 are not insufficient, the scale control process 214 determines in Step 1203 that the insufficient resource is “FALSE,” and proceeds to Step 1204. In Step 1204, the scale control process 214 adds the Worker DB node 106a in the on-premises 101, col 17,l n 55-67)
dynamically decreasing parallelism of active tasks being processed by the cloud-based resources on behalf of the system if the feedback signals satisfy overload criteria within a given time interval ( refers to the threshold value determination information 222 collected by the system threshold value determination process 219 of the monitoring server 210, to determine whether or not the network transfer amount (NW transfer amount) of the Worker DB cluster in the public cloud 102 has exceeded the threshold value., col 18, n 24-30/ the Worker DB node 106b having a cache executes the query processing while accessing the storage S1 in the on-premises 101, in parallel with data copy to the storage cluster 113 in the public cloud 102, para[0024], ln 30-35/ a hybrid cloud configuration data processing infrastructure system 200 shown in FIG. 1. Hereinafter, the hybrid cloud configuration data processing infrastructure system 200 is simply referred to as a “data processing infrastructure system 200.” The data processing infrastructure system 200 includes data processing systems 201 built on-premises 101, col 4, ln 25-35/ In Step 1263, the scale control process 214 determines whether or not a state where the CPU utilization rate of the Worker DB cluster in the public cloud 102 is equal to or smaller than the threshold value and where the network transfer amount (NW transfer amount) is equal to or smaller than the threshold value has continued for a predetermined period of time or more… determines in Step 1263 that the continued state is “FALSE,” and returns to Step 1261…..In the case where a state where the CPU utilization rate of the public cloud Worker DB cluster is equal to or smaller than the threshold value and where the network transfer amount (NW transfer amount) is equal to or smaller than the threshold value has continued for a predetermined period of time or more, the scale control process 214 determines in Step 1263 that the continued state is “TRUE,” ….. Step 1264, After the query processing is completed, the scale control process 214 removes the Worker DB node 106b in the public cloud 102 from the Worker DB cluster. In other words, the scale control process 214 executes scale-in to reduce the number of Worker DB nodes 106b in the public cloud 102 to 0., col 23, ln 1-31/Fig. 12 F.
and dynamically increasing parallelism of the active tasks being processed by the cloud-based resources on behalf of the tenant if the feedback signals do not satisfy the overload criteria within the given time interval( the Worker DB node 106b having a cache executes the query processing while accessing the storage S1 in the on-premises 101, in parallel with data copy to the storage cluster 113 in the public cloud 102, para[0024], ln 30-35/ a hybrid cloud configuration data processing infrastructure system 200 shown in FIG. 1. Hereinafter, the hybrid cloud configuration data processing infrastructure system 200 is simply referred to as a “data processing infrastructure system 200.” The data processing infrastructure system 200 includes data processing systems 201 built on-premises 101, col 4, ln 25-35/ The data processing infrastructure system 200 executes scale-out (adds (increases) the Worker DB nodes 106a that perform processing in a distributed manner) in the on-premises 101 according to the load of the query processing. In this case, resources in the on-premises 101 become insufficient (also referred to as an “on-prem resource shortage”) in some cases due to an overload caused by an unexpected analysis request in the data processing infrastructure system 200. In this case, it becomes difficult for the data processing infrastructure system 200 to perform the scale-out (add (increase) the Worker DB nodes 106a) in the on-premises 101, col 5, ln 6-20/ The first graph image Gr11 to the third graph image Gr13 indicate that the Worker DB node 106b1 is added at time t1 since the CPU utilization rate of the Worker DB cluster in the on-premises 101 exceeds the threshold value and the on-prem resources are insufficient. Further, the first graph image Gr11 to the third graph image Gr13 indicate that the Worker DB node 106b1 is added (increased) at time t2 since the CPU utilization rate of the Worker DB cluster in the public cloud 102 exceeds the threshold value, para[0023], ln 60-67/ during a period of time from a start of the data copy process to an end of the data copy process, the scale-out in the cloud environment by increasing the number of the processing nodes that execute the data processing, col 2, ln 59-65).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Richter with Wada to include the above feature because this provides a computer system and a scale-out method of the computer system that can reduce the possibility of occurrence of performance deterioration in the case where cloud bursting is executed.
Rehman teaches transmitting lease requests to a quota service, lease request specifying quantities of resources requested from the shared resource pool( In this regard, when the user manipulates the client device 118 and/or browser application 119 to receive, consume or otherwise access a resource from the resource system 116 , ….….. For example, the application platform 112 and/or virtual application 114 may transmit a request including the identifier associated with the user of the client device 118 and the identifier associated with the product, service and/or resource the user is attempting to access. Using the user's identifier and the tenant identifier associated with the provider system 110, the entitlement management engine 130 identifies any entitlement objects associated with the user in the relational database 106 to determine whether the user is associated with an entitlement that includes the identified resource. When the user is associated with an entitlement that includes the identified resource, the entitlement management engine 130 obtains or otherwise accesses the user's user entitlement usage object associated with that entitlement object to obtain the user's entitlement usage (or consumption) of that resource. Based on the user's entitlement usage with respect to that product or service along with any other limitations, rules and/or qualifying criteria for that product or service, the entitlement management engine 130 determines whether the user is entitled to that product or service. For example, the entitlement management engine 130 may determine a user is entitled to a requested resource when the user's entitlement usage indicates that the user has not exceeded his or her entitled (or allotted) quantity with respect to that resource or when the user's entitlement usage indicates that the user has exceeded his or her entitled quantity if criteria associated with that resource indicates that the user is allowed to exceed his or her entitled quantity (e.g.,
active tasks being processed by the cloud-based resources on behalf of the tenant( tenant-developed virtual applications 828, para[0055], ln 8-10/The server 802 operates with any sort of conventional processing hardware 804, such as a processor 805… including any number of "cloud-based" or other virtual systems…… The computer-executable programming instructions, when read and executed by the server 802 and/or processor 805, cause the server 802 and/or processor 805 to create, generate, or otherwise facilitate the application platform 810 and/or virtual applications 828 and perform one or more additional tasks, operations, functions, and/or processes described herein, para[0045, ln 25-40/ Any number of custom and/or standard objects 826 may also be available for integration into tenant-developed virtual applications 828, para[0050], ln 6-10/ Fig. 8).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Richter and Wada with Rehman to include the above feature because this supports on-demand applications, and more particularly, embodiments of the subject matter relate to methods and systems for providing entitlements and monitoring entitlement usage in an on-demand application system.
Lewis teaches a workload including various processing tasks for lease request specify the resources, dynamically decreasing parallelism of active tasks on behalf of the workload if the feedback signals satisfy overload criteria within a given time interval, and dynamically increasing parallelism of the active tasks on behalf of the workload if the feedback signals do not satisfy the overload criteria within the given time interval.
( For a software container service, such as the software container service 804 of FIG. 8, a service construct may be the scalable resource. In some examples, a “service construct”[workload] may refer to a group of tasks/containers configured by the customer to run as an application service (e.g., for performing particular workload processing[workload]). One or more service constructs may run in a cluster of container instances. The customer may specify a desired task count that indicates a number of tasks that should be the executing simultaneously[parallelism] in the service construct[workload]. Thus, the desired task count may be a scalable dimension of the service construct resource, para[0042]/ scaling policy triggered by a telemetry service alarm may specify to increase the group by 3 more database service instances, 10 more virtual machines, and 4 load balancers, para[0142], ln 23-29/ The customer 826 may register the service construct in the scaling service 802 with the associated cluster 832, minimum and maximum desired task counts, and a policy/role management service …….. An example of a scale out policy is to increase task count by 10 percent, with minimum increase of 2 tasks, and have a cooldown of 2 minutes. An example of a scale in policy is to decrease task count by 1 task and have a cooldown of 1 minute. Through the scaling service frontend 214, shown in FIG. 2, the customer 826 may attach the scaling policy 830 to one or more alarms of the telemetry service 806 to cause the scaling service 802 to perform the scaling action 808, para[0206]/ The scaling policy may specify scaling activities to perform as a result of the scaling policy being executed (e.g., triggered by the alarm 110). A scaling activity represents an action taken to increase or decrease the desired capacity of a scalable target at a certain time, para[0026], ln 8-16/ at least two types of events may cause notifications to be sent: an increase in desired task count and a decrease in desired task count. The customer 226 may choose to have notifications sent (e.g., via a notification service) for one or both types of events. Further, for software container service, if a scaling policy is triggered by an alarm of the telemetry service 206, the desired task count of the service construct may be changed continuously, based on the current running count and a scaling adjustment specified (within the minimum and maximum capacity) in the scaling policy until the alarm has been cleared, the minimum/maximum capacity has been reached, or the timeout has expired, para[0100], ln 1-16/ An in-progress scale-in may be indicated by the running count being greater than the desired task count, para[0107], ln 4-7/ “desired count,” the value of which indicates how many tasks should be running in a service construct of a particular cluster. The scheduler may be responsible for ensuring that the number of tasks running matches the desired count. For example, if the desired count is 50, and the 50 running tasks crash, the scheduler may launch 50 more tasks to achieve the desired count. Likewise, if there are 200 tasks running in a cluster and the desired count is 100, the scheduler may shut down 100 of the tasks to achieve the desired count, para[0153]/ the scaling service may provide added flexibility to the software container service by allowing the customer to specify that, if there is too much load on this particular service construct (e.g., if there is a load spike, etc.), the scaling service should cause the service construct to instead run 20 or 50 tasks instead of 10, para[0151], ln 26-34/ APIs. As an example, the customer 826 may create a scale out policy and a scale in policy for the service construct. An example of a scale out policy is to increase task count by 10 percent, with minimum increase of 2 tasks, and have a cooldown of 2 minutes. An example of a scale in policy is to decrease task count by 1 task and have a cooldown of 1 minute, para[0206], ln 7-15/ The scaling service 802 may perform calculations to determine, given the current number of the tasks 812 and the X % to be scaled, what new number of the tasks 812 the service construct should step to. Once this number is determined, the scaling service 802 may send an API call to the software container service 804 requesting to change the number of the tasks 812 to the amount determined. The service construct will be aware of the number of current tasks 812A and be able to determine how many additional tasks will need to be launched in order to arrive at the desired number, para[02020, ln 20-30/ If the scaling service 802 is scaling out, the scaling service 802 may only change the desired task count if the current value of the desired task count is less than the new one. In other words, the scaling service 802 may favor a larger scale over a smaller one. Take for example, a situation where two scale-out policies P1 and P2 are triggered on the same service construct within seconds of each other. In this example, P1 is specified to increase the desired task count by 10%, while P2 is specified to increase the desired task count by 20%. Assuming both the current desired and running count are 10 and assuming P1 is executed first, the scaling service 802 will set the desired task count to 11. Thus, depending on timing, P2 may see the running count being 10 and desired 11. When P2 is executed, the new desired task count will be calculated as 12 (10+10*20%), and, thus, the desired task count will be set to 12, because 12 is greater than 11. Conversely, if P2 is executed first, it will set the desired task count to 12, but P1, when executed, will not set the desired task count to 11 because 11 is smaller than 12. Similarly, if the scaling service 802 is scaling in, the scaling service 802 may only change the desired task count if current value of the desired task count is greater than the new one. In other words, the system will again favor a larger scale in to a smaller one, para[0223]/ para[0025]/ based on the scaling policy and the current task count, the system may calculate a new task count, thereby determining the scaling action. For example if the new task count is greater than the current task count, the scaling action may be to scale up the running tasks by an amount corresponding to the difference between the task counts. Likewise, if the new task count is less than the current task count, the scaling action may be to scale down the running tasks by an amount corresponding to the difference between this task count, para[0230]/ In this situation, the scaling service 202 may allow a scale-out to increase the desired task count in a manner that optimally maintains application availability. Conversely, an in-progress scale-out may be indicated by the running count being less than the desired task count, in which case the scaling service 202 may not allow a scale-in to decrease the desired task count in order to optimally protect application availability, para[0107], ln 5-14/ improve user experience with distributed computing resources by providing a single set of application programming interfaces compatible for dynamically scaling multiple types of resources, para[0018]).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to include the above feature because this improves the field of computing, specifically the field of autoscaling, using a system designed to dynamically scale a wide variety of distributed computing resource characteristics for customers of a computing resource service provider.
As to claim 2, Richter teaches observing the feedback signals further includes: detecting an overload indicator within a select one of the feedback signals corresponding to a lease request that would cause the tenant to exceed the resource quota limit( para[0528]/ para[0530], ln 1-12).
As to claim 3, Richer teaches overload indicator indicates denial of the lease request and wherein the feedback signals satisfy the overload criteria when a threshold number of overload indicators are received in the given time interval( para[0529], ln 1-10/ para[0928]).
As to claim 15, it is rejected for the same reason as to claim 1 above.
Claim(s) 4, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Richter( US 20020194251 A1 ) in view of Wada( US 11474877 B1) in view of Rehman( US 20130103641 A1) in view of Lewis( US 20170339196 A1) and further in view of Cherkasov( US 20140215487 A1).
As to claim 4, Cherkasov teaches the various processing tasks are associated with a workload and wherein dynamically decreasing parallelism of the active tasks further includes decreasing task parallelism for the workload( of a job as a function of the division of the job into tasks that are operated in parallel, para[0003]/optimizing the reduce task settings (decreasing the number of reduce tasks) while achieving performance objectives is a desirable feature of an efficient workload management in the cluster, para[0028], ln 14- 24).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching because this optimizes the workflow completion time while minimizing the resource usage for its execution.
As to claim 18, it is rejected for the same reason as to claim 4 above.
Claim(s) 5, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Richter( US 20020194251 A1 ) in view of Wada( US 11474877 B1) in view of Rehman( US 20130103641 A1) in view of Cherkasov( US 20140215487 A1) and further in view of Nelson( US 20140137104 A1).
As to claim 5, Nelson teaches dynamically decreasing parallelism for the workload achieves a multiplicative decrease in at least one of total utilization of compute resources by the workload and a number of parallel tasks being executed on behalf of the workload( application resource scheduler 132 selects and powers off one or more task VMs having a total resource allocation that offsets a corresponding decrease in the amount of unreserved resources. It should be recognized that the workload scheduler 126 may detect, by way of node manager 310, the powered off tasks VMs are no longer reachable or responsive, thereby simulating a node failure, para[0044], ln 6-17).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this adjusts an amount of computing resources seen by the workload scheduler to be available for execution of the application workload based on the determined amount of available computing resources.
As to claim 19, it is rejected for the same as to claim 5 above.
Claim(s) 6 is rejected under 35 U.S.C. 103 as being unpatentable over Richter( US 20020194251 A1 ) in view of Wada( US 11474877 B1) in view of Rehman( US 20130103641 A1) in view of Lewis( US 20170339196 A1) in view of Cherkasov( US 20140215487 A1) and further in view of Sheng( US 20230072962 A1).
As to claim 6, Sheng teaches dynamically increasing parallelism of the active tasks includes additively increasing task parallelism for the workload( computed based on the task type. Task types may include, for example, jobs (e.g., non-parallel, parallel with a fixed completion count, or parallel with a work queue, para[0043], ln 3-10/ expected workload (e.g., accounting for increased workload brought about by adding new tasks to the nodes 232-256 and accounting for decreased workload upon task completions), expected resources, and the like. , para[0046], ln 9-16).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this provides Workload scheduling and distribution functions are mostly handled by a centralized module; to ensure scheduling performance, the system usually uses simple rules.
Claim(s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over Richter( US 20020194251 A1 ) in view of Wada( US 11474877 B1) in view of Rehman( US 20130103641 A1) in view of Lewis( US 20170339196 A1) and further in view of Gupta( US 12505279 B2).
As to claim 7, Gupta teaches the shared resource pool includes graphics processing units (GPUs) dedicated to supporting a transformer model trained to perform natural language processing (NLP) tasks( The processor 104 may be a central processing unit (CPU), a graphics processing unit (GPU), or both. Additionally, any processor described herein may include multiple processors, col 5, ln 16-20/ The processor 104 may be a central processing unit (CPU), a graphics processing unit (GPU), or both. Additionally, any processor described herein may include multiple processors, col 17, ln 48-53).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this improves performance in a machine learning model that is designed to perform natural language processing tasks.
Claims 8, 11 are rejected under 35 U.S.C. 103 as being unpatentable over Richter( US 20020194251 A1 ) in view of Wada( US 11474877 B1) in view of Rehman( US 20130103641 A1) in view of Lewis( US 20170339196 A1) and further in view of Yu( US 11922282 B2).
As to claim 8, it rejected for the same reason as to claim 1 above.
In additional, Yu teaches receive, from a tenant to the shared resource pool, a request for processing of a workload by a transformer model( Typically, users of client devices submit requests to an inference system, col 1, ln 31-33/ The hardware of the inference system 130 may include one or more central processing unit (CPU) cores, CPU memory (e.g., DRAM), data storage, one or more execution engines (e.g., GPU devices). Each execution engine may include a set of cores (e.g., GPU cores) coupled to local memory (e.g., GPU memory), and may be composed of one or more hardware accelerators. In addition, the inference system 130 may be composed of multiple hardware components and components for configuring a network to connect the various components across the multiple hardware components together such that the components can coordinate with each other to process requests. , col 5, ln 12-25/ the execution engine receives a batch of requests and executes one or more iterations of the transformer model via selective batching using the inputs for each request. ……… the execution engine may process workload that requires processing capabilities of more than one hardware accelerator. Thus, the execution engine is able to distribute the workload across multiple hardware accelerators if necessary, col 19, ln 47-67 to col 20, ln 1-5).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this allows high flexibility in processing variable length requests.
As to claim 11, Richer teaches the quota manager is further configured to dynamically increase parallelism of active tasks being processed by the cloud- based resources on behalf of the tenant in response to determining that the feedback signals fail to satisfying overload criteria( col 5, ln 6-20/ col 2, ln 59-65).
Claims 9, 10 are rejected under 35 U.S.C. 103 as being unpatentable over Richter( US 20020194251 A1 ) in view of Wada( US 11474877 B1) in view of Rehman( US 20130103641 A1) in view of Lewis( US 20170339196 A1) and further in view of Mannar( US 11526385 B1).
As to claim 9, Mannar teaches the feedback signals corresponding to denied lease requests include overload indicators(the method 500 may further include determining a resource requirement for the one or more sub-tasks based upon a resource model. For example, the resource model may estimate the amount of processing power required to process/execute a task request within a specified timeframe (e.g., number of hours, days, weeks, etc. as specified by the requesting client). Accordingly, if the resource model determines that the processing requirements of a particular task request exceed the capabilities of the system, the resource model may generate an alert signal for display to a client or other user indicating denial of the task request, col 21, ln 55-67).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this provides accurate, timely, and actionable execution of these tasks.
As to claim 10, Mannar teaches the feedback signals satisfy the overload criteria for the workload when a threshold number of the overload indicators are received in association with the workload in a set period of time( col 21, ln 55-67) for the same reason as to claim 9 above.
Claim(s) 12, 13, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Richter( US 20020194251 A1 ) in view of Wada( US 11474877 B1) in view of Rehman( US 20130103641 A1) in view of Lewis( US 20170339196 A1) and further in view of Nelson( US 20140137104 A1).
As to claim 12, Nelson teaches dynamically decreasing parallelism for the workload achieves a multiplicative decrease in total utilization of compute resources by the workload ( application resource scheduler 132 selects and powers off one or more task VMs having a total resource allocation that offsets a corresponding decrease in the amount of unreserved resources. It should be recognized that the workload scheduler 126 may detect, by way of node manager 310, the powered off tasks VMs are no longer reachable or responsive, thereby simulating a node failure, para[0044], ln 6-17).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this adjusts an amount of computing resources seen by the workload scheduler to be available for execution of the application workload based on the determined amount of available computing resources.
As to claim 13, Nelson teaches dynamically decreasing parallelism for the workload achieves a multiplicative decrease in a number of parallel tasks being executed on behalf of the workload(para[0044], ln 6-17) for the same reason as to claim 12 above.
As to claim 14, Nelson teaches imposes adjustments to parallelism of active workload tasks within a client compute platform executing an application that generates the workload( para[0044], ln 6-17) for the same reason as to claim 12 above.
Claim(s) 16, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Richter( US 20020194251 A1 ) in view of Wada( US 11474877 B1) in view of Rehman( US 20130103641 A1) in view of Lewis( US 20170339196 A1) and further in view of Mannar( US 11526385 B1).
As to claim 16, Mannar teaches the feedback signals corresponding to denied lease requests include overload indicators( the method 500 may further include determining a resource requirement for the one or more sub-tasks based upon a resource model. For example, the resource model may estimate the amount of processing power required to process/execute a task request within a specified timeframe (e.g., number of hours, days, weeks, etc. as specified by the requesting client). Accordingly, if the resource model determines that the processing requirements of a particular task request exceed the capabilities of the system, the resource model may generate an alert signal for display to a client or other user indicating denial of the task request, col 21, ln 55-67).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this provides accurate, timely, and actionable execution of these tasks.
As to claim 17, Mannar teaches the feedback signals satisfy the overload criteria when a threshold number of overload indicators are received in a set period of time( col 21, ln 55-67) for the same reason as to claim 16 above.
Claim(s) 19 is rejected under 35 U.S.C. 103 as being unpatentable over Richter( US 20020194251 A1 ) in view of Wada( US 11474877 B1) in view of Rehman( US 20130103641 A1) in view of Lewis( US 20170339196 A1) in view of Mannar( US 11526385 B1) and further in view of Nelson( US 20140137104 A1).
As to claim 19, Nelson teaches dynamically decreasing parallelism for the workload achieves a multiplicative decrease in at least one of total utilization of compute resources by the workload and a number of parallel tasks being executed on behalf of the workload( application resource scheduler 132 selects and powers off one or more task VMs having a total resource allocation that offsets a corresponding decrease in the amount of unreserved resources. It should be recognized that the workload scheduler 126 may detect, by way of node manager 310, the powered off tasks VMs are no longer reachable or responsive, thereby simulating a node failure, para[0044], ln 6-17).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this adjusts an amount of computing resources seen by the workload scheduler to be available for execution of the application workload based on the determined amount of available computing resources.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Richter( US 20020194251 A1 ) in view of Wada( US 11474877 B1) in view of Rehman( US 20130103641 A1) ) in view of Lewis( US 20170339196 A1) and further in view of Aggarwal(US 20200366682 A1).
As to claim 20, Aggarwal teaches each of the lease requests includes an application identifier for the tenant and a requested quantity of compute resources to allocate toward execution of a corresponding one of the various processing tasks( ng now to operation (315), and in some embodiments, requests 210 can be received from one or more clients 230. The clients 230 can generate requests 210 to interact with or access different end points or providers within the multi-tenant environment 200. For example, the clients 230 (e.g., customers) can request 210 to access, including but not limited to, servers, devices, data centers, providers, and/or cloud services. The requests 210 can include an application 208, an application identifier, a type of application, and/or a routing policy to handle the respective request 210, para[0059], ln 1-14/ 216 can include a processing duration value and a memory utilization profile for an application 208 corresponding to the requests 210 executed by the application 208. The processing duration value can include CPU processing times and/or CPU duration times corresponding a time value used to execute of fulfill a request 210. For example, the request characteristics 216 can include CPU duration used, maximum CPU duration used, minimum CPU duration used, memory allocation or consumption, maximum memory consumption, minimum memory consumption, bandwidth allocation, and/or performance data. The request characteristics 216 can include client properties (e.g., IP address, device type) corresponding to the clients 230 generating the requests 210. The execution characteristics 217 can include metrics corresponding to the execution of a particular request 210, properties of the application 208 handling the request 210, and/or properties of the clients 230 generating the request 210, para[0047], ln 5-28).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this provides monitoring services to monitor, control and/or generate reports corresponding to the provided shared services and resources.
Response to the argument:
A. Applicant amendment filed on 05/11/2026 has been considered but they are not persuasive:
Applicant argued in substance that :
(1) “The present claims similarly provide a specific solution, e.g., adjustment of parallelism of cloud-computing processing tasks responsive to over- or under-utilization of
resources. Accordingly, for at least the foregoing reasons, the Applicant respectfully requests withdrawal of the § 101 rejection”.
(2) “No disclosure or suggestion of "dynamically decreasing parallelism of active
tasks being processed by the cloud-based resources on behalf of the workload" or
"dynamically increasing parallelism of the active tasks being processed by the
cloud-based resources on behalf of the workload."
30. Examiner respectfully disagreed with Applicant's remarks:
As to the point (1), As to Claims 1, 2, 8, 15 have been rejected under 35 USC 101 for abstract idea without significantly more. Under Step 2A, Prong 1, the “ specifying quantities of cloud-based resources requested ”, “observing feedback signals from the quota service”, “ detecting an overload indicator” recite a mental process since “specifying ” and “observing”, “detecting” are functions that can be reasonably performed in the human mind with the aid of pen and paper through observation, evaluation, judgment, opinion.
Under Prong 2, the additional element “ the feedback signals each indicating whether grant of a corresponding one of the lease requests would cause the tenant to exceed a resource quota limit allocated to the tenant; and dynamically decreasing parallelism of active tasks being processed by the cloud-based resources on behalf of the workload if the feedback signals satisfy overload criteria within a given time interval; and dynamically increasing parallelism of the active tasks being processed by the cloud-based resources on behalf of the workload if the feedback signals do not satisfy the overload criteria within the given time interval” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic computer or generic computer components to perform the judicial exception, Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f).
Under Step 2B, the additional elements “ the feedback signals each indicating whether grant of a corresponding one of the lease requests would cause the tenant to exceed a resource quota limit allocated to the tenant” - this generally have been a mental process although the tenant could be a generic computer component if the spec describes it software in actual computer hardware,
“dynamically decreasing parallelism of active tasks being processed by the cloud-based resources on behalf of the workload if the feedback signals satisfy overload criteria within a given time interval; and dynamically increasing parallelism of the active tasks being processed by the cloud-based resources on behalf of the workload if the feedback signals do not satisfy the overload criteria within the given time interval.” - this is mere instructions to apply the mental process under mpep 2106.05(f), amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
As to the point (2), Lewis teaches For a software container service, such as the software container service 804 of FIG. 8, a service construct may be the scalable resource. In some examples, a “service construct”[workload] may refer to a group of tasks/containers configured by the customer to run as an application service (e.g., for performing particular workload processing[workload]). One or more service constructs may run in a cluster of container instances. The customer may specify a desired task count that indicates a number of tasks that should be the executing simultaneously[parallelism] in the service construct[workload]. Thus, the desired task count may be a scalable dimension of the service construct resource, para[0042]/ scaling policy triggered by a telemetry service alarm may specify to increase the group by 3 more database service instances, 10 more virtual machines, and 4 load balancers, para[0142], ln 23-29/ The customer 826 may register the service construct in the scaling service 802 with the associated cluster 832, minimum and maximum desired task counts, and a policy/role management service …….. An example of a scale out policy is to increase task count by 10 percent, with minimum increase of 2 tasks, and have a cooldown of 2 minutes. An example of a scale in policy is to decrease task count by 1 task and have a cooldown of 1 minute. Through the scaling service frontend 214, shown in FIG. 2, the customer 826 may attach the scaling policy 830 to one or more alarms of the telemetry service 806 to cause the scaling service 802 to perform the scaling action 808, para[0206]/ The scaling policy may specify scaling activities to perform as a result of the scaling policy being executed (e.g., triggered by the alarm 110). A scaling activity represents an action taken to increase or decrease the desired capacity of a scalable target at a certain time, para[0026], ln 8-16/ at least two types of events may cause notifications to be sent: an increase in desired task count and a decrease in desired task count. The customer 226 may choose to have notifications sent (e.g., via a notification service) for one or both types of events. Further, for software container service, if a scaling policy is triggered by an alarm of the telemetry service 206, the desired task count of the service construct may be changed continuously, based on the current running count and a scaling adjustment specified (within the minimum and maximum capacity) in the scaling policy until the alarm has been cleared, the minimum/maximum capacity has been reached, or the timeout has expired, para[0100], ln 1-16/ An in-progress scale-in may be indicated by the running count being greater than the desired task count, para[0107], ln 4-7/ “desired count,” the value of which indicates how many tasks should be running in a service construct of a particular cluster. The scheduler may be responsible for ensuring that the number of tasks running matches the desired count. For example, if the desired count is 50, and the 50 running tasks crash, the scheduler may launch 50 more tasks to achieve the desired count. Likewise, if there are 200 tasks running in a cluster and the desired count is 100, the scheduler may shut down 100 of the tasks to achieve the desired count, para[0153]/ the scaling service may provide added flexibility to the software container service by allowing the customer to specify that, if there is too much load on this particular service construct (e.g., if there is a load spike, etc.), the scaling service should cause the service construct to instead run 20 or 50 tasks instead of 10, para[0151], ln 26-34/ APIs. As an example, the customer 826 may create a scale out policy and a scale in policy for the service construct. An example of a scale out policy is to increase task count by 10 percent, with minimum increase of 2 tasks, and have a cooldown of 2 minutes. An example of a scale in policy is to decrease task count by 1 task and have a cooldown of 1 minute, para[0206], ln 7-15/ The scaling service 802 may perform calculations to determine, given the current number of the tasks 812 and the X % to be scaled, what new number of the tasks 812 the service construct should step to. Once this number is determined, the scaling service 802 may send an API call to the software container service 804 requesting to change the number of the tasks 812 to the amount determined. The service construct will be aware of the number of current tasks 812A and be able to determine how many additional tasks will need to be launched in order to arrive at the desired number, para[02020, ln 20-30/ If the scaling service 802 is scaling out, the scaling service 802 may only change the desired task count if the current value of the desired task count is less than the new one. In other words, the scaling service 802 may favor a larger scale over a smaller one. Take for example, a situation where two scale-out policies P1 and P2 are triggered on the same service construct within seconds of each other. In this example, P1 is specified to increase the desired task count by 10%, while P2 is specified to increase the desired task count by 20%. Assuming both the current desired and running count are 10 and assuming P1 is executed first, the scaling service 802 will set the desired task count to 11. Thus, depending on timing, P2 may see the running count being 10 and desired 11. When P2 is executed, the new desired task count will be calculated as 12 (10+10*20%), and, thus, the desired task count will be set to 12, because 12 is greater than 11. Conversely, if P2 is executed first, it will set the desired task count to 12, but P1, when executed, will not set the desired task count to 11 because 11 is smaller than 12. Similarly, if the scaling service 802 is scaling in, the scaling service 802 may only change the desired task count if current value of the desired task count is greater than the new one. In other words, the system will again favor a larger scale in to a smaller one, para[0223]/ para[0025]/ based on the scaling policy and the current task count, the system may calculate a new task count, thereby determining the scaling action. For example if the new task count is greater than the current task count, the scaling action may be to scale up the running tasks by an amount corresponding to the difference between the task counts. Likewise, if the new task count is less than the current task count, the scaling action may be to scale down the running tasks by an amount corresponding to the difference between this task count, para[0230]/ In this situation, the scaling service 202 may allow a scale-out to increase the desired task count in a manner that optimally maintains application availability. Conversely, an in-progress scale-out may be indicated by the running count being less than the desired task count, in which case the scaling service 202 may not allow a scale-in to decrease the desired task count in order to optimally protect application availability, para[0107], ln 5-14/ improve user experience with distributed computing resources by providing a single set of application programming interfaces compatible for dynamically scaling multiple types of resources, para[0018]).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Conclusion
US 20090178047 A1 teaches Scalability: We verify that the present principles maintain convergence properties as we scale the number of tasks that execute simultaneously in the system. We start with the base workload and for each of the tasks we add another task with the same characteristics.
US 20120133654 A1 teaches The medium allows enabling larger scaled finer grained parallelism of computation tasks by segmenting programmatic work-loads into smaller discretized portions that are specified by minimum of two elements.
US 20130188483 A1 teaches escalation interval may indicate an amount of time the monitored resource is allowed to remain overloaded before an overload usage state is escalated. The threshold information may include different escalation intervals for each overload usage state.
US 20130103641 A1 teaches resource utilization drops below yellow threshold) indicating that the yellow alert condition is cancelled. 3) Alert issued when red alert threshold exceeded indicating that application processing engine resource utilization level is at maximum capacity, and although the system is continuing to function reliably with current accepted stream requests, all new content stream requests are to be rejected.
US 20140075029 A1 teaches determine that the usage of the computing resource exceeds a maximum usage indicated by the cluster quota. The data center can then send an alert that usage of the computing resource exceeds the maximum usage.
US 20230176918 A1 teaches ability to have more workloads scheduled and executed at a given time across all tenants. In some scenarios, scheduler 112 has access to an electronic version of the SLA agreement between the operator of cloud computing environment 50 and tenants
US 20230362160 A1 he pre-flight response may include an indication of “approved” (or other similar indication) or “denied” (or other similar indication). If the pre-flight response allows the requested access.
US 8601531 B1 teaches the request and a result of the comparison indicating that the client device is unauthorized to perform the operation on the resource when the comparison of the generated risk score with a threshold risk score of the policy associated with the resource indicates a second risk level associated with the request, the second risk level being greater than the first risk level, and wherein transmitting, by the authorization device, the set of identification factors associated with the request.
US 5996025 A teaches at step 430 the decision is made whether to admit at step 440 or reject at step 450 the new stream as a function of whether the data returned from the table indicates that the available bandwidth of any one of the four critical resources would be exceeded.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LECHI TRUONG whose telephone number is (571)272-3767. The examiner can normally be reached 10-8 PM.
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 Young Kevin can be reached on (571)270-3180. 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.
/LECHI TRUONG/Primary Examiner, Art Unit 2194
Prosecution Insights