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 07/07/2026.
Response to Amendment
By this amendment, claims 7, 9, 18, and 20 are amended. Claims 8 and 19 are canceled. Claims 22-26 are newly added claims. Therefore, claims 1, 3, 5-7, 9-18, and 20-26 are pending. Any objections and rejections not repeated below is withdrawn due to Applicant's amendment.
Response to Arguments
Applicant's arguments filed 07/07/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
Independent Claim 1
…
1. The Cited References Do Not Teach A Coarse Scheduler That Creates Pods
The Office Action alleged that Ma's "container manager" teaches the claimed "coarse scheduler" that allocates container-level resources and creates pods. Applicant respectfully submits that Ma's architecture operates entirely at the container level without any pod abstraction. As Ma explains, "the client may request a number of containers 404 for deploying the service application" and "[a]ll containers running on a computer of the cluster of computers may share the same host operating system and its kernel." (Ma, paragraphs [0024], [0027]). Ma's container manager deploys containers directly to container workers. There is no intermediate pod layer that groups containers together as recited in claim 1.
Nair fails to cure these deficiencies. The Office Action alleged that Nair teaches creating pods in response to receiving an application including a data source or storage location, citing paragraphs [0024]-[0025] and [0065]. Applicant respectfully submits that this interpretation conflates unrelated disclosures. Nair paragraph [0024] merely describes what a POD is generally: "APOD 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."
(Nair, paragraph [0024]). This is a general description of Kubernetes architecture, not a teaching of creating pods in response to receiving an application with a data source or storage location. Nair paragraph [0065]
discusses that" [ e ]mbodiments herein can examine data from diverse data sources such as data sources that process radio or other signals for location determination of users." (Nair, paragraph [0065]). This passage relates to AI data processing capabilities that occur after containers are deployed; not as a condition for their creation. Claim I requires a specific
causal relationship: the coarse scheduler creates pods "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." Neither Ma nor Nair teaches this triggering relationship.
Accordingly, claim I is patentable for at least these reasons.
With regard to point (a), 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...").
Examiner also disagrees with Applicant as [0065] of Nair discloses embodiments utilizing cloud based solutions. Furthermore, Nair states [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…”, [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.”), [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.”. In other words, the pods comprising containers are scaled and created to run an application for data processing from a data source.
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.
Independent Claim 1
…
2. Office acknowledges that Ma and NAIR fail to teach, describe, or suggest a fine grain scheduler and as claimed within the application Applicant acknowledges the Office's statement that "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." (Office Action, Page 21) As such the Office acknowledges that is it not possible for Ma and Nair, individually or in combination, to teach describe, or suggest a method with a course scheduler and a fine grain scheduler in communication "to request or release container-level resources based on monitored utilization thresholds..
With regard to point (b), Examiner disagrees with Applicant as prior 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).
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.
Independent Claim 1
…
3. PARK fails to teach, describe, or suggest the fine grain scheduler as claimed within the application
The presented claims further recite 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."
The Office relies on Park for the fine-grain scheduler. However, Park teaches host-level resource management, not independent per-container schedulers. As described in [0027]-[0028], Park's containers utilize Cgroups and Namespaces to control resource allocation within a Linux
environment. Cgroups provide resource isolation at the kernel level. These mechanisms do not constitute autonomous schedulers that communicate with a higher-level scheduler. Rather, Park's host device performs centralized monitoring and dynamic reallocation ([0071]-[0075]; Figs. 2,
4, 5). The host, not the container, determines when and how resources are reassigned. (Park, paragraphs [0052]-[0053]).
Furthermore, any resource monitoring and allocation found within Park is always performed across a "plurality of containers" within a host device to effectively distribute host device resources ([0052]-[0053]; Figs 7,8). Park teaches away from the claimed fine grain scheduler as it presents a series of weights that determine the distribution of resources across the
plurality of containers ([0068]). These weights present a pre-defined set of calculations and steps that do not replicate the communication mechanism or utilization-based thresholds of the claimed fine grain scheduler.
The Office's interpretation of the host device within Park as a course scheduler still fails to teach, describe, or suggest all of the elements of the claimed fine grain scheduler. The containers found within Park still do not "request or release container-level resources based on monitored utilization thresholds" as claimed within the present application because the containers in Park wholly lack said functionality.
With regard to point (c), Examiner disagrees with Applicant as prior 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). In other words, the container may limit CPU usage, memory usage, etc. by using Cgroups (i.e. fine grain schedulers) to execute an application (i.e. process), and each container’s available resources are dynamically reallocated based on monitored utilizations which are communicated to the host device (coarse scheduler).
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.
Independent Claim 1
…
4. No Motivation to Combine the References
Even assuming arguendo hat the individual elements could be found across the references (which Applicant does not concede), Applicant submits there is no proper motivation to combine them. The references address fundamentally different problems: Ma is directed to machine learning-based prediction for container resource allocation; Nair is directed to container image stability and recovery when containers fail; and Park is directed to IoT network resource allocation at the host level. The claimed subject matter addresses a different problem: enabling hierarchical multi-level scheduling where fine-grain schedulers within containers independently manage in-container processes and communicate with a coarse scheduler to request or release resources based on utilization thresholds.
Combining Ma's container manager with Nair's Kubemetes pods and Park's host-level resource monitoring would not yield the claimed hierarchical scheduling architecture where each container has its own fine-grain scheduler that communicates with the coarse scheduler. The references would need to be fundamentally restructured, not merely combined, to arrive at the claimed invention, which constitutes impermissible hindsight reconstruction.
With regard to point (d), in response to applicant's argument that prior arts Ma, Nair, and Park are nonanalogous arts, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, prior arts Ma, Nair, and Park all relate to the field of virtual resource allocation.
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
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.
Claim 3
The cited combination of Ma, Nair, and Park fails to teach or suggest the claimed method as amended. In particular, none of the cited references disclose or render obvious "wherein the fine grain scheduler is configured to implement a different set of allocation rules than the course scheduler.".
For the same reasons as presented for claim 1, all cited combinations of Ma, Nair, and/or Park would wholly fail to teach, describe, or suggest the creation of a containers with the claimed functionality of the fine grain scheduler within claim 1. Therefore, without the functionality of the fine course scheduler within claim 1 none of the cited references, alone or in combination, can teach, describe, or suggest different set of allocation rules as well.
With regard to point (e), Examiner disagrees with Applicant with same reasoning above in point (d). 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.
Claim 6
1. Office acknowledges that Ma and NAIR fail to teach, describe, or suggest a fine grain scheduler and as claimed within the application Applicant acknowledges the Office's statement that "Ma, NAIR, and PARK fail to teach wherein the computing system resources comprise CPUs and GPUs." (Office Action, Page 25) As such the Office acknowledges that is it not possible for Ma, Nair, and Park, individually or in combination, to teach describe, or suggest a method "wherein the computing system resources comprise CPUs and GPUs."
2. Any combination of Ma, Nair, Park, and Singh still fails to teach, describe, or suggest the claimed elements of the present application. For the same reasons as presented for claim 1, all cited combinations of Ma, Nair, and/or Park would wholly fail to teach, describe, or suggest the creation of a containers with the claimed functionality of the fine grain scheduler within claim 1. Therefore, without the functionality of the fine course scheduler within claim 1 none of the cited references, alone or in combination, can teach, describe, or suggest the method wherein the computing system resources comprise CPUs and GPUs.
With regard to point (f), Examiner disagrees with Applicant as 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…”). Examiner also disagrees with Applicant regarding the functionality of the fine grain scheduler with same reasoning above in point (d). 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.
Claim 9
…
Claim 20
…
New Claim 22
…
New claim 23
…
New Claim 24
…
New Claim 25
…
New Claim 26
With regard to point (g), all amended or new claims have been addressed in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
Independent Claim 10
…
2. The Office continues to misapply Karanos to the Feature of Allocating Tasks to Queues
The Office cites Karanos paragraphs [0111] through [0118] to describe the placement of tasks within a node based on a plurality of factors. Applicant respectfully submits that Karanasos's Algorithm 1 performs node selection, not queue-based allocation driven by task-declared resource requirements. As Karanasos explains, "Algorithm 1 takes as input a task t and outputs the node n where t should be placed." Karanasos, paragraph [0111]. The queuing Score function evaluates node affinity and node load - system-state metrics about the node - not task-declared resource requirements. Specifically, Karanasos states that "[t]he score of a node comprises two components: a node affinity fort and a node load." (Karanasos, paragraph [0111]). That is, 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. This description in Karanasos is in contrast to the subject matter of claim 10, which requires that the allocation be based on "resource requirements of each task" that is, task-declared attributes. Karanasos's placement decisions are based on the current state of nodes (queue length, wait time), not on resource requirements declared by the tasks themselves. Furthermore, with the inversed relationship taught by Karanasos between the forming of the task queues and the assigned nodes, any combination of Ma and Karanasos would fail to teach, describe, or suggest the generation and allocation to queues on the basis of the claimed features (queue depth, wait time, or predicted utilization).
3. Karanasos Does Not Teach Assigning Nodes to Queues with Tasks
The Office Action alleged that Karanasos teaches assigning nodes to queues with tasks, citing paragraph [0111]. Applicant respectfully submits that Karanasos teaches the reverse relationship: tasks are placed onto nodes, not nodes assigned to queues. Algorithm 1 "takes as input a task t and outputs the node n where t should be placed." (Karanasos, paragraph [0111]). In Karanasos, each node already has its own queue, and the system selects which node's queue to place a task into. 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 as recited in claim 10 is reversed relative to Karanasos.
With regard to point (h), Examiner disagrees with Applicant as Karanasos teaches assigning tasks to queues associated to nodes. 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.)…”, [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…”. A resource requirement for task t can be node affinity or a comparison of task t to the node’s load as stated above in Karanasos.
As a queue can queue one or more tasks, a node assigned to one
task from the queue is interpreted as the same action as a node being assigned to the queue of the task.
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.
Independent Claim 10
…
5. The inclusion of Watt fails to teach, describe, or suggest a system of Monitoring of Queue Length and Resource Utilization tied to a corresponding threshold value in the manner described within the claimed application.
The Office contends that Ma and KARANASOS in combination with
Watt would produce a system that "decreases the resources used for the container, container host, and the container agent resource provisioning process." (Office Action, page 31) While the system in Watt utilizes job queue information to scale containers as address hardware resources it still fails to teach, describe, or suggest the claimed use of a course scheduler to make the request for additional resources. That is, Watt's workload resource optimization subsystem monitors a centralized job queue and compares it to predetermined container generation conditions. As Watt explains, the workload resource optimization subsystem "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." (Watt, paragraph [0039]). These are static, predetermined thresholds for generating new containers; not dynamic monitoring at assigned nodes that triggers requests to a coarse scheduler. Critically, Watt does not involve a coarse scheduler or coordinate multiple hierarchical schedulers. Watt has a single workload resource optimization subsystem that reactively scales containers, which is fundamentally different from the hierarchical coarse/fine-grain scheduling architecture recited in claim 10. Any additional combination of Ma, KARANASOS, and Watt would also fail to include the generation of fine grain processes as found within the claimed application.
With regard to point (i), Examiner disagrees with Applicant as prior art Watt discloses [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…”, [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.”). Thus, each container’s number of jobs are monitored in order to determine an amount of requested resources that is assigned by a workload resource optimization subsystem 212 (interpreted as the coarse scheduler).
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.
Independent Claim 10
…
6. Ma's Container Manager Cannot Serve as Both the Coarse Scheduler and the Fine Grain Scheduler
The Office Action alleged that Ma's container manager teaches both the coarse scheduler for the coarse allocation feature, citing paragraph [0051], and the fine-grain scheduler for element (v), citing paragraph [0052]. (Office Action, pg. 26-27). Applicant respectfully submits that the same component cannot serve as both distinct hierarchical levels of the claimed system. Ma's container manager "may deploy the containers according to the resource allocation information obtained from the container scheduler" and "may examine the resource usage among the container workers and determine for each container its host container worker and instantiate the container." (Ma, paragraph [0052]). This is a single-level deployment function, not a hierarchical scheduling architecture with distinct coarse and fine-grain schedulers as recited in claim 10.
With regard to point (j), Examiner disagrees with Applicant as prior art Ma discloses [0051] “…Staying now with FIG. 6, the container manager computer cluster 602 (also referred as container manager) 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…”, [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…”. The container manager is interpreted as the coarse scheduler, and the container scheduler is interpreted as the fine grain scheduler.
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.
Independent Claim 10
…
7. Ma Does Not Teach the Claimed Prediction Engine Integrated with Real-Time Queue Monitoring
The Office Action alleged that Ma teaches maintaining historical performance data and predicting future resource needs, citing paragraphs [0050]-[0051] and [0036]-[0037]. Applicant respectfully submits that Ma's random forest predictor forecasts aggregate workload parameters and feeds into a container scheduler. As Ma explains, "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." (Ma, paragraph [0050]). Ma's predictor does not monitor current queue length and utilization and apply a prediction engine to adjust scheduling decisions as claim 10 requires. Ma's predictor operates on historical runtime data to forecast future resource usage as a separate component; it is not integrated with real-time queue monitoring and does not continuously adjust scheduling decisions based on current utilization levels.
With regard to point (k), Examiner disagrees with Applicant as Ma discloses [0031] “…In order to guarantee QoS and reduce over-allocation over time, system resource allocation for the application is adjusted in real-time and in a predictive manner. The prediction of resource requirement for a future time may be based on models trained by various machine learning algorithms, such as random forest regression algorithms and s support vector machine algorithms.” Thus, the predictor described in Ma monitors and adjusts resources in real 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.
Independent Claim 10
…
8. No Motivation to Combine the References
Even assuming arguendo that the individual elements could be found across the references (which Applicant does not concede), Applicant submits there is no proper motivation to combine them. The references address fundamentally different problems: Ma is directed to ML-based prediction for IaaS container resource allocation; Karanasos is directed to queue management at worker nodes in cluster scheduling; and Watt is directed to workload optimization through dynamic container and host scaling. None of these references teaches the hierarchical coarse/finegrain scheduling architecture recited in claim 10, and combining them would require fundamental restructuring of each reference's architecture, not mere combination, to arrive at the claimed invention, which constitutes impermissible hindsight reconstruction.
With regard to point (l), in response to applicant's argument that prior arts Ma, Karanasos, and Watt are nonanalogous arts, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, prior arts Ma, Karanasos, and Watt all relate to the field of virtual resource allocation.
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
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.
Claim 15
Although patentably distinct, independent claim 15 recites at least some subject matter similar to subject matter recited in claims 1 and 10 and is therefore patentable for at least some of the same reasons. Applicant reserves the right to submit further remarks evidencing the additional patentable subject matter of independent claim 15 in future papers.
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.
Claim 16
…
2. The inclusion of Kambatla fails to teach or describe the request of additional course blocks of resources as found within the claimed application
The release of "opportunistic second tier containers" as found within Kambatla teaches a wholly different method of resource allocation as compared to the claimed invention. The claimed invention does not present additional mechanisms tied to the secondary threshold but utilized the same hierarchical scheduling mechanics to allocate those additional resources within the system. As such the combination of Kambatla with Ma, KARANASOS, and Watt would present a wholly different approach to the system accounting for secondary thresholds within the claimed application.
With regard to point (n), as Applicant has not argued what and how additional mechanisms tied to the secondary threshold are different from their claimed invention, this argument is moot.
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.
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, 7, and 23 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…”); and/or 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 23, Ma, NAIR, and PARK teach the method of claim 1, Ma further teaches wherein the coarse scheduler allocates resources in sets on a per-node basis (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…”), and PARK further teaches the fine grain scheduler allocates resources on a per CPU or GPU basis ([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…”).
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, 7, and 23 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…”).
Claim 9 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, 7, and 23 above, and further in view of Zur et al. Pub. No. US 2020/0167199 Al (hereafter Zur).
Regarding claim 9, Ma, NAIR, and PARK teach the method of claim 1.
Ma, NAIR, and PARK fail to teach wherein the coarse scheduler
comprises an application programming interface (API) through which the fine grain scheduler communicates with the coarse scheduler to request additional resources.
In analogous art Zur teaches wherein the coarse scheduler comprises an application programming interface (API) through which the fine grain scheduler communicates with the coarse scheduler to request additional resources ([0042] “Service Controller 100 may monitor Container Orchestrator 104, for example using an API of Container Orchestrator 104, for obtaining the properties of the used containers, e.g., the amount of used vCPU, memory, storage, or the like at any given time. Service Controller 100 may communicate with Prediction Modeling Service 112 to predict future infrastructure needs. Service Controller 100 may allocate headroom containers (e.g., Headroom Containers 138) to reserve infrastructure for future needs. Service Controller 100 may instruct Cloud Management Service 116 to provision the additional infrastructure accordingly.”, Note: The Service Controller is interpreted as the coarse scheduler, and the Container Orchestrator is interpreted as the fine grain 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, NAIR, and PARK to incorporate the teachings of Zur to allow the claimed disclosure (a scheduler) to communicate with any container orchestrator without change (Zur [0034] “Yet another technical effect of the disclosure is that it can be used with any container orchestrator, for example using the container orchestrator API, and is not limited to a particular orchestrator. The disclosure can thus be applied to and become operative with any orchestrator or orchestrator change, without further changes.”).
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 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…”, 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…”, Note: The container scheduler is interpreted as the fine grain scheduler), 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 and 16 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.
Claims 17 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), further in view of Kambatla Pub. No. US 2018/0074855 Al as applied to claims 11 and 16 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 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…”).
Ma, KARANASOS, Watt, and Kambatla fail to teach predicting when
additional coarse blocks of resources may be needed based on current and historical utilization levels; 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…”).
Claims 20 and 22 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), further in view of PARK et al. Pub. No. US 2021/0191751 Al (hereafter PARK) as applied to claims 1, 3, 5, 7, and 23 above, and further in view of McClory et al. Pub. No. US 2018/0324204 Al (hereafter McClory).
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 based on a recommended logical node topology, and wherein the one or more master node containers and the one or more working node containers are configured to communicate with one another.
However, in analogous art McClory teaches further comprising creating one or more master node containers and one or more worker node containers based on a recommended logical node topology, and wherein the one or more master node containers and the one or more working node containers are configured to communicate with one another ([0061] “…In an embodiment, the created cluster may include at least one master cluster node such as cluster node 222-1 that includes a guest OS (e.g., guest OS 132) configured to execute one or more applications that manage one or more slave cluster nodes. In an embodiment, the created cluster may also include at least one slave cluster node such as cluster node 220-1 that includes a guest OS (e.g., guest OS 132) configured to execute one or more applications that communicate with a master cluster node and manages the execution of one or more container applications (e.g., container applications 136, etc.) and/or native applications (e.g., native applications 138, etc.) of the slave cluster node. It may be appreciated that the number of cluster nodes and the topology of the cluster nodes may vary based on the application creation configuration information determined based on answers to questions from the application developer.”).
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 McClory to provide customization of node clusters (McClory ([0061] “…It may be appreciated that the number of cluster nodes and the topology of the cluster nodes may vary based on the application creation configuration information determined based on answers to questions from the application developer.”).
Regarding claim 22, Ma, NAIR, and PARK teach the method of claim 1.
Ma, NAIR, and PARK fail to teach further comprising recommending a node topology associated with the application received, wherein said node topology includes an amount of processing nodes and a hierarchy associated with said processing nodes.
However, in analogous art McClory teaches further comprising recommending a node topology associated with the application received, wherein said node topology includes an amount of processing nodes and a hierarchy associated with said processing nodes ([0061] “…In an embodiment, the created cluster may include at least one master cluster node such as cluster node 222-1 that includes a guest OS (e.g., guest OS 132) configured to execute one or more applications that manage one or more slave cluster nodes. In an embodiment, the created cluster may also include at least one slave cluster node such as cluster node 220-1 that includes a guest OS (e.g., guest OS 132) configured to execute one or more applications that communicate with a master cluster node and manages the execution of one or more container applications (e.g., container applications 136, etc.) and/or native applications (e.g., native applications 138, etc.) of the slave cluster node. It may be appreciated that the number of cluster nodes and the topology of the cluster nodes may vary based on the application creation configuration information determined based on answers to questions from the application developer.”).
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 McClory to provide customization of node clusters (McClory ([0061] “…It may be appreciated that the number of cluster nodes and the topology of the cluster nodes may vary based on the application creation configuration information determined based on answers to questions from the application developer.”).
Claim 24 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, 7, and 23 above, and further in view of Watt, JR. et al. Pub. No. US 2018/0225155 Al (hereafter Watt).
Regarding claim 24, Ma, NAIR, and PARK teach the method of claim 1.
Ma, NAIR, and PARK fail to teach wherein the fine grain scheduler is further configured to release resources back to the coarse scheduler when resource utilization within the container falls below a predetermined threshold, and wherein the resources are released in sets or batches that meet the coarse scheduler's minimum allocation.
However, in analogous art Watt teaches wherein the fine grain scheduler is further configured to release resources back to the coarse scheduler when resource utilization within the container falls below a predetermined threshold, and wherein the resources are released in sets or batches that meet the coarse scheduler's minimum allocation ([0050] “…For example, the container host deactivation condition may be based on the hardware/virtual resources of the container host 206 consumed by existing containers 208a-b, a number of containers hosted by the container host 206, the rate at which containers are being created or decommissioned on the container host 206 and/or the agent infrastructure subsystem 204, a duration that a particular container host utilization is below a container host utilization threshold, and/or other container host thresholds and container host conditions that would be apparent to one of skill in the art in possession of the present disclosure…”, Note: The coarse scheduler's minimum allocation is interpreted as the number of containers decommissioned/released when a container host utilization/resources consumed by containers fall below thresholds).
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 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.”).
Claims 25-26 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 McClory et al. Pub. No. US 2018/0324204 Al (hereafter McClory).
Regarding claim 25, 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 assign said nodes based on a recommended node topology, wherein said node topology includes an amount of processing nodes and a hierarchy associated with said processing nodes.
However, in analogous art McClory teaches wherein the at least one processor is further configured to assign said nodes based on a recommended node topology, wherein said node topology includes an amount of processing nodes and a hierarchy associated with said processing nodes ([0061] “…In an embodiment, the created cluster may include at least one master cluster node such as cluster node 222-1 that includes a guest OS (e.g., guest OS 132) configured to execute one or more applications that manage one or more slave cluster nodes. In an embodiment, the created cluster may also include at least one slave cluster node such as cluster node 220-1 that includes a guest OS (e.g., guest OS 132) configured to execute one or more applications that communicate with a master cluster node and manages the execution of one or more container applications (e.g., container applications 136, etc.) and/or native applications (e.g., native applications 138, etc.) of the slave cluster node. It may be appreciated that the number of cluster nodes and the topology of the cluster nodes may vary based on the application creation configuration information determined based on answers to questions from the application developer.”).
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 McClory to provide customization of node clusters (McClory ([0061] “…It may be appreciated that the number of cluster nodes and the topology of the cluster nodes may vary based on the application creation configuration information determined based on answers to questions from the application developer.”).
Regarding claim 26, Ma, KARANASOS, and Watt teach the system of claim 25.
Ma, KARANASOS, and Watt fail to teach wherein said hierarchy includes at least one master node and at least one work node, said master node and said worker nodes configured to communicate with one another.
However, in analogous art McClory teaches wherein said hierarchy includes at least one master node and at least one work node, said master node and said worker nodes configured to communicate with one another ([0061] “…In an embodiment, the created cluster may include at least one master cluster node such as cluster node 222-1 that includes a guest OS (e.g., guest OS 132) configured to execute one or more applications that manage one or more slave cluster nodes. In an embodiment, the created cluster may also include at least one slave cluster node such as cluster node 220-1 that includes a guest OS (e.g., guest OS 132) configured to execute one or more applications that communicate with a master cluster node and manages the execution of one or more container applications (e.g., container applications 136, etc.) and/or native applications (e.g., native applications 138, etc.) of the slave cluster node. It may be appreciated that the number of cluster nodes and the topology of the cluster nodes may vary based on the application creation configuration information determined based on answers to questions from the application developer.”).
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 McClory to provide customization of node clusters (McClory ([0061] “…It may be appreciated that the number of cluster nodes and the topology of the cluster nodes may vary based on the application creation configuration information determined based on answers to questions from the application developer.”).
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.
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.
Examiner respectfully requests, in response to this Office action, support be
shown for language added to any original claims on amendment and any new claims.
That is, indicate support for newly added claim language by specifically pointing to
page(s) and line number(s) in the specification and/or drawing figure(s). This will assist
Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111 (c).
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.
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 5:00 PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on (571)270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.C.T./Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights