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 .
This Office Action is in response to amendment filed on 12/22/2025.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/22/2025 has been entered.
Response to Amendment
By this amendment, claims 1, 10, 13, and 15 are amended. Claims 2 and 4 are canceled. Therefore, claims 1, 3, and 5-21 are pending. Any objections and rejections not repeated below is withdrawn due to Applicant's amendment.
Response to Arguments
Applicant's arguments filed 12/22/2025 have been fully considered but they are not persuasive. Applicant argues in substance:
Claim 13 was rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. Claim 13 has been amended herein to remove the language "or latency sensitivity of the task", thereby overcoming this rejection. Hence, withdrawal of the rejection is respectfully requested.
With regard to point (a), Examiner agrees with Applicant and the 112(a) rejection for claim 13 is withdrawn due to Applicant’s amendments.
1. The Cited References Fail to Teach a Coarse Scheduler Configured to Allocate Container-Level Resources and Create Pods for an Application The Office relies on Ma as teaching a coarse scheduler configured to allocate container-level resources within a cluster. However, Ma does not disclose a scheduler that performs the claimed allocation or pod creation functions. Rather, Ma describes a "container manager 602" that
executes resource allocations determined by another component, the "container scheduler 604." (Ma [0027], [0051 ]-[0052]). Thus, the container manager performs deployment, not allocation. The claimed "coarse scheduler configured to allocate container-level resources" is therefore absent. Further, Ma contains no disclosure of creating "a set of one or more pods for an application in response to receiving the application to be run including a data source to be processed or a location for the application to store results." The notion of a pod is foreign to Ma, which does not employ Kubernetes constructs or any comparable unit of deployment that encapsulates containers.
With regard to point (b), (claim 1 point 1) Examiner disagrees with Applicant as prior art Ma teaches the coarse scheduler ([0051] "...The container manager [i.e. coarse scheduler] may be in communication with the container scheduler to obtain resource allocation for each application (in terms of number of containers and the amount of system resources allocated to each container). The container manager may further be in communication the container workers for carrying out container management...") and allocating container-level resources ([0027] "Each client application may run as one or more independent instances of containers, as shown by the stacks of blocks in 508, 510 and 512. The containers of the client applications may be instantiated in the cluster of container workers..."). Prior art NAIR teaches "a set of one or more pods for an application in response to receiving the application to be run including a data source to be processed or a location for the application to store results" as stated in the previous office action and this Office Action’s 103 rejection below.
Claim 1 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
2. The Office's Reliance on Nair [0024]-[0025] and [0065] Is Misplaced
The Office asserts that Nair discloses pods created to run applications wherein the application has data sources and storage locations for data, citing [0024]-[0025] and [0065]. Applicant respectfully submits that this interpretation misreads Nair and conflates two unrelated layers of functionality, namely Kubernetes deployment architecture and AI data processing …
The Office's interpretation effectively combines unrelated disclosures to create a causal relationship that Nair itself never describes. Nowhere does Nair state or imply that the receipt of an application including a data source triggers pod creation. The data processing operations in [0065] occur after the pod and its containers are deployed, not as a condition for their creation.
Moreover, Nair's reference to "storage resources" in [0024] pertains to infrastructure provisioning, such as persistent volume claims or local storage for container operation, not to "a location for the application to store results" as recited in the claim. The Office's equating of Kubernetes storage configuration with application-level result storage confuses hardware resource allocation with logical data persistence.
With regard to point (c), (claim 1 point 2) Examiner disagrees with Applicant as [0065] of Nair discloses embodiments utilizing cloud based solutions. Furthermore, Nair states [0047] "Returning to FIG. 3, the docker client is what an end-user 303 of docker, communicates with. The docker client can be analogized to a user interface for docker. Thus, the docker client is a middleman between the user and the docker daemon. The docker daemon is what actually executes commands sent to the docker client-like building, running, and distributing containers ... " wherein [0028] "Docker is one example of a container runtime used with a Kubernetes POD, however, other container runtimes could be used.".
Claim 1 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
3. The Cited References Fail to Teach or Suggest Fine-Grain Schedulers Within Containers Communicating With the Coarse Scheduler
The amended claim further recites that "each container comprises its own fine-grain scheduler with its own fine-grain scheduling rules, each fine-grain scheduler configured to schedule in-container processes and communicate with the coarse scheduler to request or release container-level resources based on monitored utilization thresholds.".
With regard to point (d), (claim 1 point 3) Examiner disagrees with Applicant as PARK teaches the amended claim which is stated in this Office Action’s 103 rejection below.
Claim 1 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
4. Pods Configured to Share Resources Between Containers
Applicant acknowledges that Nair discloses that "a POD encapsulates an application container (or, in some cases, multiple containers) that share resources" ([0024]). However, this teaching alone cannot cure the deficiencies discussed above. Nair's disclosure is limited to the pod's internal configuration and does not suggest hierarchical coordination between schedulers or any feedback mechanism involving utilization thresholds. The claimed method as a whole remains unsatisfied.
Moreover, it should be noted that the Office previously rejected the features recited in dependent claim 2, which stated, "The method of claim 1, wherein the fine grain scheduler is configured to communicate with the coarse scheduler." The rejection of claim 2 was internally inconsistent with the mapping presented for independent claim 1. In rejecting claim 1, the Office relied on Park ([0027]-[0028]) as teaching the recited "fine grain scheduler" within each container, based on container-level resource management using Cgroups and Namespaces. However, in rejecting dependent claim 2, the Office reverted to Ma and identified the "container workers" of Ma as the alleged fine-grain schedulers that communicate with the container manager (the alleged coarse scheduler) (see Ma, [0052], Fig. 11). This reinterpretation conflicts with the mapping used for claim 1 and is unsupported by Ma. The "container workers" in Ma merely execute workloads and interface with the container manager through an agent. They do not perform any fine-grained scheduling or contain any scheduling rules comparable to those described in Park. Accordingly, the reliance on Ma for this feature was misplaced.
With regard to point (e), (claim 1 point 4) NAIR is directed to reading on the pod claim limitations which not disclose hierarchical coordination between schedulers or any feedback mechanism involving utilization thresholds. Furthermore, Examiner disagrees with Applicant as prior art Ma's teaching in claim 2 does not conflict with Park's prior art teaching in claim 1. Regarding claim 2, Ma teaches "wherein the fine grain scheduler is configured to communicate with the coarse scheduler" ([0052] "FIG. 11 illustrates, as an example, the interactions between the container manager and the container workers. For example, a container management agent 702 may be installed on each of the container workers as an interface between the container workers and the container manager. The function the container manager may include but is not limited to service deployment 1105, proxy registration 1112, service discovery 1106, load balancing 1108, and container image management 1110 ... ", [0024] " ... All containers running on a computer of the cluster of computers may share the same host operating system and its kernel.") wherein the container manager is interpreted as the coarse scheduler that communicates with container worker (or computer) operating systems (interpreted as fine grain schedulers) to run deployed applications.
Claim 1 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
1. The Cited References Do Not Teach a Coarse Scheduler that Allocates Coarse Blocks of Resources in Response to an Application Request
The Office asserts that Ma teaches allocating coarse blocks of resources to portions of an application based on paragraph [0051]. However, Ma describes a container manager that executes resource allocations predetermined by a separate container scheduler, not a component that performs allocation in response to receiving an application request. In Ma, allocation decisions are made by the container scheduler before the container manager performs deployment. Therefore, Ma's container manager executes a predefined allocation rather than dynamically allocating resources upon an application-level request as required by claim 10. The cited paragraph does not describe the claimed triggering relationship between an application request and coarse-level allocation.
With regard to point (f), (claim 10 point 1) Examiner disagrees with Applicant as prior art Ma teaches [0051] " ... The container manager may be in communication with the container scheduler to obtain resource allocation for each application (in terms of number of containers and the amount of system resources allocated to each container) ... ". Ma teaches obtaining resource allocation for each application which implies that each application does not have a predefined allocation but rather a dynamic allocation of resources upon each application.
Claim 10 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
2. The Office Misapplies Karanasos to the Feature of Allocating Tasks to Queues
The Office relies on Karanasos paragraphs [0055] and [0ll l]-[0113] for teaching allocation of tasks to queues based on queue depth, wait time, or predicted utilization. Those passages describe a resource manager (RM) that selects nodes for task placement using a "queuingScore" function. The score evaluates node affinity and node load to decide which node receives a task. Nowhere does Karanasos disclose allocating tasks to queues or determining queue characteristics such as queue depth or wait time as inputs to allocation. The RM in Karanasos manages node assignment, not queue management. Moreover, Karanasos computes instantaneous node load values, not forward-looking predicted utilization as recited in claim 10. The Office therefore mischaracterizes Karanasos; it teaches node selection, not queue-based allocation using predictive utilization.
With regard to point (g), (claim 10 point 2) Examiner disagrees with Applicant as, under BRI, prior art Karanasos teaches assigning tasks to queues associated to nodes. Karanasos discloses calculating a queuingScore based on different strategies such as queue length ([0112] "Based on queue length: Simple information that each node may publish is the size of its queue. This strategy assigns a higher score to nodes with smaller queue lengths ... ") and queue wait time ([0113] "Based on queue wait time: This strategy assumes that each node publishes information about the estimated time a task will have to wait at a node before starting its execution, as described below. The lower this estimated wait time is, the higher the score of the node ... "). Thus, Karanasos teaches queue-based allocation.
Claim 10 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
3. The Cited Combination Fails to Teach Assigning Nodes to Queues with Tasks
The Office cites Karanasos paragraph [0111] for assigning nodes to queues. In Karanasos, a node is selected to execute a task; there is no disclosure of a system that first forms task queues and then assigns nodes to those queues. The claimed relationship between queues and nodes is reversed relative to Karanasos. Consequently, the cited art lacks the claimed structural association between queues and nodes.
With regard to point (h), (claim 10 point 3) Examiner disagrees with Applicant as, under BRI, prior art Karanasos teaches assigning tasks to queues associated to nodes. In other words, nodes are assigned to queues with tasks.
Claim 10 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
4. The Office's Reliance on Ma and Watt Does Not Establish Monitoring of Queue Length and Utilization or Hierarchical Resource Requests
The Office contends that Ma and Watt together teach monitoring queue length and resource utilization and requesting additional resources from a coarse scheduler when a threshold is exceeded. This interpretation is incorrect.
Ma only describes a container manager that "examines resource usage" among container workers. It does not monitor queue length or make threshold-based resource requests. Resource allocation in Ma occurs through communication between the container manager and container scheduler as part of container deployment, not through continuous monitoring and feedback.
Watt discloses a workload optimization subsystem that compares job queue information to static "container generation conditions." These conditions are fixed thresholds that trigger the creation of additional containers within the same subsystem. Watt does not involve a coarse scheduler and does not coordinate multiple hierarchical schedulers. Its thresholds are simple numerical limits rather than dynamic utilization metrics that evolve over time. Combining Ma and Watt would still fail to produce the claimed feature because neither reference teaches dual-parameter monitoring (queue length and utilization) or hierarchical resource requests.
With regard to point (i), (claim 10 point 4) Examiner disagrees with Applicant as prior art Watt teaches monitoring queue length ([0039] " ... The workload resource optimization subsystem 212 may compare the job queue information to the container generation conditions that may be based on thresholds for a number of jobs in the job queue 308 ... a number of jobs in the job queue 308 per agent pool... ") and utilization ([0044] " ... the container host activation condition may be based on ... a duration that a particular container host utilization is above a container host utilization threshold, and/or other container host thresholds/conditions that would be apparent to one of skill in the art in possession of the present disclosure ... ") and thus also disclose dynamic utilization metrics that evolve over time.
Claim 10 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
5. The Office's Mapping of Ma to the Feature of Initiating Fine-Grain Processes Is Incorrect
The Office equates Ma's container instances with the claimed "fine-grain processes." This is inaccurate. In Ma, each container is a coarse resource partition that runs a full client application instance. The claimed system initiates fine-grain processes-sub-tasks created by a fine-grain scheduler within a node-in response to detected resource availability. Ma provides no disclosure of process-level sub-task scheduling within a node. The container manager in Ma launches containers, not fine-grain processes, and does so based on pre-allocated resources rather than in response to dynamic resource availability.
With regard to point (j), (claim 10 point 5) Examiner disagrees with Applicant as prior art Ma teaches deploying containers using corresponding application images (fine grain processes) on container workers (nodes). The deployment occurs based on comparing resource usage (resource availability) of the container workers and the resource allocation information of a container using an application image.
Claim 10 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
6. The Office Mischaracterizes Ma as Teaching Optimal Node Selection by a Fine-Grain Scheduler
Paragraph [0052] of Ma describes the container manager choosing container workers for deployment. The decision is procedural, based on available hardware, and does not involve optimization among nodes by a fine-grain scheduler. The claimed system, in contrast, requires the fine-grain scheduler to spawn multiple fine-grain processes and then select an optimal node from a set of available nodes for execution. Ma contains no concept of a fine-grain scheduler or an optimization step performed at a sub-task level. The Office's mapping conflates deployment with scheduling optimization.
With regard to point (k), (claim 10 point 6) Examiner disagrees with Applicant as prior art Ma teaches the fine-grain scheduler wherein Examiner interprets the container manager of [0052] as the fine-grain scheduler. The optimization step is also present wherein the container manager of [0052] chooses to deploy a container using the corresponding application image (a fine grain process) on a host container worker (a node) based on the resource usage of the container workers and the resource allocation information of the container.
Claim 10 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
7. The Cited References Do Not Teach the Predictive Feedback Feature of Element (vi)
The Office asserts that Ma paragraph [0050] teaches maintaining historical performance data and predicting future resource needs. That interpretation misreads Ma. The cited passage describes a random forest predictor that forecasts aggregate workload parameters such as CPU or memory usage at a future time. The output is communicated to the container scheduler, which statically adjusts container allocations. The predictor in Ma is not coupled to real-time queue or utilization monitoring and does not operate as a continuous feedback engine. There is no integration between historical data, current utilization information, and scheduling adjustment.
Claim 10 recites a prediction engine based on historical training data and current utilization levels that continuously monitors queue length and utilization to predict future resource needs and adjust scheduling decisions. Neither Ma, Karanasos, nor Watt teaches or suggests this adaptive, feedback-driven scheduling model. Watt performs reactive scaling without any predictive component, and Karanasos does not use historical data or a prediction engine at all.
With regard to point (l), (claim 10 point 7) Examiner disagrees with Applicant as Ma teaches the amended claim which is stated in this Office Action’s 103 rejection below.
Claim 10 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
Although patentably distinct, independent claim 15 as amended recites at least some subject matter similar to subject matter recited in claim 10 and is therefore patentable for at least some of the same reasons. Further, claim 15 recites separately patentable subject matter.
In view of the above remarks, Applicant respectfully submits that the rejection of claims 1, 10 and 15 under35 U.S.C. § 103 was improper and/or has been overcome and should be withdrawn.
With regard to point (m), regarding claim 15, as it is a method claim whose limitations are substantially the same as those of claim 10. Accordingly, Applicant's arguments are answered for substantially the same reasons.
Claim 15 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
The cited combination of Ma, Karanasos, and Watt fails to teach or suggest the recited feature that "the resource requirements of each task include one or more of: (i) a type of compute resource required by the task, including CPU, GPU, or memory; (ii) an amount of each compute resource required; or (iii) an execution mode of the task, including whether the task is to be run in interactive or batch mode." The passages of Karanasos cited by the Office, including paragraphs [0055] and [0lll]-[0113], merely describe how a resource manager selects nodes for tasks based on runtime metrics such as queue length, node load, or data locality. These parameters reflect the current state of the system, not task-declared resource requirements. Karanasos lacks any disclosure of tasks defining their own compute resource types, resource quantities, or operational modes. The cited combination therefore does not teach a system in which each task includes predefined attributes that inform scheduling decisions.
With regard to point (n), regarding claim 13, Karanasos discloses [0055] “…The RM may then choose where to place the tasks based on a policy (such as resource availability, status of queues at the NMs, data locality, etc.)…” and [0111] “Algorithm 1 takes as input a task t and outputs the node n where t should be placed. Yaq may preferentially place tasks at nodes that have available resources since such tasks will incur no queuing delays…”. Karanasos [0111] describes an input task that which is placed on a node with available resources. Thus, there must be a comparison between task-declared resource requirements and available node resources.
Claim 13 and all its dependent claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 5, and 7-9 are rejected under 35 U.S.C. 103 as being unpatentable over MA et al. Pub. No. US 2019/0286486 Al (hereafter Ma) in view of NAIR et al. Pub. No. US 2020/0167234 Al (hereafter NAIR), and further in view of PARK et al. Pub. No. US 2021/0191751 Al (hereafter PARK).
Regarding claim 1, Ma teaches a method for scheduling tasks in a computing system, the method comprising: creating a coarse scheduler configured to allocate container level resources within a cluster (Paragraph 0051, “…Staying now with FIG. 6, the container manager computer cluster 602 (also referred as container manager) [i.e. coarse scheduler] may comprise one or more computers. These computers may be dedicated to the function of container management. Alternatively, container management function may be encapsulated in software running on the computers where container management is only part of their overall function. The container manager may be in communication with the container scheduler to obtain resource allocation for each application (in terms of number of containers and the amount of system resources allocated to each container). The container manager may further be in communication the container workers for carrying out container management…”, [0027] “Each client application may run as one or more independent instances of containers, as shown by the stacks of blocks in 508, 510 and 512. The containers of the client applications may be instantiated in the cluster of container workers…”) … creating one or more containers for the application, in response to the coarse scheduler allocating container level resources ([0052] “…The container manager [i.e. coarse scheduler] may deploy the containers according to the resource allocation information obtained from the container scheduler. The container manager may examine the resource usage among the container workers and determine for each container its host container worker and instantiate the container…”)…
Ma fails to teach … create a set of one or more pods for an application, in response to receiving the application to be run including a data source to be processed by the application or a location for the application to store results … wherein each container is contained within one of the pods, and each pod is configured to share computing system resources between containers within the pod.
In analogous art NAIR teaches … create a set of one or more pods for an application ([0025] “Each POD is intended to run a single instance of a given application. To scale an application horizontally (e.g., run multiple instances), multiple PODs may be used…”), in response to receiving the application to be run including a data source to be processed by the application or a location for the application to store results ([0065] “…Embodiments herein can examine data from diverse data sources such as data sources that process radio or other signals for location determination of users. Embodiments herein can include artificial intelligence processing platforms featuring improved processes to transform unstructured data into structured form permitting computer based analytics and decision making. Embodiments herein can include particular arrangements for both collecting rich data into a data repository and additional particular arrangements for updating such data and for use of that data to drive artificial intelligence decision making.”) … wherein each container is contained within one of the pods, and each pod is configured to share computing system resources between containers within the pod ([0024] “…A POD encapsulates an application container (or, in some cases, multiple containers) and includes storage resources, a unique network IP, and options that govern how the container(s) should run. A POD represents a unit of deployment: a single instance of an application in Kubernetes, which might consist of either a single container or a small number of containers that are tightly coupled and that share resources.”).
It would have been obvious to a person having ordinary skill in the art prior to the
effective filing date of the claimed invention to have modified Ma to incorporate
the teachings of NAIR to deploy a unit of deployment that comprises of containers which share resources (NAIR [0024] “…A POD represents a unit of deployment: a single instance of an application in Kubernetes, which might consist of either a single container or a small number of containers that are tightly coupled and that share resources.”).
Ma and NAIR fail to teach wherein each container comprises its own fine grain scheduler with its own fine grain scheduling rules, each fine grain scheduler configured to schedule in-container processes and communicate with the coarse scheduler to request or release container-level resources based on monitored utilization thresholds.
In analogous art PARK teaches wherein each container comprises its own fine grain scheduler with its own fine grain scheduling rules, each fine grain scheduler configured to schedule in-container processes ([0027] “…Container refers to an independent system that is configured to allocate resources to an application process through Cgroups and is virtualized in an OS isolated through Namespace…”, [0028] “A container may allocate computing resources to each application by using Cgroups according to a resource allocation policy. Cgroups may create a process group and allocate and manage resources to allocate host resources to a process in an OS … Accordingly, the container may limit CPU usage, memory usage, etc. by using Cgroups of a Linux kernel…”, Note: Each container contains different processes and thus different cgroups (fine grain schedulers) allocating resources based on different resource allocation policies (fine grain scheduling rules)) and communicate with the coarse scheduler to request or release container-level resources based on monitored utilization thresholds ([0052] “In a block 2004, the host device according to an embodiment may monitor the amount of resources used when services are provided by the plurality of containers…”, [0053] “In a block 2005, the host device according to an embodiment may dynamically recalculate resources to be allocated to the plurality of containers by reflecting the amount of resources used by the plurality of containers. For example, waste of network resources may be reduced by distributing resources already allocated to a container to another container.”, Note: The host device is interpreted as the coarse scheduler).
It would have been obvious to a person having ordinary skill in the art prior to the
effective filing date of the claimed invention to have modified Ma and NAIR to incorporate the teachings of PARK to dynamically allocate resources to containers based on network performance and different executing services (PARK [0005] “…dynamically allocating resources to a plurality of containers in consideration of network performance of a plurality of containers providing different services in an IoT environment.”).
Regarding claim 3, Ma, NAIR, and PARK teach the method of claim 1, and Ma further teaches wherein the fine grain scheduler is configured to implement a different set of allocation rules than the coarse scheduler (Paragraph 0024, “…All containers running on a computer of the cluster of computers may share the same host operating system [i.e. fine grain scheduler] and its kernel…”, paragraph 0051, “…The container manager [i.e. coarse scheduler] may be in communication with the container scheduler to obtain resource allocation for each application (in terms of number of containers and the amount of system resources allocated to each container). The container manager may further be in communication the container workers for carrying out container management…”, Note: The host operating system schedules portions of an application based on container resource allocations, while the container manager schedules the entire application (provisions all containers associated with the application)).
Regarding claim 5, Ma, NAIR, and PARK teach the method of claim 1, and NAIR further teaches wherein each container is managed by a Kubernetes container orchestration platform ([0024] “…A POD represents a unit of deployment: a single instance of an application in Kubernetes, which might consist of either a single container or a small number of containers…”).
Regarding claim 7, Ma, NAIR, and PARK teach the method of claim 1, and Ma further teaches wherein the coarse scheduler is configured based on historical performance data collected from prior runs of the application (Paragraph 0050, “Returning now to FIG. 6, once the resource usage for a client application at a future time, such as number of user request, CPU usage, and memory usage, is predicted by the random forest developed from the modified RFR predictor above or in FIG. 6, predicted resource usage may be communicated to the container scheduler 604 of FIG. 6. The container scheduler 604 may be responsible for converting the resource usage output of the predictor into system resource allocation including a number of containers to be instantiated and CPU/memory allocation for each container. Alternatively, only a number of containers to be added or removed and CPU/memory allocation adjustment are determined by the scheduler.”, paragraph 0051, “…The container manager [i.e. coarse scheduler] may be in communication with the container scheduler to obtain resource allocation for each application (in terms of number of containers and the amount of system resources allocated to each container). The container manager may further be in communication the container workers for carrying out container management…”).
Regarding claim 8, Ma, NAIR, and PARK teach the method of claim 1, and Ma further teaches wherein the fine grain scheduler is configured based on historical performance data collected from prior runs of the application (Paragraph 0050, “Returning now to FIG. 6, once the resource usage for a client application at a future time, such as number of user request, CPU usage, and memory usage, is predicted by the random forest developed from the modified RFR predictor above or in FIG. 6, predicted resource usage may be communicated to the container scheduler 604 of FIG. 6. The container scheduler 604 may be responsible for converting the resource usage output of the predictor into system resource allocation including a number of containers to be instantiated and CPU/memory allocation for each container. Alternatively, only a number of containers to be added or removed and CPU/memory allocation adjustment are determined by the scheduler.”, paragraph 0051, “…The container manager [i.e. coarse scheduler] may be in communication with the container scheduler to obtain resource allocation for each application (in terms of number of containers and the amount of system resources allocated to each container). The container manager may further be in communication the container workers for carrying out container management…”, Note: The allocation of system resources to each container is a prediction by the coarse scheduler and other system components, therefore it will also affect each fine grain scheduler’s allocation of resources to containers).
Regarding claim 9, Ma, NAIR, and PARK teach the method of claim 1, and Ma further teaches further comprising creating a plurality of coarse host processes and a plurality of fine grain processes (Paragraph 0024, “…Rather, the client may request a number of containers 404 for deploying the service application…”, Note: Course host processes may be all the functions performed in order to provision the application into smaller fine grain processes which are executed within containers).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over MA et al. Pub. No. US 2019/0286486 Al (hereafter Ma) in view of NAIR et al. Pub. No. US 2020/0167234 Al (hereafter NAIR), further in view of PARK et al. Pub. No. US 2021/0191751 Al (hereafter PARK) as applied to claims 1, 3, 5, and 7-9 above, and further in view of Singh et al. Pub. No. US 2016/0162320 Al (hereafter Singh).
Regarding claim 6, Ma, NAIR, and PARK teach the method of claim 1.
Ma, NAIR, and PARK fail to teach wherein the computing system resources comprise CPUs and GPUs.
In analogous art Singh teaches wherein the computing system resources comprise CPUs and GPUs (Paragraph 0076, “…The hosts 342 may be equipped with any needed processing capability, including one or more processors, such as a central processing unit, a graphics processing unit…”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Ma, NAIR, and PARK to incorporate the teachings of Singh to allow the two-tiered scheduler to execute a variety of different tasks (Singh Paragraph 0076, “…Each of the hosts 342 may be any device or equipment configured to execute instructions for performing data computation, manipulation, or storage tasks, such as a computer or a server…”).
Claims 10, 12-15, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over MA et al. Pub. No. US 2019/0286486 Al (hereafter Ma) in view of KARANASOS et al. Pub. No. US 2018/0300174 Al (hereafter KARANASOS), and further in view of Watt, JR. et al. Pub. No. US 2018/0225155 Al (hereafter Watt).
Regarding claim 10, Ma teaches a system, comprising: a memory including computer readable instructions; at least one processor configured to execute the computer readable instructions to ([0022] “…The memories 211 store, for example, instructions that the processors 302 may execute to carry out desired functionality for providing IaaS to clients…”): allocate coarse blocks of resources to portions of an application that is to be executed, in response to receiving a request to execute the application (Paragraph 0051, “…Staying now with FIG. 6, the container manager computer cluster 602 (also referred as container manager) [i.e. coarse scheduler] may comprise one or more computers. These computers may be dedicated to the function of container management. Alternatively, container management function may be encapsulated in software running on the computers where container management is only part of their overall function. The container manager may be in communication with the container scheduler to obtain resource allocation for each application (in terms of number of containers and the amount of system resources allocated to each container). The container manager may further be in communication the container workers for carrying out container management…”); and … (iv) initiate one or more fine grain processes, in response to detecting resource availability within an assigned node (Paragraph 0027: “Each client application may run as one or more independent instances of containers, as shown by the stacks of blocks in 508, 510 and 512…”, Paragraph 0052: “…The container manager may examine the resource usage among the container workers and determine for each container its host container worker and instantiate the container using the corresponding application image…”, Fig. 5, Note: Application instances [i.e. fine grain processes]), (v) select an optimal node from a set of available nodes for the one or more fine grain processes to run on, in response to a fine grain scheduler spawning multiple fine grain processes (Paragraph 0052: “…The container manager may deploy the containers according to the resource allocation information obtained from the container scheduler. The container manager may examine the resource usage among the container workers and determine for each container its host container worker and instantiate the container using the corresponding application image…”), and (vi) maintain historical performance data for processes of different applications and, in response to monitoring current queue length and utilization and applying a prediction engine based on historical training data and current utilization levels, predict future resource needs and adjust scheduling decisions accordingly (Paragraph 0050, “Returning now to FIG. 6, once the resource usage for a client application at a future time, such as number of user request, CPU usage, and memory usage, is predicted by the random forest developed from the modified RFR predictor above or in FIG. 6, predicted resource usage may be communicated to the container scheduler 604 of FIG. 6. The container scheduler 604 may be responsible for converting the resource usage output of the predictor into system resource allocation including a number of containers to be instantiated and CPU/memory allocation for each container. Alternatively, only a number of containers to be added or removed and CPU/memory allocation adjustment are determined by the scheduler.”, paragraph 0051, “…The container manager may be in communication with the container scheduler to obtain resource allocation for each application (in terms of number of containers and the amount of system resources allocated to each container). The container manager may further be in communication the container workers for carrying out container management…”, [0036] “The run-time data message queues 702 may comprise multiple separate queues from queue 1 to queue L, each for one client application…”, [0037] “Run-time data messages aggregated according to client applications 1 to L may then be processed by a run-time message processing engine 704 of FIG. 7 to extract and format data into forms that may be used in predictive modeling based on machine learning algorithms…”, Note: The predictor is interpreted as the prediction engine which uses the number of messages/requests of run-time data message queues of client applications and resource usage of client applications to predict container resource allocation).
Ma fails to teach (i) allocate tasks to queues based on a combination of resource requirements of each task and characteristics of the queues, the characteristics of the queues including one or more one of: queue depth, wait time, or predicted utilization, (ii) assign nodes to the queues with tasks…
In analogous art KARANASOS teaches (i) allocate tasks to queues based on a combination of resource requirements of each task and characteristics of the queues, the characteristics of the queues including one or more one of: queue depth, wait time, or predicted utilization ([0055] “…The RM may then choose where to place the tasks based on a policy (such as resource availability, status of queues at the NMs, data locality, etc.)…”, [0111] “Algorithm 1 takes as input a task t and outputs the node n where t should be placed. Yaq may preferentially place tasks at nodes that have available resources since such tasks will incur no queuing delays … If the cluster is almost fully loaded (as defined by the Rfmin parameter given as input), a node with a high with highest queuingScore is chosen to place t (line 3). The function queuingScore (n,t) is used to quantify how suitable a node n is for executing t. The score of a node comprises two components: a node affinity for t and a node load … The load of a node may be calculated based on one of the following strategies depending on the richness, completeness, and granularity of the information published by each node:”, [0112] “Based on queue length: Simple information that each node may publish is the size of its queue. This strategy assigns a higher score to nodes with smaller queue lengths…”, [0113] “Based on queue wait time: This strategy assumes that each node publishes information about the estimated time a task will have to wait at a node before starting its execution, as described below. The lower this estimated wait time is, the higher the score of the node…”), (ii) assign nodes to the queues with tasks ([0111] “Algorithm 1 takes as input a task t and outputs the node n where t should be placed. Yaq may preferentially place tasks at nodes that have available resources since such tasks will incur no queuing delays…”)…
It would have been obvious to a person having ordinary skill in the art prior to the
effective filing date of the claimed invention to have modified Ma to incorporate the teachings of KARANASOS to achieve high cluster resource utilization and low job completion times (KARANASOS [0039] “Introduced are techniques that dictate how queues at worker nodes can be maintained in order to achieve both high cluster resource utilization and low job completion times…”).
Ma and KARANASOS fail to teach …(iii) monitor each queue length associated with the assigned nodes and the resource utilization of those nodes and request additional resources from a coarse scheduler when a queue length or resource utilization of the assigned nodes exceeds a corresponding threshold value…
In analogous art Watt teaches …(iii) monitor each queue length associated with the assigned nodes and the resource utilization of those nodes and request additional resources from a coarse scheduler when a queue length or resource utilization of the assigned nodes exceeds a corresponding threshold value (Paragraph 0039, “…For example, the workload resource optimization subsystem 212 may include a plurality of predetermined container generation conditions that indicate whether the jobs generated by the workload manager subsystem 202 are being processed according to a desired standard and, if not, whether the agent infrastructure subsystem 204 requires more containers with more agents to process the jobs in the job queue of the workload manager subsystem 202. The workload resource optimization subsystem 212 may compare the job queue information to the container generation conditions that may be based on thresholds for a number of jobs in the job queue 308…a number of jobs in the job queue 308 per agent pool…”, paragraph 0041, “…At block 706, the workload resource optimization subsystem 212 may provide the container instructions that identify an agent pool that needs a new container and agent to process the job(s) in the job queue 308, and provide instructions to generate a new container to the agent infrastructure subsystem 204.”, Fig. 7)…
It would have been obvious to a person having ordinary skill in the art prior to the
effective filing date of the claimed invention to have modified Ma and KARANASOS to incorporate the teachings of Watt to decrease resources used for the container, container host, and container agent resource provisioning process (Watt Paragraph 0033, “…a workload optimization system that includes a workload resource optimization subsystem that monitors and manages a workload manager subsystem that creates and manages jobs generated by workloads, and an agent infrastructure subsystem that includes one or more agents that process those jobs. The workload resource optimization engine uses job queue information from the workload manager subsystem to scale up and scale down container hosts and/or containers hosted by the container hosts…By implementing scaling of containers and container hosts, information technology departments can substantially reduce their hardware footprints by requiring less hardware resources to provision customized agents that can process a variety of different jobs, while simultaneously reducing job queue times at the workload manager subsystem, as well as agent provisioning times.”).
Regarding claim 12, Ma, KARANASOS, and Watt teach the system of claim 10, and Ma further teaches wherein the at least one processor is further configured to apply a resource allocation policy based on resource availability and capabilities (Paragraph 0024, “…All containers running on a computer of the cluster of computers may share the same host operating system [i.e. fine grain scheduler] and its kernel…”, paragraph 0051, “…The container manager [i.e. coarse scheduler] may be in communication with the container scheduler to obtain resource allocation for each application (in terms of number of containers and the amount of system resources allocated to each container)…”, Note: The host operating system [i.e. fine grain scheduler] schedules resources to containers based on resources provisioned by the container manager [i.e. coarse scheduler]).
Regarding claim 13, Ma, KARANASOS, and Watt teach the system of claim 10, and KARANASOS further teaches resource requirements of each task include one or more of: (i) a type of compute resource required by the task, including CPU, GPU, or memory; (ii) an amount of each compute resource required; or (iii) an execution mode of the task, including whether the task is to be run in interactive or batch mode ([0055] “…The RM may then choose where to place the tasks based on a policy (such as resource availability, status of queues at the NMs, data locality, etc.)…”, [0111] “Algorithm 1 takes as input a task t and outputs the node n where t should be placed. Yaq may preferentially place tasks at nodes that have available resources since such tasks will incur no queuing delays…”, Note: Amounts of compute resources required by the task are compared to nodes when tasks are placed).
Regarding claim 14, Ma, KARANASOS, and Watt teach the system of claim 10, and Ma further teaches wherein the at least one processor applies a resource allocation policy further based on per description or historical/prediction data (Paragraph 0050, “Returning now to FIG. 6, once the resource usage for a client application at a future time, such as number of user request, CPU usage, and memory usage, is predicted by the random forest developed from the modified RFR predictor above or in FIG. 6, predicted resource usage may be communicated to the container scheduler 604 of FIG. 6. The container scheduler 604 may be responsible for converting the resource usage output of the predictor into system resource allocation including a number of containers to be instantiated and CPU/memory allocation for each container. Alternatively, only a number of containers to be added or removed and CPU/memory allocation adjustment are determined by the scheduler.”, paragraph 0051, “…The container manager [i.e. coarse scheduler] may be in communication with the container scheduler to obtain resource allocation for each application (in terms of number of containers and the amount of system resources allocated to each container). The container manager may further be in communication the container workers for carrying out container management…”, Note: The allocation of system resources to each container is a prediction by the coarse scheduler and other system components, therefore it will also affect each fine grain scheduler’s allocation of resources to containers).
Regarding claim 15, it is a method claim whose limitations are substantially the same as those of claim 10. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 21, Ma, KARANASOS, and Watt teach the system 10, and Ma further teaches wherein the optimal node is based on specified requirements of the tasks and selected using one or more fine grain scheduler priorities (Paragraph 0052: “…The container manager may deploy the containers according to the resource allocation information obtained from the container scheduler. The container manager may examine the resource usage among the container workers and determine for each container its host container worker and instantiate the container using the corresponding application image…”).
Claims 11, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over MA et al. Pub. No. US 2019/0286486 Al (hereafter Ma) in view of KARANASOS et al. Pub. No. US 2018/0300174 Al (hereafter KARANASOS), further in view of Watt, JR. et al. Pub. No. US 2018/0225155 Al (hereafter Watt) as applied to claims 10, 12-15, and 21 above, and further in view of Kambatla Pub. No. US 2018/0074855 Al.
Regarding claim 11, Ma, KARANASOS, and Watt teach the system of claim 10.
Ma, KARANASOS, and Watt fail to teach wherein the at least one processor is further configured to request additional coarse blocks of resources if available resources fall below a second threshold.
However, in analogous art Kambatla teaches wherein the at least one processor is further configured to request additional coarse blocks of resources if available resources fall below a second threshold (Paragraph 0057, “…For example, in an embodiment, the scheduler 340a may only allocate an opportunistic second tier container if the actual resource utilization is below an allocation threshold. In other words, the scheduler 340a may only allocate an opportunistic container to process a task if the worker node has available unused resources to process the task…”, Fig. 4).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Ma, KARANASOS, and Watt to incorporate the teachings of Kambatla and provide a two-tiered scheduling invention that monitors and requests additional resources if node resources decrease below a threshold. Doing so would decrease resource contention and increase the computing system’s performance (Kambatla Paragraph 0017, “…Oversubscription can become untenable when tasks simultaneously start using more resources, potentially leading to performance degradation, and even task failures. To address this problem, UBIS can preempt opportunistic containers to ease resource contention….”).
Regarding claim 16, it is a method claim whose limitations are substantially the same as those of claim 11. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 18, Ma, KARANASOS, Watt, and Kambatla teach the method of claim 16, and Watt further teaches further comprising monitoring utilization levels (Paragraph 0036, “…For example, the container host engine 505/603 may communicate container host [i.e. node] utilization information to the workload resource optimization engine 404 such as a number of containers per host operating system, a rate of job processing, a number of active container hosts on the agent infrastructure subsystem 204, a number of agents per agent pool, physical resource utilization of the agent infrastructure subsystem 204 and/or the container host 206…”).
Claims 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over MA et al. Pub. No. US 2019/0286486 Al (hereafter Ma) in view of KARANASOS et al. Pub. No. US 2018/0300174 Al (hereafter KARANASOS), further in view of Watt, JR. et al. Pub. No. US 2018/0225155 Al (hereafter Watt), further in view of Kambatla Pub. No. US 2018/0074855 Al as applied to claims 11, 16, and 18 above, and further in view of Zur et al. Pub. No. US 2020/0167199 Al (hereafter Zur).
Regarding claim 17, Ma, KARANASOS, Watt, and Kambatla teach the method of claim 16.
Ma, KARANASOS, Watt, and Kambatla fail to teach predicting when additional coarse blocks of resources may be needed; and performing a request in response thereto.
However, in analogous art Zur teaches predicting when additional coarse blocks of resources may be needed; and performing a request in response thereto (Paragraph 0042, “…Service Controller 100 may communicate with Prediction Modeling Service 112 to predict future infrastructure needs…”, paragraph 0043, “Prediction Modeling Service 112 may be configured for predicting future requirements of the executed applications…The prediction may be provided statically, based for example on user defined parameters, indicating number of units of various resources to be reserved, percentage of the current resource consumption, or the like. Additionally or alternatively, the prediction may be made dynamically, and may use predictive models of future infrastructure needs, based on past usage data of Container Orchestrator 104 and container scheduler 108...”, paragraph 0046, “In some exemplary embodiments, Service Controller 100 may simulate the behavior of Container Orchestrator 104 for orchestrating all containers (e.g., 132, 136) as well as Headroom Containers 138, on the infrastructure available by Cloud Management Platform 124, to determine whether all containers can be scheduled with the currently available infrastructure, and a proposed deployment plan thereof. If not all requirements can be met, it may be determined that additional infrastructure is required to ensure the application can scale when required. In some exemplary embodiments, Service Controller 100 may issue a request comprising the expected extra infrastructure to Cloud Management Service 116...”, Fig. 2).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Ma, KARANASOS, Watt, and Kambatla to incorporate the teachings of Zur and provide a two-tiered scheduling invention that predicts when additional resources are needed to run an application. Doing so would decrease latency and maintain a standard of quality service (Zur Paragraph 0023, “One technical solution comprises predicting and pre-provisioning additional infrastructure for containers, before capacity exhaustion is encountered. If sufficient infrastructure is available once it is needed, the system can scale quickly, thus reducing latency and maintaining the quality of service…”).
Regarding claim 19, Ma, KARANASOS, Watt, and Kambatla teach the method of claim 18.
Ma, KARANASOS, Watt, and Kambatla fail to teach predicting when additional coarse blocks of resources may be needed; and performing a request in response thereto.
However, in analogous art Zur teaches predicting when additional coarse blocks of resources may be needed based on current and historical utilization levels; and performing a request in response thereto (Paragraph 0042, “…Service Controller 100 may communicate with Prediction Modeling Service 112 to predict future infrastructure needs…”, paragraph 0043, “Prediction Modeling Service 112 may be configured for predicting future requirements of the executed applications…The prediction may be provided statically, based for example on user defined parameters, indicating number of units of various resources to be reserved, percentage of the current resource consumption, or the like. Additionally or alternatively, the prediction may be made dynamically, and may use predictive models of future infrastructure needs, based on past usage data of Container Orchestrator 104 and container scheduler 108...”, paragraph 0046, “In some exemplary embodiments, Service Controller 100 may simulate the behavior of Container Orchestrator 104 for orchestrating all containers (e.g., 132, 136) as well as Headroom Containers 138, on the infrastructure available by Cloud Management Platform 124, to determine whether all containers can be scheduled with the currently available infrastructure, and a proposed deployment plan thereof. If not all requirements can be met, it may be determined that additional infrastructure is required to ensure the application can scale when required. In some exemplary embodiments, Service Controller 100 may issue a request comprising the expected extra infrastructure to Cloud Management Service 116...”, Fig. 2).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Ma, KARANASOS, Watt, and Kambatla to incorporate the teachings of Zur and provide a two-tiered scheduling invention that predicts when additional resources are needed to run an application. Doing so would decrease latency and maintain a standard of quality service (Zur Paragraph 0023, “One technical solution comprises predicting and pre-provisioning additional infrastructure for containers, before capacity exhaustion is encountered. If sufficient infrastructure is available once it is needed, the system can scale quickly, thus reducing latency and maintaining the quality of service…”).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over MA et al. Pub. No. US 2019/0286486 Al (hereafter Ma) in view of NAIR et al. Pub. No. US 2020/0167234 Al (hereafter NAIR), further in view of PARK et al. Pub. No. US 2021/0191751 Al (hereafter PARK) as applied to claims 1, 3, 5, and 7-9 above, and further in view of Kambatla Pub. No. US 2018/0074855 Al.
Regarding claim 20, Ma, NAIR, and PARK teach the method of claim 1.
Ma, NAIR, and PARK fail to teach further comprising creating one or more master node containers and one or more worker node containers that are configured to communicate with one another.
However, in analogous art Kambatla teaches further comprising creating one or more master node containers and one or more worker node containers that are configured to communicate with one another (Paragraph 0021: “…The example environment 100 includes a plurality of data nodes 124a-c that comprise cluster of worker nodes in in communication (e.g. via computer network) with each other and one or more master nodes…”, Paragraph 0023: “…The central resource manager 108 is a general resource manager configured to manage and arbitrate resources among applications in the system. Communicating with node managers 118a-c which act as the agents at each node, the central resource manager 108 may allocate and schedule resources available at the various nodes based on the available resources reported from each node manager…”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Ma, NAIR, and PARK to incorporate the teachings of Kambatla and provide a two-tiered scheduling invention that contains communicating master and worker nodes. Doing so would decrease resource contention and increase the computing system’s performance (Kambatla Paragraph 0017, “…Oversubscription can become untenable when tasks simultaneously start using more resources, potentially leading to performance degradation, and even task failures. To address this problem, UBIS can preempt opportunistic containers to ease resource contention….”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. In particular, US 20190014059 A1 is cited because it discloses a two-tier scheduling system which includes at least one resource offer manager that offers each scheduler resource offers based on an amount of requested resources, and each scheduler chooses a resource offer for scheduling. In addition, US 2016/0239331 Al is cited because it discloses tasks queued within virtual machines. Further, US 10,303,492 Bl is cited because it discloses one operating system within one container. All 5 NPLs cited on the IDS filed on 01/26/2022 were considered, but they were cited again and rescanned in order to provide clear copies.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN CHE-CHUN TONG whose telephone number is (703)756-1737. The examiner can normally be reached Monday-Thursday: 7:30 AM to 6:00 PM 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, April Y Blair can be reached at (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.
/J.C.T./Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196