DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed on 11/03/2025.
Claims 1-2, 4-9, 11-16, 18-20, and 24-26 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-2, 4-9, 11-16, 18-20, and 24-26 are 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. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 8, and 15 recite(s) the limitation(s): “a user-defined configuration file that is available to the device management service before the description file of the to-be-scheduled Pod is acquired;”. However, upon review of the initial application filing, proper support in the written description for this limitation was not found. The specification states: “Step I: defining, by a user, a list of to-be-managed devices in a configuration file, including a device quantity, an operation authority (read/write/modify), a host device file path, and an in-container device file path. Step II: enabling a device management service, reading a configuration file configured for a user device, and analyzing the configuration file to obtain configuration information; and then registering the configuration information in a service of kubelet (for example, a registry service in Fig. 4) … Step IV: when a Pod requires to use one or more devices, it is only necessary to declare names and quantities of required devices in a limits field (e.g., k8s.input: 1; the number of applied input devices is 1) of a yaml description file of the Pod, determine, by a kube-scheduler, a work node (i.e., node) with a satisfactory device resource, and complete the binding of the Pod to the work node” in paragraphs 76-77 and 79. While the initial filing discusses a user-defined configuration file, it fails to teach that such a configuration file is available to the device management service before the description file of the to-be-scheduled Pod is acquired. The initial filing does explicitly not describe the configuration file being made available to the device management service and further does not discus the timing of availability relating to a description file of the to-be-scheduled pod. Thus, there is a lack of support in the initial filing for this limitation of claims 1, 8, and 15. If applicant disagrees that there is support within the written description, please provide citation to where the support can be found within the specification.
Claims 2, 4-7, 9, 11-14, 16, 18-20, and 24-26 depend, directly or indirectly, from rejected claims and do not resolve the deficiencies thereof and are therefore rejected for at least the same reasons.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 26 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 26 recites the limitation “the container has the authority to read or write or modify which devices” in lines 2-3. It is unclear which devices the claim is referring to. For the sake of compact prosecution, Examiner will interpret this to mean “the container has the authority to read or write or modify devices”.
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-2, 4-5, 7, 15-16, 18-19, and 25-26 are rejected under 35 U.S.C. 103 as being unpatentable over Huo (US 2022/0405127 A1) in view of Yang, Che. Getting Started with Kubernetes GPU Management and Device Plugin Implementation, 2020 hereinafter Yang in view of Myers (US 2021/0049002 A1).
With regard to claim 1, Huo teaches:
A computer-implemented method for creating a container in a Kubernetes-based environment of a target work node on a Unix-derived operating system, comprising: “Kubernetes, commonly referred to as K8s, is an open-source container-orchestration system for automating computer application deployment, scaling, and management. Particularly, it aims to provide a platform for automating deployment, scaling, and operations of application containers across clusters of hosts. Kubernetes works with a range of container tools and runs containers in a cluster, often with images built using Docker” [Huo ¶ 2]. “The basic scheduling unit in Kubernetes is a pod. A pod is a grouping of containerized components. A pod includes of one or more containers that are guaranteed to be co-located on the same node” [Huo ¶ 2].
acquiring, by a kube-scheduler, a description file of a to-be-scheduled container group (Pod), wherein the description file of the to-be-scheduled Pod is used for describing resource demand information; “A scheduler is the pluggable component that selects which node an unscheduled pod (i.e., the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2]
binding, by the kube-scheduler, the to-be-scheduled Pod to the target work node selected from a plurality of work nodes, “At block 302, software application 204 of computer system 202 is configured to receive a request 206 to schedule a pod on a node from a pool of schedulable nodes. Nodes 1, 2, 3, 4, 5, 6, 7 (generally referred to as nodes 1-7) are schedulable worker nodes which could potentially contain and run the requested pod” [Huo ¶ 36]. “At block 314, software application 204 is configured to deploy and/or cause the requested pod to be deployed on the node determined to be the highest/best performance node” [Huo ¶ 44].
wherein the kube-scheduler selects the target work node by finding a work node from the plurality of work nodes whose idle resource information satisfies the resource demand information in the description file; “A scheduler is the pluggable component that selects which node an unscheduled pod (i.e., the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2].
Huo fails to teach sending, by a kubelet, a container runtime interface (CRI) request to a container engine, wherein the CRI request includes instructions to create a target container at the target work node based on a configuration information in the CRI request, wherein the configuration information is received from a device management service in response to an Allocate request, the configuration information being derived from a user-defined configuration file that is available to the device management service before the description file of the to-be-scheduled Pod is acquired; wherein the configuration information is used to limit an authority of the target container and the authority of the target container relates to a corresponding device of the target work node, wherein the corresponding device was pre-registered at the device management service, wherein the authority comprises an operation authority, a path access authority, and a device quantity, such that from the time the target container is created, the configuration information appears in the target container, and the authority of the target container to access the corresponding device is limited to that provided by the configuration information; wherein the configuration information is for the corresponding device and comprises: a device name, a device quantity, an operation authority, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file.
However, Yang teaches:
and sending, by a kubelet, a container runtime interface (CRI) request to a container engine, wherein the CRI request includes instructions to create a target container at the target work node based on a configuration information in the CRI request, “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node. After the binding is complete, the node-matched kubelet creates a container. When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container” [Yang Pg. 13 ¶ 1-2].
wherein the configuration information is received from a device management service in response to an Allocate request, “The kubelet sends an Allocate request to the device plugin. The request includes the device ID list that contains the GPU to be assigned to the container. After receiving the Allocate request, the device plugin finds the device path, driver directory, and environment variables related to the device ID, and returns the information to the kubelet through an Allocate response” [Yang Pg. 13 ¶ 3].
the configuration information being derived from a user-defined configuration file that is available to the device management service before the description file of the to-be-scheduled Pod is acquired; “Step 4: The kubelet exposes these devices to the status of the node and sends the device quantity to the Kubernetes API server. The scheduler implements scheduling based on this information. The kubelet reports only the GPU quantity to the Kubernetes API server. The device plugin manager of the kubelet stores the GPU ID list and assigns the GPU IDs to devices. The Kubernetes global scheduler does not see the GPU ID list, only the GPU quantity. As a result, when a device plugin is used, the Kubernetes global scheduler implements scheduling based only on the GPU quantity … When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node” [Yang Pg. 12 ¶ 4-5, Pg. 13 ¶ 1 Examiner notes the GPU ID and GPU quantity is configuration information which available to Kubernetes when a pod wants to use a GPU].
wherein the configuration information is used to limit an authority of the target container “We can use Kubernetes to manage GPUs and other heterogeneous resources to achieve the following: … Ensure exclusive access to resources: We can isolate heterogeneous devices through containers to prevent interference” [Yang Pg. 2 ¶ 3]. “After the deployment is complete, log on to the container and run the "nvidia-smi" command to check the result. You can see that a T4 GPU is used by the container. One of the two GPUs is in use in the container. The other GPU is transparent to the container and is inaccessible due to the GPU isolation feature” [Yang Pg. 8-9 ¶ 3].
and the authority of the target container relates to a corresponding device of the target work node, “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node. After the binding is complete, the node-matched kubelet creates a container. When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container. The kubelet sends an Allocate request to the device plugin. The request includes the device ID list that contains the GPU to be assigned to the container” [Yang Pg. 13 ¶ 1-3].
wherein the corresponding device was pre-registered at the device management service “Step 1: The device plugin is registered to interact with Kubernetes. Multiple devices may exist on a node. The device plugin, as a client, reports the following information to the kubelet: (1) name of the device managed by the device plugin, such as a GPU or RDMA; (2) file path of the UNIX socket to which the device plugin listens so that the kubelet can call the device plugin; (3) protocol for interaction, which is the API version … The kubelet reports only the GPU quantity to the Kubernetes API server. The device plugin manager of the kubelet stores the GPU ID list and assigns the GPU IDs to devices” [Yang Pg. 12 ¶ 1, 5].
wherein the authority comprises an operation authority, a path access authority, and a device quantity, “After receiving the Allocate request, the device plugin finds the device path, driver directory, and environment variables related to the device ID, and returns the information to the kubelet through an Allocate response. The kubelet assigns a GPU to the container based on the received device path and driver directory. Then, Docker creates a container as instructed by the kubelet. The created container includes a GPU. Finally, the required driver directory is mounted. This completes the process of assigning a GPU to a pod in Kubernetes” [Yang Pg. 13 ¶ 4-5]. “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node” [Yang Pg. 13 ¶ 1].
such that from the time the target container is created, the configuration information appears in the target container, “The kubelet assigns a GPU to the container based on the received device path and driver directory. Then, Docker creates a container as instructed by the kubelet. The created container includes a GPU. Finally, the required driver directory is mounted. This completes the process of assigning a GPU to a pod in Kubernetes” [Getting Started Section 5].
and the authority of the target container to access the corresponding device is limited to that provided by the configuration information; “Set nvidia.com/gpu to the number of required GPUs under the limit field in the pod resource configuration. It is set to 1 in the following figure. Then, run the "kubectl create" command to deploy the target pod” [Getting Started – GPU Management Section 3].
wherein the configuration information is for the corresponding device and comprises: a device name, a device quantity, an operation authority, “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node. After the binding is complete, the node-matched kubelet creates a container. When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container” [Yang Pg. 13 ¶ 1-2 Examiner notes the assignment of a device to a container is considered an authority to operate said device].
a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; “The kubelet assigns a GPU to the container based on the received device path (host path) and driver directory. Then, Docker creates a container as instructed by the kubelet. The created container includes a GPU. Finally, the required driver directory (in-container path) is mounted” [Yang Pg. 13 ¶ 5].
Yang is considered to be analogous to the claimed invention because it is in the same field of management of virtual resources. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo to incorporate the teachings of Yang and include: sending, by a kubelet, a container runtime interface (CRI) request to a container engine, wherein the CRI request includes instructions to create a target container at the target work node based on a configuration information in the CRI request, wherein the configuration information is received from a device management service in response to an Allocate request, the configuration information being derived from a user-defined configuration file that is available to the device management service before the description file of the to-be-scheduled Pod is acquired; wherein the configuration information is used to limit an authority of the target container and the authority of the target container relates to a corresponding device of the target work node, wherein the corresponding device was pre-registered at the device management service, wherein the authority comprises an operation authority, a path access authority, and a device quantity, such that from the time the target container is created, the configuration information appears in the target container, and the authority of the target container to access the corresponding device is limited to that provided by the configuration information; wherein the configuration information is for the corresponding device and comprises: a device name, a device quantity, an operation authority, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file. Doing so would allow for improved system flexibility and availability through access to GPU resources. “We can use Kubernetes to manage GPUs to drive down costs and improve efficiency” [Yang Pg. 2 ¶ 2].
Huo in view of Yang fails to explicitly teach the configuration information being derived from a user-defined configuration file… using the user-defined configuration file which comprises the configuration information set by a user, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; and scanning the user-defined configuration file according to a preset time, and in response to determining that the user-defined configuration file has changed, adding a device type based on the changed user-defined configuration file.
However, Myers teaches:
the configuration information being derived from a user-defined configuration file “The information in the repository 601 includes software images 603 that can be run as containers by the host server 614. Along with the software images 603, the repository 601 can include information such as stateful sets 605, initialization scripts 607, and configuration files 609” [Myers ¶ 157]. Each of the containers 110a-110e may have a corresponding configuration file 112a-112e. When each container 110a-110e is created and initialized, the host server 102 accesses the appropriate configuration file 112a-112e to prepare the container” [Myers ¶ 63]. “The configuration file 316 may be used to effectuate the deployment of the container 310. The configuration file 316 may have been generated or modified by an operator, developer, or administrator of the container 310 or of a cluster that the container 310 is part of” [Myers ¶ 114].
using the user-defined configuration file which comprises the configuration information set by a user, “The instructions 822 may be generated and sent to the stateful set 812 manually. For example, the instructions 822 may be generated and sent to the stateful set 812 by one or more system administrators, operators, and/or developers. The instructions 822 may be generated and sent to the stateful set 812 automatically based on a triggering event. For example, the instructions 822 may be automatically sent to the stateful set 812 in order to update the configuration file 804a in response to a determination that a new driver 834 is available” [Myers ¶ 230].
a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; “The parameters in the configuration file 316 may include, for example, a cache size, capacity limits, port assignments, etc. The configuration file 316 may be used to effectuate the deployment of the container 310. The configuration file 316 may have been generated or modified by an operator, developer, or administrator of the container 310 or of a cluster that the container 310 is part of” [Myers ¶ 114]. “In the example, the starting of the container 610 causes the container 610 to follow the reference 606 and read the configuration file 609a, which in turn identifies the driver 632a and its location. For example, the configuration file 609a points to the driver 632 and the configuration settings 638” [Myers ¶ 176].
and scanning the user-defined configuration file according to a preset time, “The software image 802a may use the reference 806 and read the modified configuration file 804b in response to the passing of a particular amount of time since last reading the modified configuration file 804b, e.g. when the software image 802a is configured to read the modified configuration file 804b periodically” [Myers ¶ 234].
and in response to determining that the user-defined configuration file has changed, adding a device type based on the changed user-defined configuration file. “For example, the instructions 822 may be generated and sent to the stateful set 812 by one or more system administrators, operators, and/or developers. The instructions 822 may be generated and sent to the stateful set 812 automatically based on a triggering event. For example, the instructions 822 may be automatically sent to the stateful set 812 in order to update the configuration file 804a in response to a determination that a new driver 834 is available” [Myers ¶ 230-231]. “Upon reading the modified configuration file 804b, the software image 802a shown in FIG. 8A is directed to the driver 834. The software image 802a may proceed to retrieve the driver 834 and install it on the running instance of the modified software image 802a and/or the container 810a shown in FIG. 8A, resulting in the modified software image 802b” [Myers ¶ 236]. “For example, the host server 814 may compare the driver 834 with a list of one or more drivers that are currently installed on the running instance of the software image 802a and/or the container 810a. If the driver 834 is not listed, the host server 814 may retrieve the driver 834 and install it on the running instance of the software image 802a and/or the container 810a, resulting in the modified software image 802b and/or the modified container 810b” [Myers ¶ 238].
Myers is considered to be analogous to the claimed invention because it is in the same field of management of virtual resources. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo in view of Yang to incorporate the teachings of Myers and include: the configuration information being derived from a user-defined configuration file… using the user-defined configuration file which comprises the configuration information set by a user, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; and scanning the user-defined configuration file according to a preset time, and in response to determining that the user-defined configuration file has changed, adding a device type based on the changed user-defined configuration file. Doing so would allow for changes to be made to a container without updating the software image of the container. “By contrast with traditional systems, the systems discussed herein can enable state data, updates, and customizations to be applied to containers without requiring updates to the software images for the containers” [Myers ¶ 6].
With regard to claim 2, Huo in view of Yang in view of Myers teaches the method according to claim 1, as referenced above. Huo further teaches:
wherein the idle resource information of each of the plurality of work nodes is determined by: registering, by the device management service, the configuration information in a node agent kubelet; “At block 306, software application 204 is configured to save to workload data database 214 and process the resource information and the node type information for each of the selected candidate nodes 4, 5, 6, 7, as well as the (Docker) image layers information and the concurrency count of the requested pod. Workload data database 214 may be stored in memory 208” [Huo ¶ 38].
and reporting, by the device management service, responsive to registering the configuration information being completed, the idle resource information of each work node to the kubelet. “At block 802 of the computer-implemented process 800 of FIG. 8, software application 204 (e.g., K8s scheduler) is configured to monitor workload data database 214 which continuously receives information about nodes running on nodes 1-7 as seen in FIG. 9” [Huo ¶ 53].
With regard to claim 4, Huo in view of Yang in view of Myers teaches the method according to claim 1, as referenced above. Huo fails to teach wherein the idle resource information of each work node comprises a number of available devices at each work node, and the method further comprises: sending, by a kubelet, the number of available devices to an API server in a form of an extended resource.
However, Yang teaches:
wherein the idle resource information of each work node comprises a number of available devices at each work node, “After the GPU node is deployed, view GPU information in the node status information, including: · GPU name, which is nvidia.com/gpu in this example · GPU quantity, which is 2 in the following figure, indicating that the node has two GPUs” [Yang Pg. 7-8 ¶ 5-1].
and the method further comprises: sending, by a kubelet, the number of available devices to an API server in a form of an extended resource. “Kubernetes provides extended resources to allow you to create custom resources. Extended resources are measured at the integer level so that different heterogeneous devices can be supported by using a general mode, such as remote direct memory access (RDMA), field programmable gate array (FPGA), and AMD GPUs. This feature is not restricted to NVIDIA GPUs” [Yang Pg. 9 ¶ 4]. “Step 4: The kubelet exposes these devices to the status of the node and sends the device quantity to the Kubernetes API server. The scheduler implements scheduling based on this information” [Yang Pg. 12 ¶ 4].
With regard to claim 5, Huo in view of Yang in view of Myers teaches the method according to claim 1, as referenced above. Huo further teaches:
wherein the kube-scheduler selects the target work node by finding a work node whose idle resource information satisfies the resource demand information in the description file further comprises: determining, by a master node in a Kubernetes cluster comprising the plurality of work nodes, “Computer system 202 may be referred to as the control node, master node, master, Kubernetes deployment controller, etc. Computer systems 251, 252, 253, 254, 255, 256, 257 may be referred to as worker nodes, workers, etc., and can each be a server. For illustration purposes, computer systems 251, 252, 253, 254, 255, 256, 257 can respectively correlate to nodes 1, 2, 3, 4, 5, 6, 7 in a cluster” [Huo ¶ 34].
based on the idle resource information of each work node “For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2, Fig. 2 Examiner notes the inclusion of K8s Scheduler 204 in Computer system 202 in figure 2].
and a preset scheduling strategy, a demand amount for each work node; “This can provide an improvement over known methods for scheduling and deploying a pod by deploying the pod on the node based at least in part on the having the best predicted response time” [Huo ¶ 4].
and determining, by the master node in the Kubernetes cluster comprising the plurality of work nodes, a work node having a demand amount satisfying a demand amount corresponding to the description file of the to-be-scheduled Pod as the target work node. “At block 304, software application 204 is configured to select candidate nodes from the pool of nodes based on one or more rules. For example, the selected candidate nodes can be selected based on having enough hardware and software resources to accommodate a new pod” [Huo ¶ 37].
With regard to claim 7, Huo in view of Yang in view of Myers teaches the method according to claim 1, as referenced above. Huo fails to teach wherein idle resource information corresponding to a device at each work node comprises idle resource information corresponding to a graphics processing unit (GPU) in the device at each work node.
However, Yang teaches wherein idle resource information corresponding to a device at each work node comprises idle resource information corresponding to a graphics processing unit (GPU) in the device at each work node. “When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container” [Yang Pg. 13 ¶ 2].
With regard to claim 15, Huo teaches:
A non-transitory computer readable storage medium storing computer instructions for “The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention” [Huo ¶ 92].
creating a container in a Kubernetes-based environment of a target work node on a Unix-derived operating system, wherein the computer instructions are configured to cause a computer to execute operations comprising: “Kubernetes, commonly referred to as K8s, is an open-source container-orchestration system for automating computer application deployment, scaling, and management. Particularly, it aims to provide a platform for automating deployment, scaling, and operations of application containers across clusters of hosts. Kubernetes works with a range of container tools and runs containers in a cluster, often with images built using Docker” [Huo ¶ 2]. “The basic scheduling unit in Kubernetes is a pod. A pod is a grouping of containerized components. A pod includes of one or more containers that are guaranteed to be co-located on the same node” [Huo ¶ 2].
acquiring, by a kube-scheduler, a description file of a to-be-scheduled container group (Pod), wherein the description file of the to-be-scheduled Pod is used for describing resource demand information; “A scheduler is the pluggable component that selects which node an unscheduled pod (i.e., the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2]
binding, by the kube-scheduler, the to-be-scheduled Pod to the target work node selected from a plurality of work nodes, “At block 302, software application 204 of computer system 202 is configured to receive a request 206 to schedule a pod on a node from a pool of schedulable nodes. Nodes 1, 2, 3, 4, 5, 6, 7 (generally referred to as nodes 1-7) are schedulable worker nodes which could potentially contain and run the requested pod” [Huo ¶ 36]. “At block 314, software application 204 is configured to deploy and/or cause the requested pod to be deployed on the node determined to be the highest/best performance node” [Huo ¶ 44].
wherein the kube-scheduler selects the target work node by finding a work node from the plurality of work nodes whose idle resource information satisfies the resource demand information in the description file; “A scheduler is the pluggable component that selects which node an unscheduled pod (i.e., the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2].
Huo fails to teach and sending, by a kubelet, a container runtime interface (CRI) request to a container engine, wherein the CRI request includes instructions to create a target container at the target work node based on a configuration information in the CRI request, wherein the configuration information is received from a device management service in response to an Allocate request, the configuration information being derived from a user-defined configuration file that is available to the device management service before the description file of the to-be-scheduled Pod is acquired; wherein the configuration information is used to limit an authority of the target container and the authority of the target container relates to a corresponding device of the target work node, wherein the corresponding device was pre-registered at the device management service using the user-defined configuration file which comprises the configuration information set by a user, wherein the authority comprises an operation authority, a path access authority, and a device quantity, such that from the time the target container is created, the configuration information appears in the target container, and the authority of the target container to access the corresponding device is limited to that provided by the configuration information; wherein the configuration information is for the corresponding device and comprises: a device name, a device quantity, an operation authority, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file.
However, Yang teaches:
and sending, by a kubelet, a container runtime interface (CRI) request to a container engine, wherein the CRI request includes instructions to create a target container at the target work node based on a configuration information in the CRI request, “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node. After the binding is complete, the node-matched kubelet creates a container. When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container” [Yang Pg. 13 ¶ 1-2].
wherein the configuration information is received from a device management service in response to an Allocate request, “The kubelet sends an Allocate request to the device plugin. The request includes the device ID list that contains the GPU to be assigned to the container. After receiving the Allocate request, the device plugin finds the device path, driver directory, and environment variables related to the device ID, and returns the information to the kubelet through an Allocate response” [Yang Pg. 13 ¶ 3].
the configuration information being derived from a user-defined configuration file that is available to the device management service before the description file of the to-be-scheduled Pod is acquired; “Step 4: The kubelet exposes these devices to the status of the node and sends the device quantity to the Kubernetes API server. The scheduler implements scheduling based on this information. The kubelet reports only the GPU quantity to the Kubernetes API server. The device plugin manager of the kubelet stores the GPU ID list and assigns the GPU IDs to devices. The Kubernetes global scheduler does not see the GPU ID list, only the GPU quantity. As a result, when a device plugin is used, the Kubernetes global scheduler implements scheduling based only on the GPU quantity … When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node” [Yang Pg. 12 ¶ 4-5, Pg. 13 ¶ 1 Examiner notes the GPU ID and GPU quantity is configuration information which available to Kubernetes when a pod wants to use a GPU].
wherein the configuration information is used to limit an authority of the target container “We can use Kubernetes to manage GPUs and other heterogeneous resources to achieve the following: … Ensure exclusive access to resources: We can isolate heterogeneous devices through containers to prevent interference” [Yang Pg. 2 ¶ 3]. “After the deployment is complete, log on to the container and run the "nvidia-smi" command to check the result. You can see that a T4 GPU is used by the container. One of the two GPUs is in use in the container. The other GPU is transparent to the container and is inaccessible due to the GPU isolation feature” [Yang Pg. 8-9 ¶ 3].
and the authority of the target container relates to a corresponding device of the target work node, “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node. After the binding is complete, the node-matched kubelet creates a container. When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container. The kubelet sends an Allocate request to the device plugin. The request includes the device ID list that contains the GPU to be assigned to the container” [Yang Pg. 13 ¶ 1-3].
wherein the corresponding device was pre-registered at the device management service “Step 1: The device plugin is registered to interact with Kubernetes. Multiple devices may exist on a node. The device plugin, as a client, reports the following information to the kubelet: (1) name of the device managed by the device plugin, such as a GPU or RDMA; (2) file path of the UNIX socket to which the device plugin listens so that the kubelet can call the device plugin; (3) protocol for interaction, which is the API version … The kubelet reports only the GPU quantity to the Kubernetes API server. The device plugin manager of the kubelet stores the GPU ID list and assigns the GPU IDs to devices” [Yang Pg. 12 ¶ 1, 5].
wherein the authority comprises an operation authority, a path access authority, and a device quantity, “After receiving the Allocate request, the device plugin finds the device path, driver directory, and environment variables related to the device ID, and returns the information to the kubelet through an Allocate response. The kubelet assigns a GPU to the container based on the received device path and driver directory. Then, Docker creates a container as instructed by the kubelet. The created container includes a GPU. Finally, the required driver directory is mounted. This completes the process of assigning a GPU to a pod in Kubernetes” [Yang Pg. 13 ¶ 4-5]. “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node” [Yang Pg. 13 ¶ 1].
such that from the time the target container is created, the configuration information appears in the target container, “The kubelet assigns a GPU to the container based on the received device path and driver directory. Then, Docker creates a container as instructed by the kubelet. The created container includes a GPU. Finally, the required driver directory is mounted. This completes the process of assigning a GPU to a pod in Kubernetes” [Getting Started Section 5].
and the authority of the target container to access the corresponding device is limited to that provided by the configuration information; “Set nvidia.com/gpu to the number of required GPUs under the limit field in the pod resource configuration. It is set to 1 in the following figure. Then, run the "kubectl create" command to deploy the target pod” [Getting Started – GPU Management Section 3].
wherein the configuration information is for the corresponding device and comprises: a device name, a device quantity, an operation authority, “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node. After the binding is complete, the node-matched kubelet creates a container. When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container” [Yang Pg. 13 ¶ 1-2 Examiner notes the assignment of a device to a container is considered an authority to operate said device].
a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; “The kubelet assigns a GPU to the container based on the received device path (host path) and driver directory. Then, Docker creates a container as instructed by the kubelet. The created container includes a GPU. Finally, the required driver directory (in-container path) is mounted” [Yang Pg. 13 ¶ 5].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo to incorporate the teachings of Yang and include: sending, by a kubelet, a container runtime interface (CRI) request to a container engine, wherein the CRI request includes instructions to create a target container at the target work node based on a configuration information in the CRI request, wherein the configuration information is received from a device management service in response to an Allocate request, the configuration information being derived from a user-defined configuration file that is available to the device management service before the description file of the to-be-scheduled Pod is acquired; wherein the configuration information is used to limit an authority of the target container and the authority of the target container relates to a corresponding device of the target work node, wherein the corresponding device was pre-registered at the device management service, wherein the authority comprises an operation authority, a path access authority, and a device quantity, such that from the time the target container is created, the configuration information appears in the target container, and the authority of the target container to access the corresponding device is limited to that provided by the configuration information; wherein the configuration information is for the corresponding device and comprises: a device name, a device quantity, an operation authority, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file. Doing so would allow for improved system flexibility and availability through access to GPU resources. “We can use Kubernetes to manage GPUs to drive down costs and improve efficiency” [Yang Pg. 2 ¶ 2].
Huo in view of Yang fails to explicitly teach the configuration information being derived from a user-defined configuration file… using the user-defined configuration file which comprises the configuration information set by a user, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; and scanning the user-defined configuration file according to a preset time, and in response to determining that the user-defined configuration file has changed, adding a device type based on the changed user-defined configuration file.
However, Myers teaches:
the configuration information being derived from a user-defined configuration file “The information in the repository 601 includes software images 603 that can be run as containers by the host server 614. Along with the software images 603, the repository 601 can include information such as stateful sets 605, initialization scripts 607, and configuration files 609” [Myers ¶ 157]. Each of the containers 110a-110e may have a corresponding configuration file 112a-112e. When each container 110a-110e is created and initialized, the host server 102 accesses the appropriate configuration file 112a-112e to prepare the container” [Myers ¶ 63]. “The configuration file 316 may be used to effectuate the deployment of the container 310. The configuration file 316 may have been generated or modified by an operator, developer, or administrator of the container 310 or of a cluster that the container 310 is part of” [Myers ¶ 114].
using the user-defined configuration file which comprises the configuration information set by a user, “The instructions 822 may be generated and sent to the stateful set 812 manually. For example, the instructions 822 may be generated and sent to the stateful set 812 by one or more system administrators, operators, and/or developers. The instructions 822 may be generated and sent to the stateful set 812 automatically based on a triggering event. For example, the instructions 822 may be automatically sent to the stateful set 812 in order to update the configuration file 804a in response to a determination that a new driver 834 is available” [Myers ¶ 230].
a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; “The parameters in the configuration file 316 may include, for example, a cache size, capacity limits, port assignments, etc. The configuration file 316 may be used to effectuate the deployment of the container 310. The configuration file 316 may have been generated or modified by an operator, developer, or administrator of the container 310 or of a cluster that the container 310 is part of” [Myers ¶ 114]. “In the example, the starting of the container 610 causes the container 610 to follow the reference 606 and read the configuration file 609a, which in turn identifies the driver 632a and its location. For example, the configuration file 609a points to the driver 632 and the configuration settings 638” [Myers ¶ 176].
and scanning the user-defined configuration file according to a preset time, “The software image 802a may use the reference 806 and read the modified configuration file 804b in response to the passing of a particular amount of time since last reading the modified configuration file 804b, e.g. when the software image 802a is configured to read the modified configuration file 804b periodically” [Myers ¶ 234].
and in response to determining that the user-defined configuration file has changed, adding a device type based on the changed user-defined configuration file. “For example, the instructions 822 may be generated and sent to the stateful set 812 by one or more system administrators, operators, and/or developers. The instructions 822 may be generated and sent to the stateful set 812 automatically based on a triggering event. For example, the instructions 822 may be automatically sent to the stateful set 812 in order to update the configuration file 804a in response to a determination that a new driver 834 is available” [Myers ¶ 230-231]. “Upon reading the modified configuration file 804b, the software image 802a shown in FIG. 8A is directed to the driver 834. The software image 802a may proceed to retrieve the driver 834 and install it on the running instance of the modified software image 802a and/or the container 810a shown in FIG. 8A, resulting in the modified software image 802b” [Myers ¶ 236]. “For example, the host server 814 may compare the driver 834 with a list of one or more drivers that are currently installed on the running instance of the software image 802a and/or the container 810a. If the driver 834 is not listed, the host server 814 may retrieve the driver 834 and install it on the running instance of the software image 802a and/or the container 810a, resulting in the modified software image 802b and/or the modified container 810b” [Myers ¶ 238].
Myers is considered to be analogous to the claimed invention because it is in the same field of management of virtual resources. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo in view of Yang to incorporate the teachings of Myers and include: the configuration information being derived from a user-defined configuration file… using the user-defined configuration file which comprises the configuration information set by a user, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; and scanning the user-defined configuration file according to a preset time, and in response to determining that the user-defined configuration file has changed, adding a device type based on the changed user-defined configuration file. Doing so would allow for changes to be made to a container without updating the software image of the container. “By contrast with traditional systems, the systems discussed herein can enable state data, updates, and customizations to be applied to containers without requiring updates to the software images for the containers” [Myers ¶ 6].
With regard to claim 16, Huo in view of Yang in view of Myers teaches the non-transitory computer readable storage medium according to claim 15, as referenced above. Huo further teaches:
wherein the operations further comprise: registering, by the device management service, the configuration information in a node agent kubelet; “At block 306, software application 204 is configured to save to workload data database 214 and process the resource information and the node type information for each of the selected candidate nodes 4, 5, 6, 7, as well as the (Docker) image layers information and the concurrency count of the requested pod. Workload data database 214 may be stored in memory 208” [Huo ¶ 38].
and reporting, by the device management service, responsive to registering the configuration information being completed, the idle resource information of each work node to the kubelet. “At block 802 of the computer-implemented process 800 of FIG. 8, software application 204 (e.g., K8s scheduler) is configured to monitor workload data database 214 which continuously receives information about nodes running on nodes 1-7 as seen in FIG. 9” [Huo ¶ 53].
With regard to claim 18, Huo in view of Yang in view of Myers teaches the non-transitory computer readable storage medium according to claim 15, as referenced above. Huo fails to teach wherein the idle resource information of each work node comprises a number of available devices at each work node, and the operations further comprise: sending, by a kubelet, the number of available devices to an API server in a form of an extended resource.
However, Yang teaches:
wherein the idle resource information of each work node comprises a number of available devices at each work node, “After the GPU node is deployed, view GPU information in the node status information, including: · GPU name, which is nvidia.com/gpu in this example · GPU quantity, which is 2 in the following figure, indicating that the node has two GPUs” [Yang Pg. 7-8 ¶ 5-1].
and the operations further comprise: sending, by a kubelet, the number of available devices to an API server in a form of an extended resource. “Kubernetes provides extended resources to allow you to create custom resources. Extended resources are measured at the integer level so that different heterogeneous devices can be supported by using a general mode, such as remote direct memory access (RDMA), field programmable gate array (FPGA), and AMD GPUs. This feature is not restricted to NVIDIA GPUs” [Yang Pg. 9 ¶ 4]. “Step 4: The kubelet exposes these devices to the status of the node and sends the device quantity to the Kubernetes API server. The scheduler implements scheduling based on this information” [Yang Pg. 12 ¶ 4].
With regard to claim 19, Huo in view of Yang in view of Myers teaches the non-transitory computer readable storage medium according to claim 15, as referenced above. Huo further teaches:
wherein determining, based on the description file of the to-be-scheduled Pod and the idle resource information of each work node, the target work node from the plurality of work nodes comprises: determining, by a master node in a Kubernetes cluster comprising the plurality of work nodes, “Computer system 202 may be referred to as the control node, master node, master, Kubernetes deployment controller, etc. Computer systems 251, 252, 253, 254, 255, 256, 257 may be referred to as worker nodes, workers, etc., and can each be a server. For illustration purposes, computer systems 251, 252, 253, 254, 255, 256, 257 can respectively correlate to nodes 1, 2, 3, 4, 5, 6, 7 in a cluster” [Huo ¶ 34].
based on the idle resource information of each work node “For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2, Fig. 2 Examiner notes the inclusion of K8s Scheduler 204 in Computer system 202 in figure 2].
and a preset scheduling strategy, a demand amount for each work node; “This can provide an improvement over known methods for scheduling and deploying a pod by deploying the pod on the node based at least in part on the having the best predicted response time” [Huo ¶ 4].
and determining, by the master node in the Kubernetes cluster comprising the plurality of work nodes, a work node having a demand amount satisfying a demand amount corresponding to the description file of the to-be-scheduled Pod as the target work node. “At block 304, software application 204 is configured to select candidate nodes from the pool of nodes based on one or more rules. For example, the selected candidate nodes can be selected based on having enough hardware and software resources to accommodate a new pod” [Huo ¶ 37].
With regard to claim 25, Huo in view of Yang in view of Myers teaches the method according to claim 1, as referenced above. Huo in view of Yang fails to teach wherein the adding the device type in the device management service based on the changed user-defined configuration file further comprises without modification of program code of the device management service.
However, Myers teaches wherein the adding the device type in the device management service based on the changed user-defined configuration file further comprises without modification of program code of the device management service. “The container can be configured to seek out the configuration information and act on it, so that the operation of the container initiates the incorporation of external elements (e.g., to pull the external elements into the container or to reconfigure software of the container), rather than be directed to make the changes by the host system or a management process” [Myers ¶ 7].
With regard to claim 26, Huo in view of Yang in view of Myers teaches the method according to claim 25, as referenced above. Huo fails to teach wherein the devices comprise at least one of a GPU and an input device.
However, Yang teaches wherein the devices comprise at least one of a GPU and an input device. “When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container” [Yang Pg. 13 ¶ 2].
Huo in view of Yang fails to explicitly teach wherein the configuration information used to limit the authority of the target container comprises: the container has the authority to read or write or modify which devices.
However, Myers teaches wherein the configuration information used to limit the authority of the target container comprises: the container has the authority to read or write or modify which devices, “In the example, the starting of the container 610 causes the container 610 to follow the reference 606 and read the configuration file 609a, which in turn identifies the driver 632a and its location. For example, the configuration file 609a points to the driver 632 and the configuration settings 638” [Myers ¶ 176]. “In reading the configuration file 609a, the software image 603a and/or the container 610 may identify additional resources including external resources, settings that are stored as part of the configuration file 609a, and/or instructions for the software image 603a and/or the container 610 to take” [Myers ¶ 180].
Claims 6 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Huo (US 2022/0405127 A1) in view of Yang in view of Myers (US 2021/0049002 A1) in view of Wang (US 2022/0334882 A1).
With regard to claim 6, Huo in view of Yang in view of Myers teaches the method according to claim 1, as referenced above. Huo further teaches:
wherein a plurality of target work nodes are determined from the plurality of work nodes, “For example, the selected candidate nodes can be selected based on having enough hardware and software resources to accommodate a new pod. In this example scenario, it is assumed that software application 204 has selected candidate nodes 4, 5, 6, 7 which correspond to computer systems 254, 255, 256, 257, respectively” [Huo ¶ 37].
and the method further comprises: acquiring, by a master node in a Kubernetes cluster comprising the plurality of work nodes, “Computer system 202 may be referred to as the control node, master node, master, Kubernetes deployment controller, etc. Computer systems 251, 252, 253, 254, 255, 256, 257 may be referred to as worker nodes, workers, etc., and can each be a server. For illustration purposes, computer systems 251, 252, 253, 254, 255, 256, 257 can respectively correlate to nodes 1, 2, 3, 4, 5, 6, 7 in a cluster” [Huo ¶ 34].
allocating, to the training task, by a master node in a Kubernetes cluster comprising the plurality of work nodes, a node satisfying the resource demand information corresponding to the training task based on the idle resource information of each work node in the plurality of target work nodes, “A scheduler is the pluggable component that selects which node an unscheduled pod (i.e., the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2]
and scheduling, by a component of the Kubernetes system, the training node to execute the training task, “At block 314, software application 204 is configured to deploy and/or cause the requested pod to be deployed on the node determined to be the highest/best performance node” [Huo ¶ 44].
Huo in view of Yang in view of Myers fails to explicitly teach a training task of a to-be-trained target model and resource demand information corresponding to the training task; allocating, to the training task, by a master node in a Kubernetes cluster comprising the plurality of work nodes, a node … and using the allocated node as a training node of the training task … the training task, to train the to-be-trained target model.
However, Wang teaches:
a training task of a to-be-trained target model and resource demand information corresponding to the training task; “In the scenario, the resource management platform is Kubernetes, and algorithm technicians submit a training task of an artificial intelligence model to a Kubernetes resource management platform, and specify the name of the data set as dataset” [Wang ¶ 88].
allocating, to the training task, by a master node in a Kubernetes cluster comprising the plurality of work nodes, a node “The task allocation unit in Kubernetes judges if each node has the required data set according to the name of the data set in the node and the name of the data set required for processing tasks… Wherein, to facilitate selection of nodes, the node is scored according to a preset data set scoring strategy of the node. Since the Kubernetes resource management platform has a scoring strategy for the performance of the node, therefore, the node is allocated with tasks based on the original node scoring strategy of the Kubernetes platform and in combination with the data set scores of the node.” [Wang ¶ 88].
and using the allocated node as a training node of the training task; “In the scenario, the resource management platform is Kubernetes, and algorithm technicians submit a training task of an artificial intelligence model to a Kubernetes resource management platform, and specify the name of the data set as dataset … The obtained score of the data set of the node is added to the score of the original node of Kubernetes, for the node having no required data set, the score of the data set is 0, and a node with the score capable of meeting requirements for processing tasks is selected for task allocation” [Wang ¶ 88].
the training task, to train the to-be-trained target model. “Along with rapid development of artificial intelligence technology and containerization technology, more and more artificial intelligence models are trained and tested on distributed resource management platforms” [Wang ¶ 3].
Wang is considered to be analogous to the claimed invention because it is in the same field of management of virtual resources. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo in view of Yang in view of Myers to incorporate the teachings of Wang and include: a training task of a to-be-trained target model and resource demand information corresponding to the training task; allocating, to the training task, by a master node in a Kubernetes cluster comprising the plurality of work nodes, a node … and using the allocated node as a training node of the training task … the training task, to train the to-be-trained target model. Doing so would allow for further efficiency when accommodating artificial intelligence workloads. “Based on the above problems, the present application provides a task allocation method and system based on a resource management platform, capable of solving the problem of waste in time and resources caused by the requirement of downloading data sets by a large number of nodes when training or testing tasks of an artificial intelligence model are processed on a resource management platform” [Wang ¶ 5].
With regard to claim 20, Huo in view of Yang in view of Myers teaches the n-transitory computer readable storage medium according to claim 15, as referenced above. Huo further teaches:
wherein a plurality of target work nodes are determined from the plurality of work nodes, “For example, the selected candidate nodes can be selected based on having enough hardware and software resources to accommodate a new pod. In this example scenario, it is assumed that software application 204 has selected candidate nodes 4, 5, 6, 7 which correspond to computer systems 254, 255, 256, 257, respectively” [Huo ¶ 37].
the operations further comprising: acquiring, by a master node in a Kubernetes cluster comprising the plurality of work nodes, “Computer system 202 may be referred to as the control node, master node, master, Kubernetes deployment controller, etc. Computer systems 251, 252, 253, 254, 255, 256, 257 may be referred to as worker nodes, workers, etc., and can each be a server. For illustration purposes, computer systems 251, 252, 253, 254, 255, 256, 257 can respectively correlate to nodes 1, 2, 3, 4, 5, 6, 7 in a cluster” [Huo ¶ 34].
allocating, to the training task, by a master node in a Kubernetes cluster comprising the plurality of work nodes, a node satisfying the resource demand information corresponding to the training task based on the idle resource information of each work node in the plurality of target work nodes, “A scheduler is the pluggable component that selects which node an unscheduled pod (i.e., the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2]
and scheduling, by a component of the Kubernetes system, the training node to execute the training task, “At block 314, software application 204 is configured to deploy and/or cause the requested pod to be deployed on the node determined to be the highest/best performance node” [Huo ¶ 44].
Huo in view of Yang in view of Myers fails to explicitly teach a training task of a to-be-trained target model and resource demand information corresponding to the training task; allocating, to the training task, by a master node in a Kubernetes cluster comprising the plurality of work nodes, a node … and using the allocated node as a training node of the training task … the training task, to train the to-be-trained target model.
However, Wang teaches:
a training task of a to-be-trained target model and resource demand information corresponding to the training task; “In the scenario, the resource management platform is Kubernetes, and algorithm technicians submit a training task of an artificial intelligence model to a Kubernetes resource management platform, and specify the name of the data set as dataset” [Wang ¶ 88].
allocating, to the training task, by a master node in a Kubernetes cluster comprising the plurality of work nodes, a node “The task allocation unit in Kubernetes judges if each node has the required data set according to the name of the data set in the node and the name of the data set required for processing tasks… Wherein, to facilitate selection of nodes, the node is scored according to a preset data set scoring strategy of the node. Since the Kubernetes resource management platform has a scoring strategy for the performance of the node, therefore, the node is allocated with tasks based on the original node scoring strategy of the Kubernetes platform and in combination with the data set scores of the node.” [Wang ¶ 88].
and using the allocated node as a training node of the training task “In the scenario, the resource management platform is Kubernetes, and algorithm technicians submit a training task of an artificial intelligence model to a Kubernetes resource management platform, and specify the name of the data set as dataset … The obtained score of the data set of the node is added to the score of the original node of Kubernetes, for the node having no required data set, the score of the data set is 0, and a node with the score capable of meeting requirements for processing tasks is selected for task allocation” [Wang ¶ 88].
the training task, to train the to-be-trained target model. “Along with rapid development of artificial intelligence technology and containerization technology, more and more artificial intelligence models are trained and tested on distributed resource management platforms” [Wang ¶ 3].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo in view of Yang in view of Myers to incorporate the teachings of Wang and include: a training task of a to-be-trained target model and resource demand information corresponding to the training task; allocating, to the training task, by a master node in a Kubernetes cluster comprising the plurality of work nodes, a node … and using the allocated node as a training node of the training task … the training task, to train the to-be-trained target model. Doing so would allow for further efficiency when accommodating artificial intelligence workloads. “Based on the above problems, the present application provides a task allocation method and system based on a resource management platform, capable of solving the problem of waste in time and resources caused by the requirement of downloading data sets by a large number of nodes when training or testing tasks of an artificial intelligence model are processed on a resource management platform” [Wang ¶ 5].
Claims 8-9, 11-14, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Huo (US 2022/0405127 A1) in view of Yang in view of Myers (US 2021/0049002 A1) in view of Wang (US 2022/0334882 A1) in view of Levin (US 10,972,449 B1).
With regard to claim 8, Huo teaches:
A system for creating a container in a Kubernetes-based environment of a target work node on a Unix-derived operating system, comprising: “Kubernetes, commonly referred to as K8s, is an open-source container-orchestration system for automating computer application deployment, scaling, and management. Particularly, it aims to provide a platform for automating deployment, scaling, and operations of application containers across clusters of hosts. Kubernetes works with a range of container tools and runs containers in a cluster, often with images built using Docker” [Huo ¶ 2]. “The basic scheduling unit in Kubernetes is a pod. A pod is a grouping of containerized components. A pod includes of one or more containers that are guaranteed to be co-located on the same node” [Huo ¶ 2].
at least one processor; and a memory storing instructions, wherein the instructions when executed by the at least one processor cause the at least one processor to perform operations comprising: “The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention” [Huo ¶ 92].
acquiring, by a kube-scheduler, a description file of a to-be-scheduled container group (Pod), wherein the description file of the to-be-scheduled Pod is used for describing resource demand information; “A scheduler is the pluggable component that selects which node an unscheduled pod (i.e., the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2]
binding, by the kube-scheduler, the to-be-scheduled Pod to the target work node selected from a plurality of work nodes, “At block 302, software application 204 of computer system 202 is configured to receive a request 206 to schedule a pod on a node from a pool of schedulable nodes. Nodes 1, 2, 3, 4, 5, 6, 7 (generally referred to as nodes 1-7) are schedulable worker nodes which could potentially contain and run the requested pod” [Huo ¶ 36]. “At block 314, software application 204 is configured to deploy and/or cause the requested pod to be deployed on the node determined to be the highest/best performance node” [Huo ¶ 44].
wherein the kube-scheduler selects the target work node by finding a work node from the plurality of work nodes whose idle resource information satisfies the resource demand information in the description file; “A scheduler is the pluggable component that selects which node an unscheduled pod (i.e., the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2].
wherein the kube-scheduler selects the target work node by finding a work node from the plurality of work nodes whose idle resource information satisfies the resource demand information in the description file comprises: obtaining a resource difference value for each work node in the plurality of work nodes based on the idle resource information of each work node in the plurality of work nodes and the resource demand information, “At block 304, software application 204 is configured to select candidate nodes from the pool of nodes based on one or more rules. For example, the selected candidate nodes can be selected based on having enough hardware and software resources to accommodate a new pod” [Huo ¶ 37].
based on the resource difference value corresponding to each work node, select one or more of the work nodes as a training node for the training task, “At block 304, software application 204 is configured to select candidate nodes from the pool of nodes based on one or more rules. For example, the selected candidate nodes can be selected based on having enough hardware and software resources to accommodate a new pod” [Huo ¶ 37]. “A scheduler is the pluggable component that selects which node an unscheduled pod (i.e., the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2].
based on the idle resource information of each work node and the corresponding demand and preset scheduling strategy, obtain the demand for each work node, “For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2]. “At block 302, software application 204 of computer system 202 is configured to receive a request 206 to schedule a pod on a node from a pool of schedulable nodes. Nodes 1, 2, 3, 4, 5, 6, 7 (generally referred to as nodes 1-7) are schedulable worker nodes which could potentially contain and run the requested pod” [Huo ¶ 36]. “This can provide an improvement over known methods for scheduling and deploying a pod by deploying the pod on the node based at least in part on the having the best predicted response time” [Huo ¶ 4].
Huo fails to teach and sending, by a kubelet, a container runtime interface (CRI) request to a container engine, wherein the CRI request includes instructions to create a target container at the target work node based on a configuration information in the CRI request, wherein the configuration information is received from a device management service in response to an Allocate request, the configuration information being derived from a user-defined configuration file that is available to the device management service before the description file of the to-be-scheduled Pod is acquired; wherein the configuration information is used to limit an authority of the target container and the authority of the target container relates to a corresponding device of the target work node, wherein the corresponding device was pre-registered at the device management service using the user-defined configuration file which comprises the configuration information set by a user, wherein the authority comprises an operation authority, a path access authority, and a device quantity, such that from the time the target container is created, the configuration information appears in the target container, and the authority of the target container to access the corresponding device is limited to that provided by the configuration information; wherein the configuration information is for the corresponding device and comprises: a device name, a device quantity, an operation authority, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file.
However, Yang teaches:
and sending, by a kubelet, a container runtime interface (CRI) request to a container engine, wherein the CRI request includes instructions to create a target container at the target work node based on a configuration information in the CRI request, “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node. After the binding is complete, the node-matched kubelet creates a container. When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container” [Yang Pg. 13 ¶ 1-2].
wherein the configuration information is received from a device management service in response to an Allocate request, “The kubelet sends an Allocate request to the device plugin. The request includes the device ID list that contains the GPU to be assigned to the container. After receiving the Allocate request, the device plugin finds the device path, driver directory, and environment variables related to the device ID, and returns the information to the kubelet through an Allocate response” [Yang Pg. 13 ¶ 3].
the configuration information being derived from a user-defined configuration file that is available to the device management service before the description file of the to-be-scheduled Pod is acquired; “Step 4: The kubelet exposes these devices to the status of the node and sends the device quantity to the Kubernetes API server. The scheduler implements scheduling based on this information. The kubelet reports only the GPU quantity to the Kubernetes API server. The device plugin manager of the kubelet stores the GPU ID list and assigns the GPU IDs to devices. The Kubernetes global scheduler does not see the GPU ID list, only the GPU quantity. As a result, when a device plugin is used, the Kubernetes global scheduler implements scheduling based only on the GPU quantity … When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node” [Yang Pg. 12 ¶ 4-5, Pg. 13 ¶ 1 Examiner notes the GPU ID and GPU quantity is configuration information which available to Kubernetes when a pod wants to use a GPU].
wherein the configuration information is used to limit an authority of the target container “We can use Kubernetes to manage GPUs and other heterogeneous resources to achieve the following: … Ensure exclusive access to resources: We can isolate heterogeneous devices through containers to prevent interference” [Yang Pg. 2 ¶ 3]. “After the deployment is complete, log on to the container and run the "nvidia-smi" command to check the result. You can see that a T4 GPU is used by the container. One of the two GPUs is in use in the container. The other GPU is transparent to the container and is inaccessible due to the GPU isolation feature” [Yang Pg. 8-9 ¶ 3].
and the authority of the target container relates to a corresponding device of the target work node, “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node. After the binding is complete, the node-matched kubelet creates a container. When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container. The kubelet sends an Allocate request to the device plugin. The request includes the device ID list that contains the GPU to be assigned to the container” [Yang Pg. 13 ¶ 1-3].
wherein the corresponding device was pre-registered at the device management service “Step 1: The device plugin is registered to interact with Kubernetes. Multiple devices may exist on a node. The device plugin, as a client, reports the following information to the kubelet: (1) name of the device managed by the device plugin, such as a GPU or RDMA; (2) file path of the UNIX socket to which the device plugin listens so that the kubelet can call the device plugin; (3) protocol for interaction, which is the API version … The kubelet reports only the GPU quantity to the Kubernetes API server. The device plugin manager of the kubelet stores the GPU ID list and assigns the GPU IDs to devices” [Yang Pg. 12 ¶ 1, 5].
wherein the authority comprises an operation authority, a path access authority, and a device quantity, “After receiving the Allocate request, the device plugin finds the device path, driver directory, and environment variables related to the device ID, and returns the information to the kubelet through an Allocate response. The kubelet assigns a GPU to the container based on the received device path and driver directory. Then, Docker creates a container as instructed by the kubelet. The created container includes a GPU. Finally, the required driver directory is mounted. This completes the process of assigning a GPU to a pod in Kubernetes” [Yang Pg. 13 ¶ 4-5]. “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node” [Yang Pg. 13 ¶ 1].
such that from the time the target container is created, the configuration information appears in the target container, “The kubelet assigns a GPU to the container based on the received device path and driver directory. Then, Docker creates a container as instructed by the kubelet. The created container includes a GPU. Finally, the required driver directory is mounted. This completes the process of assigning a GPU to a pod in Kubernetes” [Getting Started Section 5].
and the authority of the target container to access the corresponding device is limited to that provided by the configuration information; “Set nvidia.com/gpu to the number of required GPUs under the limit field in the pod resource configuration. It is set to 1 in the following figure. Then, run the "kubectl create" command to deploy the target pod” [Getting Started – GPU Management Section 3].
wherein the configuration information is for the corresponding device and comprises: a device name, a device quantity, an operation authority, “When a pod wants to use a GPU, it declares the GPU resource and required quantity in Resource.limits, such as nvidia.com/gpu: 1. Kubernetes finds the node that meets the required GPU quantity, subtracts the number of GPUs on the node by 1, and binds the pod and the node. After the binding is complete, the node-matched kubelet creates a container. When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container” [Yang Pg. 13 ¶ 1-2 Examiner notes the assignment of a device to a container is considered an authority to operate said device].
a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; “The kubelet assigns a GPU to the container based on the received device path (host path) and driver directory. Then, Docker creates a container as instructed by the kubelet. The created container includes a GPU. Finally, the required driver directory (in-container path) is mounted” [Yang Pg. 13 ¶ 5].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo to incorporate the teachings of Yang and include: sending, by a kubelet, a container runtime interface (CRI) request to a container engine, wherein the CRI request includes instructions to create a target container at the target work node based on a configuration information in the CRI request, wherein the configuration information is received from a device management service in response to an Allocate request, the configuration information being derived from a user-defined configuration file that is available to the device management service before the description file of the to-be-scheduled Pod is acquired; wherein the configuration information is used to limit an authority of the target container and the authority of the target container relates to a corresponding device of the target work node, wherein the corresponding device was pre-registered at the device management service, wherein the authority comprises an operation authority, a path access authority, and a device quantity, such that from the time the target container is created, the configuration information appears in the target container, and the authority of the target container to access the corresponding device is limited to that provided by the configuration information; wherein the configuration information is for the corresponding device and comprises: a device name, a device quantity, an operation authority, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file. Doing so would allow for improved system flexibility and availability through access to GPU resources. “We can use Kubernetes to manage GPUs to drive down costs and improve efficiency” [Yang Pg. 2 ¶ 2].
Huo in view of Yang fails to explicitly teach the configuration information being derived from a user-defined configuration file… using the user-defined configuration file which comprises the configuration information set by a user, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; and the operations further comprise: scanning the user-defined configuration file according to a preset time, and in response to determining that the user-defined configuration file has changed, adding a device type based on the changed user-defined configuration file; wherein the adding the device type in the device management service based on the changed user-defined configuration file further comprises without modification of program code of the device management service; wherein the preset scheduling strategy comprises: resource balance scheduling strategy.
However, Myers teaches:
the configuration information being derived from a user-defined configuration file “The information in the repository 601 includes software images 603 that can be run as containers by the host server 614. Along with the software images 603, the repository 601 can include information such as stateful sets 605, initialization scripts 607, and configuration files 609” [Myers ¶ 157]. Each of the containers 110a-110e may have a corresponding configuration file 112a-112e. When each container 110a-110e is created and initialized, the host server 102 accesses the appropriate configuration file 112a-112e to prepare the container” [Myers ¶ 63]. “The configuration file 316 may be used to effectuate the deployment of the container 310. The configuration file 316 may have been generated or modified by an operator, developer, or administrator of the container 310 or of a cluster that the container 310 is part of” [Myers ¶ 114].
using the user-defined configuration file which comprises the configuration information set by a user, “The instructions 822 may be generated and sent to the stateful set 812 manually. For example, the instructions 822 may be generated and sent to the stateful set 812 by one or more system administrators, operators, and/or developers. The instructions 822 may be generated and sent to the stateful set 812 automatically based on a triggering event. For example, the instructions 822 may be automatically sent to the stateful set 812 in order to update the configuration file 804a in response to a determination that a new driver 834 is available” [Myers ¶ 230].
a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; “The parameters in the configuration file 316 may include, for example, a cache size, capacity limits, port assignments, etc. The configuration file 316 may be used to effectuate the deployment of the container 310. The configuration file 316 may have been generated or modified by an operator, developer, or administrator of the container 310 or of a cluster that the container 310 is part of” [Myers ¶ 114]. “In the example, the starting of the container 610 causes the container 610 to follow the reference 606 and read the configuration file 609a, which in turn identifies the driver 632a and its location. For example, the configuration file 609a points to the driver 632 and the configuration settings 638” [Myers ¶ 176].
and the operations further comprise: scanning the user-defined configuration file according to a preset time, “The software image 802a may use the reference 806 and read the modified configuration file 804b in response to the passing of a particular amount of time since last reading the modified configuration file 804b, e.g. when the software image 802a is configured to read the modified configuration file 804b periodically” [Myers ¶ 234].
and in response to determining that the user-defined configuration file has changed, adding a device type based on the changed user-defined configuration file, “For example, the instructions 822 may be generated and sent to the stateful set 812 by one or more system administrators, operators, and/or developers. The instructions 822 may be generated and sent to the stateful set 812 automatically based on a triggering event. For example, the instructions 822 may be automatically sent to the stateful set 812 in order to update the configuration file 804a in response to a determination that a new driver 834 is available” [Myers ¶ 230-231]. “Upon reading the modified configuration file 804b, the software image 802a shown in FIG. 8A is directed to the driver 834. The software image 802a may proceed to retrieve the driver 834 and install it on the running instance of the modified software image 802a and/or the container 810a shown in FIG. 8A, resulting in the modified software image 802b” [Myers ¶ 236]. “For example, the host server 814 may compare the driver 834 with a list of one or more drivers that are currently installed on the running instance of the software image 802a and/or the container 810a. If the driver 834 is not listed, the host server 814 may retrieve the driver 834 and install it on the running instance of the software image 802a and/or the container 810a, resulting in the modified software image 802b and/or the modified container 810b” [Myers ¶ 238].
wherein the adding the device type in the device management service based on the changed user-defined configuration file further comprises without modification of program code of the device management service; “The container can be configured to seek out the configuration information and act on it, so that the operation of the container initiates the incorporation of external elements (e.g., to pull the external elements into the container or to reconfigure software of the container), rather than be directed to make the changes by the host system or a management process” [Myers ¶ 7].
wherein the preset scheduling strategy comprises: resource balance scheduling strategy. “The existing containers 402a, 404a, and 406a are processing requests provided to them through the load balancer services 408. The load balancing services 408 may include one or more load balancers. Using a load balancer may improve individual container performance and performance of the cluster 410 by spreading the load, e.g. request traffic, over the containers in the cluster 410” [Myers ¶ 126].
Myers is considered to be analogous to the claimed invention because it is in the same field of management of virtual resources. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo in view of Yang to incorporate the teachings of Myers and include: the configuration information being derived from a user-defined configuration file… using the user-defined configuration file which comprises the configuration information set by a user, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file; and the operations further comprise: scanning the user-defined configuration file according to a preset time, and in response to determining that the user-defined configuration file has changed, adding a device type based on the changed user-defined configuration file, wherein the adding the device type in the device management service based on the changed user-defined configuration file further comprises without modification of program code of the device management service; wherein the preset scheduling strategy comprises: resource balance scheduling strategy. Doing so would allow for changes to be made to a container without updating the software image of the container. “By contrast with traditional systems, the systems discussed herein can enable state data, updates, and customizations to be applied to containers without requiring updates to the software images for the containers” [Myers ¶ 6].
Huo in view of Yang in view of Myers fails to teach wherein the resource demand information corresponds to a training task.
However, Wang teaches wherein the resource demand information corresponds to a training task; “In the scenario, the resource management platform is Kubernetes, and algorithm technicians submit a training task of an artificial intelligence model to a Kubernetes resource management platform, and specify the name of the data set as dataset” [Wang ¶ 88].
Wang is considered to be analogous to the claimed invention because it is in the same field of management of virtual resources. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo in view of Yang in view of Myers to incorporate the teachings of Wang and include: wherein the resource demand information corresponds to a training task. Doing so would allow for further efficiency when accommodating artificial intelligence workloads. “Based on the above problems, the present application provides a task allocation method and system based on a resource management platform, capable of solving the problem of waste in time and resources caused by the requirement of downloading data sets by a large number of nodes when training or testing tasks of an artificial intelligence model are processed on a resource management platform” [Wang ¶ 5].
Huo in view of Yang in view of Myers in view of Wang fails to teach obtaining a resource difference value for each work node … where the probability of using a work node as a training node is negatively correlated with a resource difference corresponding to that work node.
However, Levin teaches:
obtaining a resource difference value for each work node “For example, in implementations where the servers may have different hardware resources, management service 120 may select a server that best matches the requirement of the client-requested instance with minimum extra resources” [Levin Col. 6 Lines 60-64].
where the probability of using a work node as a training node is negatively correlated with a resource difference corresponding to that work node; “For example, in implementations where the servers may have different hardware resources, management service 120 may select a server that best matches the requirement of the client-requested instance with minimum extra resources” [Levin Col. 6 Lines 60-64].
Levin is considered to be analogous to the claimed invention because it is in the same field of management of virtual resources. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo in view of Yang in view of Myers in view of Wang to incorporate the teachings of Levin and include: obtaining a resource difference value for each work node … where the probability of using a work node as a training node is negatively correlated with a resource difference corresponding to that work node. Doing so would allow for client cost savings. “The hardware of the bare-metal instance may be fully dedicated to the client, including any additional storage, during the time period that the sever is rented to the client” [Levin Col. 6 Lines 54-57].
With regard to claim 9, Huo in view of Yang in view of Myers in view of Wang in view of Levin teaches the system according to claim 8, as referenced above. Huo further teaches:
wherein the operations further comprise: registering, by the device management service, the configuration information in a node agent kubelet; “At block 306, software application 204 is configured to save to workload data database 214 and process the resource information and the node type information for each of the selected candidate nodes 4, 5, 6, 7, as well as the (Docker) image layers information and the concurrency count of the requested pod. Workload data database 214 may be stored in memory 208” [Huo ¶ 38].
and reporting, by the device management service, responsive to registering the configuration information being completed, the idle resource information of each work node to the kubelet. “At block 802 of the computer-implemented process 800 of FIG. 8, software application 204 (e.g., K8s scheduler) is configured to monitor workload data database 214 which continuously receives information about nodes running on nodes 1-7 as seen in FIG. 9” [Huo ¶ 53].
With regard to claim 11, Huo in view of Yang in view of Myers in view of Wang in view of Levin teaches the system according to claim 8, as referenced above. Huo fails to teach wherein the idle resource information of each work node comprises a number of available devices at each work node, and the operations further comprise: sending, by a kubelet, the number of available devices to an API server in a form of an extended resource.
However, Yang teaches:
wherein the idle resource information of each work node comprises a number of available devices at each work node, “After the GPU node is deployed, view GPU information in the node status information, including: · GPU name, which is nvidia.com/gpu in this example · GPU quantity, which is 2 in the following figure, indicating that the node has two GPUs” [Yang Pg. 7-8 ¶ 5-1].
and the operations further comprise: sending, by a kubelet, the number of available devices to an API server in a form of an extended resource. “Kubernetes provides extended resources to allow you to create custom resources. Extended resources are measured at the integer level so that different heterogeneous devices can be supported by using a general mode, such as remote direct memory access (RDMA), field programmable gate array (FPGA), and AMD GPUs. This feature is not restricted to NVIDIA GPUs” [Yang Pg. 9 ¶ 4]. “Step 4: The kubelet exposes these devices to the status of the node and sends the device quantity to the Kubernetes API server. The scheduler implements scheduling based on this information” [Yang Pg. 12 ¶ 4].
With regard to claim 12, Huo in view of Yang in view of Myers in view of Wang in view of Levin teaches the system according to claim 8, as referenced above. Huo further teaches:
wherein the operations further comprise: determining, by a master node in a Kubernetes cluster comprising the plurality of work nodes, “Computer system 202 may be referred to as the control node, master node, master, Kubernetes deployment controller, etc. Computer systems 251, 252, 253, 254, 255, 256, 257 may be referred to as worker nodes, workers, etc., and can each be a server. For illustration purposes, computer systems 251, 252, 253, 254, 255, 256, 257 can respectively correlate to nodes 1, 2, 3, 4, 5, 6, 7 in a cluster” [Huo ¶ 34].
based on the idle resource information of each work node “For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2, Fig. 2 Examiner notes the inclusion of K8s Scheduler 204 in Computer system 202 in figure 2].
and a preset scheduling strategy, a demand amount for each work node; “This can provide an improvement over known methods for scheduling and deploying a pod by deploying the pod on the node based at least in part on the having the best predicted response time” [Huo ¶ 4].
and determining, by the master node in the Kubernetes cluster comprising the plurality of work nodes, a work node having a demand amount satisfying a demand amount corresponding to the description file of the to-be-scheduled Pod as the target work node. “At block 304, software application 204 is configured to select candidate nodes from the pool of nodes based on one or more rules. For example, the selected candidate nodes can be selected based on having enough hardware and software resources to accommodate a new pod” [Huo ¶ 37].
With regard to claim 13, Huo in view of Yang in view of Myers in view of Wang in view of Levin teaches the system according to claim 8, as referenced above. Huo further teaches:
wherein a plurality of target work nodes are determined from the plurality of work nodes, “For example, the selected candidate nodes can be selected based on having enough hardware and software resources to accommodate a new pod. In this example scenario, it is assumed that software application 204 has selected candidate nodes 4, 5, 6, 7 which correspond to computer systems 254, 255, 256, 257, respectively” [Huo ¶ 37].
and the operations further comprise: acquiring, by a master node in a Kubernetes cluster comprising the plurality of work nodes, “Computer system 202 may be referred to as the control node, master node, master, Kubernetes deployment controller, etc. Computer systems 251, 252, 253, 254, 255, 256, 257 may be referred to as worker nodes, workers, etc., and can each be a server. For illustration purposes, computer systems 251, 252, 253, 254, 255, 256, 257 can respectively correlate to nodes 1, 2, 3, 4, 5, 6, 7 in a cluster” [Huo ¶ 34].
allocating, to the training task, by a master node in a Kubernetes cluster comprising the plurality of work nodes, a node satisfying the resource demand information corresponding to the training task based on the idle resource information of each work node in the plurality of target work nodes, “A scheduler is the pluggable component that selects which node an unscheduled pod (i.e., the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2]
and using the allocated node as a training node of the training task to train the to-be-trained target model when scheduled “At block 314, software application 204 is configured to deploy and/or cause the requested pod to be deployed on the node determined to be the highest/best performance node” [Huo ¶ 44].
Huo in view of Yang in view of Myers fails to explicitly teach a training task of a to-be-trained target model and resource demand information corresponding to the training task; allocating, to the training task, by a master node in a Kubernetes cluster comprising the plurality of work nodes, a node … and using the allocated node as a training node of the training task to train the to-be-trained target model when scheduled.
However, Wang teaches:
a training task of a to-be-trained target model and resource demand information corresponding to the training task; “In the scenario, the resource management platform is Kubernetes, and algorithm technicians submit a training task of an artificial intelligence model to a Kubernetes resource management platform, and specify the name of the data set as dataset” [Wang ¶ 88].
allocating, to the training task, by a master node in a Kubernetes cluster comprising the plurality of work nodes, a node “The task allocation unit in Kubernetes judges if each node has the required data set according to the name of the data set in the node and the name of the data set required for processing tasks… Wherein, to facilitate selection of nodes, the node is scored according to a preset data set scoring strategy of the node. Since the Kubernetes resource management platform has a scoring strategy for the performance of the node, therefore, the node is allocated with tasks based on the original node scoring strategy of the Kubernetes platform and in combination with the data set scores of the node.” [Wang ¶ 88].
and using the allocated node as a training node of the training task “In the scenario, the resource management platform is Kubernetes, and algorithm technicians submit a training task of an artificial intelligence model to a Kubernetes resource management platform, and specify the name of the data set as dataset … The obtained score of the data set of the node is added to the score of the original node of Kubernetes, for the node having no required data set, the score of the data set is 0, and a node with the score capable of meeting requirements for processing tasks is selected for task allocation” [Wang ¶ 88].
to train the to-be-trained target model when scheduled. “Along with rapid development of artificial intelligence technology and containerization technology, more and more artificial intelligence models are trained and tested on distributed resource management platforms” [Wang ¶ 3].
With regard to claim 14, Huo in view of Yang in view of Myers in view of Wang in view of Levin teaches the system according to claim 8, as referenced above. Huo fails to teach wherein idle resource information corresponding to a device at each work node comprises idle resource information corresponding to a graphics processing unit (GPU) in the device at each work node.
However, Yang teaches wherein idle resource information corresponding to a device at each work node comprises idle resource information corresponding to a graphics processing unit (GPU) in the device at each work node. “When the kubelet finds that the resource specified in the pod's container request is a GPU, it enables the internal device plugin manager to select an available GPU from the GPU ID list and assigns the GPU to the container” [Yang Pg. 13 ¶ 2].
With regard to claim 24, Huo in view of Yang in view of Myers teaches the method according to claim 1, as referenced above. Huo further teaches:
wherein the kube-scheduler selects the target work node by finding a work node from the plurality of work nodes whose idle resource information satisfies the resource demand information in the description file comprises: obtaining a resource difference value for each work node in the plurality of work nodes based on the idle resource information of each work node in the plurality of work nodes and the resource demand information, “At block 304, software application 204 is configured to select candidate nodes from the pool of nodes based on one or more rules. For example, the selected candidate nodes can be selected based on having enough hardware and software resources to accommodate a new pod” [Huo ¶ 37].
based on the resource difference value corresponding to each work node, select one or more of the work nodes as a training node for the training task, “At block 304, software application 204 is configured to select candidate nodes from the pool of nodes based on one or more rules. For example, the selected candidate nodes can be selected based on having enough hardware and software resources to accommodate a new pod” [Huo ¶ 37]. “A scheduler is the pluggable component that selects which node an unscheduled pod (i.e., the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2].
based on the idle resource information of each work node and the corresponding demand and preset scheduling strategy, obtain the demand for each work node, “For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints and policy directives such as quality-of-service, affinity/anti-affinity requirements, data locality, and so on. In essence, the scheduler's role is to match resource "supply" to workload "demand."” [Huo ¶ 2]. “At block 302, software application 204 of computer system 202 is configured to receive a request 206 to schedule a pod on a node from a pool of schedulable nodes. Nodes 1, 2, 3, 4, 5, 6, 7 (generally referred to as nodes 1-7) are schedulable worker nodes which could potentially contain and run the requested pod” [Huo ¶ 36]. “This can provide an improvement over known methods for scheduling and deploying a pod by deploying the pod on the node based at least in part on the having the best predicted response time” [Huo ¶ 4].
Huo in view of Yang fails to teach wherein the preset scheduling strategy comprises: resource balance scheduling strategy.
However, Myers teaches:
wherein the preset scheduling strategy comprises: resource balance scheduling strategy. “The existing containers 402a, 404a, and 406a are processing requests provided to them through the load balancer services 408. The load balancing services 408 may include one or more load balancers. Using a load balancer may improve individual container performance and performance of the cluster 410 by spreading the load, e.g. request traffic, over the containers in the cluster 410” [Myers ¶ 126].
Huo in view of Yang in view of Myers fails to teach wherein the resource demand information corresponds to a training task.
However, Wang teaches wherein the resource demand information corresponds to a training task; “In the scenario, the resource management platform is Kubernetes, and algorithm technicians submit a training task of an artificial intelligence model to a Kubernetes resource management platform, and specify the name of the data set as dataset” [Wang ¶ 88].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo in view of Yang in view of Myers to incorporate the teachings of Wang and include: wherein the resource demand information corresponds to a training task. Doing so would allow for further efficiency when accommodating artificial intelligence workloads. “Based on the above problems, the present application provides a task allocation method and system based on a resource management platform, capable of solving the problem of waste in time and resources caused by the requirement of downloading data sets by a large number of nodes when training or testing tasks of an artificial intelligence model are processed on a resource management platform” [Wang ¶ 5].
Huo in view of Yang in view of Myers in view of Wang fails to teach obtaining a resource difference value for each work node … where the probability of using a work node as a training node is negatively correlated with a resource difference corresponding to that work node.
However, Levin teaches:
obtaining a resource difference value for each work node “For example, in implementations where the servers may have different hardware resources, management service 120 may select a server that best matches the requirement of the client-requested instance with minimum extra resources” [Levin Col. 6 Lines 60-64].
where the probability of using a work node as a training node is negatively correlated with a resource difference corresponding to that work node; “For example, in implementations where the servers may have different hardware resources, management service 120 may select a server that best matches the requirement of the client-requested instance with minimum extra resources” [Levin Col. 6 Lines 60-64].
Levin is considered to be analogous to the claimed invention because it is in the same field of management of virtual resources. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huo in view of Yang in view of Myers in view of Wang to incorporate the teachings of Levin and include: obtaining a resource difference value for each work node … where the probability of using a work node as a training node is negatively correlated with a resource difference corresponding to that work node. Doing so would allow for client cost savings. “The hardware of the bare-metal instance may be fully dedicated to the client, including any additional storage, during the time period that the sever is rented to the client” [Levin Col. 6 Lines 54-57].
Response to Arguments
Applicant's arguments filed 04/07/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
I. Regarding feature i), the Office Action concedes on page 10 that Huo in view of Yang fails to disclose the configuration information being derived from a user-defined configuration file; using the user-defined configuration file which comprises the configuration information set by a user. However, the Office Action alleges that Zhou discloses these features. Applicant respectfully disagrees.
The Office Action alleges the features are disclosed by paragraph 34 of Zhou. However, paragraph 34, at most, teaches a user task service request sent at runtime. In contrast thereto, in amended claim 1 the user-defined configuration file is available before the Pod description file is acquired. This allows the device management service to pre-register devices and their permissions independently of any particular request, and certainly not any request sent at the later timepoint (e.g., during runtime, i.e. after container is established) as taught by Zhou. Zhou thus fails to teach or suggest such a pre-existing configuration file.
Regarding feature ii), the Office Action concedes on pages 5-6, that Huo fails to teach a configuration information is for the corresponding device and comprises: a device name, a device quantity, an operation authority, a user-defined host path for a corresponding device file, and a user-defined in-container path for a corresponding device file and cites page 13 of Yang (see Office Action pages 8-9) as allegedly disclosing the missing features. However, at most, Yang teaches a device-specific plugin from a vendor that returns fixed device paths (host) and driver directories (in-container). In Yang, the user has no control over these paths. In contrast thereto, in amended claim 1 there is provided user-defined host path and user-defined in-container path in the configuration file, giving the user control over where the device file resides on the host and where it is mounted inside the container. Yang does not teach this flexibility as Yang simply uses fixed default settings.
Regarding feature iii), this was incorporated from previous claim 24. In relation to claim 24, the Office Action concedes (see Office Action pages 48-49), that Hua in view of Yang in view of Zhou in view of Wang and in view of Levin fails to teach the limitation and the method further comprises: scanning the user-defined configuration file according to a preset time, and cites paragraphs 50-51 of Zhang (see Office Action pages 48-49) as allegedly disclosing the features missing from Hua, Yang, Zhou, Wang, and Levin. The Office Action concedes (see Office Action pages 46-47), that Hua in view of Yang fails to teach limitation and in response to determining that the user-defined configuration file has changed, add or delete a device based on the changed user-defined configuration file, and cites paragraph 35 of Zhou (see Office Action pages 47) as allegedly disclosing the features missing from Hua and Yang. However, at most, Zhang (para. [0051]) teaches periodic reporting of hardware/tenant information after container migration, which is unrelated to scanning at a preset time. Further, Zhang does not teach adding a device based on a changed configuration file. Zhou (para. [0035]) teaches only deletion of a specific device in response to a user termination request, specifically Zhou only teaches deleting a container and deallocating GPUs upon a user request. Zhou does not teach adding anything, let alone teach adding a device type, based on a configuration file change. Thus, Zhang and Zhou both fail to disclose the individual limitations in the feature scanning the user-defined configuration file according to a preset time, and in response to determining that the user-defined configuration file has changed, adding a device type based on the changed user-defined configuration file, and thus fails to establish a prima facie case. Moreover, Zhou and Zhang both fail to teach any suggestion or motivation of combining such features. Notably, the Office Action fails to provide any motivation for combining the teaching of Zhou with Yang, instead citing Wang as motivation for a feature related to training.
Thus, based on at least the above reasons, the Office Action fails to establish a prima facie case of obviousness, and the independent claims 1, 8 and 15 are non-obvious.
a) Applicant’s arguments with respect to claim(s) 1, 8, and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
II. At least the following features are not disclosed alone or in combination in the cited art:
iv) where the probability of using a work node as a training node is negatively correlated with a resource difference corresponding to that work node;
v) wherein the adding the device type in the device management service based on the changed user-defined configuration file further comprises without modification of program code of the device management service.
Feature iv) was incorporated from previously pending claim 24. In relation to claim 24, the Office Action concedes (see Office Action page 48), Hua in view of Yang in view of Zhou in view of Wang fails to teach obtaining a resource difference value for each work node... where the probability of using a work node as a training node is negatively correlated with a resource difference corresponding to that work node and cites Levin Col. 6 Lines 60-64 (see Office Action pages 48) as allegedly disclosing the features missing from Hua, Yang, Zhou and Wang. However, Levin (col.6, lines 60-64), at most, teaches a deterministic rule of selecting the server with the minimum extra resources. In contrast, the feature iv) uses a probabilistic selection where the probability of selecting a node is negatively correlated with the resource difference. The method and result will not be the same, as Levin will simply pick one server with the lowest extra resources, not correlate a negative probability to the difference for each server, and Levin thus lacks flexibility in selection.
Regarding feature v), without modification of program code of the device management service, in combination with claim 1's ordered limitations this scans the user-defined configuration file at preset times and, upon change, adds a device type in the device management service without requiring modification of program code. In other words, claim 1 recites a method which supports adding a whole new category of device (e.g., an FPGA, a new GPU model) simply by updating the configuration. This capability is a distinct advantage over conventional device plugins (such as taught in Yang), which require code changes.
Thus, features iv) and v) are not disclosed in any of the cited art, and accordingly claim 8 is non-obvious. Applicant respectfully notes that features iv) and v) also appear in claims 23 and 25 respectively, which depend on claim 1 and are allowable for at least similar reasons.
a) Examiner respectfully disagrees. Levin teaches obtaining a resource difference value for each work node where the probability of using a work node as a training node is negatively correlated with a resource difference corresponding to that work node; [Levin Col. 6 Lines 60-64]. The amount of extra resources of a node as compared to a requested amount as taught by Levin is considered a resource difference value. This resource difference value of Levin is negatively correlated with the probability of using a node because, as Applicant argues, Levin teaches selecting a node with the minimum resource difference value. Thus, the probability of choosing a node with the minimum resource difference value is higher than the probability of choosing a node with a larger resource difference value. This is in accordance with the description given in paragraph 68 of the instant specification: “Specifically, the smaller the resource difference is, the higher a probability that a node corresponding to the resource difference is determined as the training node is. The node with a smaller resource difference is determined as the training node of the training task, which means that the remaining resources of the training node are fewer, such that the training tasks that can be processed by the cluster to which the training node belongs are more, thereby improving the overall throughput of the cluster”. The arguments have been considered but were not found to be persuasive.
Applicant’s further arguments with respect to claim(s) 8, 24, and 25 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
III. Finally, as regards the combinations of teachings, the Office Action relies on up to six references from different technical fields (scheduling, device plugins, dataset allocation, secure communication, license management). As held in KSR International Co. v. Teleflex Inc., 550 U.S. 398, 421 (2007), a combination of prior art elements must be shown to be "obvious to try" with a reasonable expectation of success, and a general desire to improve a system is insufficient to combine disparate references. Here, there is no teaching or suggestion in any reference to combine the specific features claimed as an ordered combination, nor has the Office Action provided any specific reasons to incorporate all of the teachings to obtain a user-defined configuration file with operation authority and path mapping into a Kubernetes device plugin framework, let alone to add probabilistic scheduling and dynamic configuration-file-driven device type addition. The claimed combination in claim 8 is therefore not obvious.
a) Examiner respectfully disagrees. In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the cited prior art of Huo, Yang, Myers, Wang, and Levin are all in the same field of management of virtual devices. As detailed in the rejection above, there is some teaching, suggestion, or motivation to combine each of the references found within the references themselves. A person of ordinary skill in the art would be motivated to combine Huo with the teachings of Yang because doing so would allow for improved system flexibility and availability through access to GPU resources [Yang Pg. 2 ¶ 2]. A person of ordinary skill in the art would be motivated to combine Huo in view of Yang with the teachings of Myers because doing so would allow for changes to be made to a container without updating the software image of the container [Myers ¶ 6]. A person of ordinary skill in the art would be motivated to combine Huo in view of Yang in view of Myers with the teachings of Wang because doing so would allow for further efficiency when accommodating artificial intelligence workloads [Wang ¶ 5]. A person of ordinary skill in the art would be motivated to combine Huo in view of Yang in view of Myers in view of Wang with the teachings of Levin because doing so would allow for client cost savings [Levin Col. 6 Lines 54-57].
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “a user-defined configuration file with operation authority and path mapping into a Kubernetes device plugin framework, let alone to add probabilistic scheduling and dynamic configuration-file-driven device type addition”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The arguments have been considered but were not found to be persuasive.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4:30PM.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/A.F.R./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights