IT OPERATION MANAGEMENT APPARATUS AND METHOD

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 . Notice for all US Patent Applications filed on or after March 16, 2013 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. Status of the Claims This communication is in response to communications received on 7/8/26. Claim(s) 1-2 and 4-10 is/are amended, claim(s) 3 is/are cancelled, claim(s) none is/are new, and applicant does not provide any information on where support for the amendments can be found in the instant specification. Therefore, Claim(s) 1-2 and 4-10 is/are pending and have been addressed below. Information Disclosure Statement There is no IDS. The previously information disclosure statement(s) (IDS) was/were submitted on submitted on 3/12/25. Priority Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. Acknowledgment is made of applicant's claim for foreign priority based on an application(s) JP2024-078509 filed in Japan on 5/14/24. Response to Arguments Applicant’s arguments, see applicant’s remarks, filed 7/8/26, with respect to rejections under 35 USC 112 a and b for claim(s) 1-6 and 35 USC 101 for claim(s) 1-10 have been fully considered and are persuasive. The Examiner respectfully withdraws rejections under 35 USC 112 a and b for claim(s) 1-6 and 35 USC 101 for claim(s) 1-10. Applicant’s arguments, see applicant’s remarks, filed 7/8/26, with respect to rejections under 35 USC 103 for claim(s) 1-10 have been fully considered but they are not persuasive as far as they apply to the amended 103 rejection(s) below. 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. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. It has been held that a prior art reference must either be in the field of applicant’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the applicant was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). Claim(s) 1-2, 6, 7, 8, 9, and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malvankar et al. (US 2025/0028553 A1) in view of Martίnez published September 20, 2022 (reference U on the Notice of References Cited), Byers et al. (US 2020/0219007 A1), and Beveridge (US 2024/0419470 A1). Regarding claims 1 and 7 (currently amended), Malvankar teaches a method performed by a management computer in communication with resources in an operational environment, the resources including at least one graphics processing unit (GPU) and at least one central processing unit (CPU), the at least one CPU the at least one GPU the method comprising {a computer including a non-transitory computer-readable medium, the computer configured by executable instructions to perform operations including - claim 1} [see at least [0015-0016] “In FIG. 1 , computing environment 100 contains an example of an environment for the execution of at least some of the computer code involved in performing the inventive methods, such as preemption optimization system 126. In addition to block 126, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes processor set 110 (including processing circuitry 120 and cache 121), communication fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and block 126, as identified above), peripheral device set 114 (including user interface (UI) device set 123, storage 124, and Internet of Things (IoT) sensor set 125), and network module 115. Remote server 104 includes remote database 130. Public cloud 105 includes gateway 140, cloud orchestration module 141, host physical machine set 142, virtual machine set 143, and container set 144.”; Table 1 and [0037] “In Table 1, an example set of jobs 1-4 is shown and the metrics for each, including job type (the type of model training), … resources requested (amount of compute resources requested), … and predicted time (output that the ML model predicts).” where Table 1 shows in example resources requested includes CPU, GPU, and memory size (GB) such that a resource can be one or all 3 items]: acquiring, as container deployment instruction information, a deployment instruction for execution of a respective plurality of container programs on the resources in the operational environment; {managing, as container deployment information, deployment of containers for execution of a respective plurality of container programs on resources in the operational environment; - claim 1} acquiring information; acquiring information; storing the container deployment instruction information, the information, and the information {storing, on the non-transitory computer-readable medium – claim 1} [for the limitations above, see at least [0010, 0028] container a) runs on the computer resources and b) has programs “Two familiar types of VCEs are virtual machines and containers. A container is a VCE that uses operating-system-level virtualization. This refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances, called containers. These isolated user-space instances typically behave as real computers from the point of view of programs running in them. A computer program running on an ordinary operating system can utilize all resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and devices assigned to the container, a feature which is known as containerization.”; [0033] managing deployment “In step 220, preemption optimization system 126 determines that no computing hosts within the computing cluster have available resources capable of running the pending job and non-preemptive measures won't provide required resources for the pending job. … In an embodiment, preemption optimization system 126 makes this determination by reviewing current jobs running and the resources available in the cluster at any point in time by taking a snapshot and comparing to the associated information received about the pending job of the resources required to run the pending job.”; [0034] acquiring information including priority (deployment instruction) “In step 230, preemption optimization system 126 identifies dynamic and static information on candidate jobs for preemption. In an embodiment, responsive to determining that no computing hosts within the computing cluster have available resources capable of running the pending job and non-preemptive measures won't provide required resources for the pending job, preemption optimization system 126 identifies dynamic and static information on candidate jobs for preemption. In an embodiment, preemption optimization system 126 identifies the static information by pulling the static information received in a job submission script (e.g., in YAML programming language) on each candidate job for preemption. The static information is a configured priority value assigned to a candidate job. In some embodiments, preemption optimization system 126 identifies the dynamic information by polling the cluster for dynamic information about each candidate job as that job runs in the cluster. In some embodiments, preemption optimization system 126 identifies the dynamic information for each candidate job by dynamically calculating the dynamic information for each candidate job using methods described below. The dynamic information includes two aspects: (1) elapsed time from last checkpoint of a respective candidate job and (2) predicted remaining time for completion of a respective candidate job.”; [0035] acquiring more information items (3) and (4) and storing acquired data “For calculating the elapsed time from a last checkpoint of a respective candidate job, preemption optimization system 126 can use several different methods, including implicit and explicit methods. In one embodiment, preemption optimization system 126 maintains a data structure, e.g., in a job scheduler component, that indicates (i.e., stores) the last checkpoint time (i.e., the most recent or latest checkpoint time) detected for each running job. … (3) in a container environment, implicitly by monitoring volumes mounted to a container to detect changes in files that indicate completion of a checkpoint or by monitoring specific network traffic that would indicate completion of a snapshot, e.g., monitoring network traffic to an object store; and (4) for AI training jobs, implicitly by monitoring the contents of files that are specific for the AI training framework to detect completion of a checkpoint, in which most AI frameworks have specific identifiable files where calculation results are stored, progress is recorded, and stable checkpoints can be identified.”; Table 1 and [0037] further define static information “In Table 1, an example set of jobs 1-4 is shown and the metrics for each, including job type (the type of model training), … resources requested (amount of compute resources requested), … and predicted time (output that the ML model predicts).” where Table 1 shows in example resources requested includes CPU, GPU, and memory size (GB) such that a resource can be one or all 3 items]; and determining workload characteristics of running container programs based at least the information and the information; selecting, based at least on the workload characteristics of each of the running container programs in the operational environment, a item to be a preemption target from among the plurality of containers; and based at least on the selecting, redeploying execution of the container program of the selected container [for the limitations above, see at least [0010, 0028] container programs; [0036] use stored data “For calculating the predicted remaining time for completion of a respective candidate job, preemption optimization system 126 can use several different methods, including implicit and explicit methods. In one embodiment, preemption optimization system 126 maintains a data structure, e.g., in a job scheduler component, that indicates (i.e., stores) the predicted total time for completion for each running job and a start time of each running job. Thus, preemption optimization system 126 calculates the predicted remaining time for completion of a job using the data in the data structure as the difference between the predicted total time, the start time, and the current time. In several embodiments, preemption optimization system 126 predicts the total time or remaining time for a running job in multiple ways: (1) explicitly using a scheduler API by which a job indicates its predicted total time for completion (e.g., based on statistics); (2) implicitly by applying job profiling based on which resources are needed and which resources are available to predict the total time for completion of a job, this can be done using extrapolation or machine learning models; and (3) for AI training jobs, implicitly using information on a current training stage and future training stages to predict the remaining time for a job.”; [0038-0042] infer workload “In step 240, preemption optimization system 126 ranks the candidate jobs based on the dynamic and static information. In an embodiment, responsive to identifying the dynamic and static information for each candidate job, preemption optimization system 126 ranks the candidate jobs. In an embodiment, preemption optimization system 126 ranks the candidate jobs based on the dynamic and static information with the objective of minimizing loss of computation (i.e., computation time of candidate jobs for preemption) in addition to optimizing the benefit and utilization of the cluster resources.”; [0043] select a container (job) “In step 250, preemption optimization system 126 attempts to preempt a top N candidate jobs whose released resources in combination with the available resources of the cluster satisfy a resource requirement of the pending job. N is the number of candidate jobs required whose released resources in combination with the available resources of the cluster satisfy a resource requirement of the pending job. In an embodiment, responsive to ranking the candidate jobs, preemption optimization system 126 attempts to preempt a top N candidate jobs based on the ranking whose released resources in combination with the available resources of the cluster satisfy a resource requirement of the pending job. If one of the top N candidate jobs has a no-preemption policy enabled, then preemption optimization system 126 will not be able to successfully preempt that candidate job and will go to a next top candidate job to attempt to preempt until a successful preemption occurs of candidate jobs whose released resources in combination with the available resources of the cluster satisfy a resource requirement of the pending job.” [0044] “In step 260, responsive to a successful preemption of the top candidate jobs, preemption optimization system 126 initiates running the pending job.”]. Malvankar [0027-0028, 0035] teaches container but doesn’t/don’t explicitly teach however, in the field pertinent to the particular problem with which the applicant was concerned such as container scheduling, Martίnez discloses acquiring, as container deployment instruction information, a deployment instruction of containers for execution of a respective container on the resources in the operational environment [see at least [pg 2] “Preemption is the following process: if a new Pod needs to be scheduled but doesn't have any suitable Node with enough resources, then kube-scheduler will check if by evicting (terminating) some Pods with lower priority the new Pod can be part of that Node. Let's first understand how Kubernetes scheduling works.”; [pg 5] Pod contains at least one container and more instructions (priority) “In Kubernetes, Pods are giving one of three QoS Classes, which will define how likely they are going to be evicted in case of lack of resources, from less likely to more likely: Guaranteed Burstable BestEffort How are these QoS Classes assigned to Pods? This is based on limits and requests for CPU and memory. As a reminder: Limits: maximum amount of a resource that a container can use. Requests: minimum desired amount of resources for a container to run. For more information about limits and requests, please check Understanding Kubernetes limits and requests. Guaranteed A Pod is assigned with a QoS Class of Guaranteed if: All containers in the Pod have both Limits and Requests set for CPU and memory. All containers in the Pod have the same value for CPU Limit and CPU Request. All containers in the Pod have the same value for memory Limit and memory Request. A Guaranteed Pod won't be evicted in normal circumstances to allocate another Pod in the node. Burstable A Pod is assigned with a QoS Class of Burstable if: It doesn't have QoS Class of Guaranteed. Either Limits or Requests have been set for a container in the Pod. A Burstable Pod can be evicted, but less likely than the next category. BestEffort A Pod will be assigned with a QoS Class of BestEffort if: No Limits and Requests are set for any container in the Pod. BestEffort Pods have the highest chance of eviction in case of a node-pressure process happening in the node.”]; acquiring, as container deployment information, a deployment of the containers in the operational environment [see at least [pg 2] location of container (pod) “Let's first understand how Kubernetes scheduling works. Pod Scheduling Kubernetes Scheduling is the process where Pods are assigned to nodes. By default, there's a Kubernetes entity responsible for scheduling, called kube-scheduler which will be running in the control plane. The Pod will start in the Pending state until a matching node is found. The process of assigning a Pod to a Node follows this sequence: 1. Filtering 2. Scoring Filtering During the Filtering step, kube-scheduler will select all Nodes where the current Pod might be placed. Features like Taints and Tolerations will be taken into account here. Once finished, it will have a list of suitable Nodes for that Pod.”]; acquiring, as container monitoring information, an operational status of the resources operating in the operational environment [see at least [pg 6] “As mentioned, QoS Classes will be taken into account for node-pressure eviction. Here's the process that happens internally. The kubelet ranks the Pods to be evicted in the following order: BestEffort Pods or Burstable Pods where usage exceeds requests Burstable Pods where usage is below requests or Guaranteed Pods”]; workload characteristics of running container based at least on the container deployment information and the container monitoring information; selecting, based at least on the workload characteristics of each of the running container in the operational environment, a container currently executing to be a preemption target from among the plurality of containers [see at least [pg 6] “The kubelet ranks the Pods to be evicted in the following order: BestEffort Pods or Burstable Pods where usage exceeds requests Burstable Pods where usage is below requests or Guaranteed Pods”]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Malvankar with Martίnez to include the limitation(s) above as disclosed by Martίnez. Doing so would improve Malvankar’s (Malvankar) job scheduling via greater information beyond generic priority to determine scheduling [see at least Martίnez [pg 1, 5-6] ]. Furthermore, all of the claimed elements were known in the prior arts of a) Malvankar and b) Martίnez and c) one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention. Malvankar in view of Martίnez (Malvankar) [0027-0028, 0035] teaches container but doesn’t/don’t explicitly teach however, in the field pertinent to the particular problem with which the applicant was concerned such as container scheduling, Byers discloses a plurality of resources in an operational environment, the plurality of resources including at least one graphics processing unit (GPU) and at least one central processing unit (CPU), the at least one CPU having lower processing performance than the at least one GPU: on the plurality of resources in the operational environment; { on the plurality of resources in the operational environment; - claim 1} the plurality of resources operating in the operational environment; selecting, based at least on the workload characteristics of each of the running in the operational environment, a container currently executing on the at least one GPU to be a target from among the plurality of containers; and based at least on the selecting, redeploying execution of the selected container from executing on the at least one GPU to executing on the at least one CPU [for the limitations above, see at least [0016, 0031] low resource (CPU) to high resources (GPU) “For example, if the ML system 200 is not meeting performance requirements due to slow processing of data and data training by learning functions 205 and/or slow execution of a trained model by the inference functions 207, the learning functions 205 and/or the inference functions 207 may be moved to a faster processing resource type. For example, the functions may be moved from a CPU to a FPGA, GPU, and/or TPU.”; [0035] redeploy (as noted in [0044]) container to high resource or lower resource based on determined current container requirements “For example, the ML inference functions 207 are initially deployed on a certain set of the processing resources for a typical load (e.g., CPU 304 a), but if a surge in workloads is detected by the MLOM 350, the ML inference function 207 is redeployed to bring additional and/or higher performing resources (e.g., a FPGA 304 b or GPU 304 c) to bear on the additional workloads until the overload subsides”; [0042] redeploy from high resource to low resource “While described above in relation to increased performance for the ML learning function and the ML inference function, the MLOM 350 may also determine adjusted processing resource type changes to reduce a network utilization expense of the ML system. For example, after an increased capacity process resource is no longer needed for the ML learning functions 205, the MLOM 350 determines to adjust the processing resources utilized by the ML functions 205 to an optimized deployment for ML system costs on the network 300. For example, the ML learning functions 205 workloads may move from a TPU to a CPU.”; [0043-0044] redeploy from low resource need to high resource need “At block 418, the MLOM 350 determines a reallocation of the first and second allocations of resources to provide an increased performance to the ML system. For example, if ML inference functions are executing below the performance parameters on a network node and/or network level and the ML learning functions are over-performing, the allocation of the processing resource dedicated to the ML learning functions may be reallocated to the ML inference functions, such that the workloads of the inference functions may be processed more efficiently. The resource reallocation may also include a reallocation of resources across several network nodes and/or network levels. At block 420, the MLOM 350 executes the one or more system adjustments. in some examples, the MLOM 350 executes the system adjustments for the ML system 200 by causing containers on the various determined network levels, processing resources, and/or reallocated processing resources, to begin execution and instructs the ML functions to begin utilizing the containers on the determined network levels and processing resources. In some examples, the MLOM 350 uses a container based control messaging system to implement the one or more system adjustments.”]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Malvankar in view of Martίnez with Byers to include the limitation(s) above as disclosed by Byers. Doing so would improve Malvankar in view of Martίnez’s (Malvankar) job scheduling via greater analysis of redeployment requirements [see at least Byers [0002] ]. Furthermore, all of the claimed elements were known in the prior arts of a) Malvankar in view of Martίnez and b) Byers and c) one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention. Malvankar in view of Martίnez and Byers (Malvankar) [0027-0028, 0035] teaches container but doesn’t/don’t explicitly teach however, in the field pertinent to the particular problem with which the applicant was concerned such as container scheduling, Beveridge discloses plurality of containers in the operational environment; plurality of containers in the operational environment [for the limitations above, see at least [0019] “Containers 1301 to 130Y (collectively referred to as containers 130 and individually referred to as container 130) are software instances that enable virtualization at the OS level.”]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Malvankar in view of Martίnez and Byers with Beveridge discloses to include the limitation(s) above as disclosed by Beveridge discloses. Doing so would improve Malvankar in view of Martίnez and Byers’s (Malvankar) job scheduling via greater information beyond generic priority to determine scheduling [see at least Beveridge discloses [0021, 0074] ]. Furthermore, all of the claimed elements were known in the prior arts of a) Malvankar in view of Martίnez and Byers and b) Beveridge and c) one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention. Regarding claim 2, the claim(s) recite(s) analogous limitations to claim(s) 7 above and is/are therefore rejected on the same premise. Regarding claims 6 and 10 (currently amended), modified Malvankar teaches the method according to claim 7, . Modified Malvankar (Malvankar) [0027-0028, 0035] teaches container but doesn’t/don’t explicitly teach however, in the field pertinent to the particular problem with which the applicant was concerned such as container scheduling, Martίnez discloses wherein the container monitoring information includes a utilization amount of each of the plurality of containers, and the selecting of the container to be the preemption target involves selecting the container to be the preemption target based at least on the utilization amount [for the limitations above, see at least [pg 5] Pod contains at least one container and more instructions (priority) “In Kubernetes, Pods are giving one of three QoS Classes, which will define how likely they are going to be evicted in case of lack of resources, from less likely to more likely: Guaranteed Burstable BestEffort How are these QoS Classes assigned to Pods? This is based on limits and requests for CPU and memory. As a reminder: Limits: maximum amount of a resource that a container can use. Requests: minimum desired amount of resources for a container to run. For more information about limits and requests, please check Understanding Kubernetes limits and requests. Guaranteed A Pod is assigned with a QoS Class of Guaranteed if: All containers in the Pod have both Limits and Requests set for CPU and memory. All containers in the Pod have the same value for CPU Limit and CPU Request. All containers in the Pod have the same value for memory Limit and memory Request. A Guaranteed Pod won't be evicted in normal circumstances to allocate another Pod in the node. Burstable A Pod is assigned with a QoS Class of Burstable if: It doesn't have QoS Class of Guaranteed. Either Limits or Requests have been set for a container in the Pod. A Burstable Pod can be evicted, but less likely than the next category. BestEffort A Pod will be assigned with a QoS Class of BestEffort if: No Limits and Requests are set for any container in the Pod. BestEffort Pods have the highest chance of eviction in case of a node-pressure process happening in the node.”; [pg 6] “As mentioned, QoS Classes will be taken into account for node-pressure eviction. Here's the process that happens internally. The kubelet ranks the Pods to be evicted in the following order: BestEffort Pods or Burstable Pods where usage exceeds requests Burstable Pods where usage is below requests or Guaranteed Pods”]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify modified Malvankar with Martίnez to include the limitation(s) above as disclosed by Martίnez. Doing so would improve Malvankar’s (Malvankar) job scheduling via greater information beyond generic priority to determine scheduling [see at least Martίnez [pg 1, 5-6] ]. Furthermore, all of the claimed elements were known in the prior arts of a) modified Malvankar and b) Martίnez and c) one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention. Modified Malvankar (Malvankar) [0027-0028, 0035] teaches container but doesn’t/don’t explicitly teach however, in the field pertinent to the particular problem with which the applicant was concerned such as container scheduling, Beveridge discloses a VRAM utilization amount of each of the plurality of containers, and the selecting of the container based at least on the VRAM utilization amount [for the limitations above, see at least [0021] “Each container 130 may be assigned resources for running the application 132. For example, container 130 running on a VM 104 may be assigned VCPU resources and VRAM resources of the VM 104. For example, each container 130 may be allocated a certain number of VCPUs and a certain amount of VRAM, such as based on a request and/or limit associated with the container 130.”; [0074] “Continuing, at 210, the number (quantity) of containerized workloads (e.g., pods, containers, etc.) running on the VMs 104 is changed (e.g., increased or decreased) based on the change in the number of VMs 104 and/or on a change in quota for one or more resource types, as discussed, such as a CPU quota, memory allocation quota, etc. In certain aspects, container control plane 160 or an operator is configured to automatically change the number of containerized workloads based on the change in the number of VMs 104 and/or on a change in quota for one or more resource types. In certain aspects, scaling agent 180 determines a change to the number of containerized workloads based on the change in the number of VMs 104 and/or on a change in quota for one or more resource types and instructs container control plane 160 and/or an operator accordingly. For example, as discussed, like a VM 104 uses resources of a host 102, a container 130 uses virtual resources of a VM 104. The number of containers 130 on one or more VM 104 s for running a containerized workload may be changed according to any of the same or similar techniques discussed herein for changing the number of VMs 104 on one or more hosts 102, including reactively, predictively, with or without oversubscription, etc. In particular, a container 130 may have a container configuration indicating a number of resources (e.g., VCPUs, memory, etc.) used per container, and the one or more VMs 104 have a number of available resources (e.g., VCPUs, VRAM, etc.). Therefore, the number of containers is changed based on the number of available resources of the one or more VMs 104.”]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify modified Malvankar with Beveridge discloses to include the limitation(s) above as disclosed by Beveridge discloses. Doing so would improve Malvankar’s (Malvankar) job scheduling via greater information beyond generic priority to determine scheduling [see at least Beveridge discloses [0021, 0074] ]. Furthermore, all of the claimed elements were known in the prior arts of a) modified Malvankar and b) Beveridge and c) one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention. Regarding claim 8 (currently amended), modified Malvankar teaches the method according to claim 7, as well as wherein redeploying execution of the container program of the selected container and the container program of the selected container. Modified Malvankar (Malvankar) [0027-0028, 0035] teaches container but doesn’t/don’t explicitly teach however, in the field pertinent to the particular problem with which the applicant was concerned such as container scheduling, Byers discloses wherein redeploying execution of the selected container includes deploying the selected container in the operational environment such that the container is processed solely by the at least one CPU without using a GPU, including the at least one GPU, among the resources [see at least [0016, 0031] low resource (CPU) to high resources (GPU) “For example, if the ML system 200 is not meeting performance requirements due to slow processing of data and data training by learning functions 205 and/or slow execution of a trained model by the inference functions 207, the learning functions 205 and/or the inference functions 207 may be moved to a faster processing resource type. For example, the functions may be moved from a CPU to a FPGA, GPU, and/or TPU.”; [0035] redeploy (as noted in [0044]) container to high resource or lower resource based on determined current container requirements “For example, the ML inference functions 207 are initially deployed on a certain set of the processing resources for a typical load (e.g., CPU 304 a), but if a surge in workloads is detected by the MLOM 350, the ML inference function 207 is redeployed to bring additional and/or higher performing resources (e.g., a FPGA 304 b or GPU 304 c) to bear on the additional workloads until the overload subsides”; [0042] redeploy from high resource to low resource “While described above in relation to increased performance for the ML learning function and the ML inference function, the MLOM 350 may also determine adjusted processing resource type changes to reduce a network utilization expense of the ML system. For example, after an increased capacity process resource is no longer needed for the ML learning functions 205, the MLOM 350 determines to adjust the processing resources utilized by the ML functions 205 to an optimized deployment for ML system costs on the network 300. For example, the ML learning functions 205 workloads may move from a TPU to a CPU.”; [0043-0044] redeploy from low resource need to high resource need “At block 418, the MLOM 350 determines a reallocation of the first and second allocations of resources to provide an increased performance to the ML system. For example, if ML inference functions are executing below the performance parameters on a network node and/or network level and the ML learning functions are over-performing, the allocation of the processing resource dedicated to the ML learning functions may be reallocated to the ML inference functions, such that the workloads of the inference functions may be processed more efficiently. The resource reallocation may also include a reallocation of resources across several network nodes and/or network levels. At block 420, the MLOM 350 executes the one or more system adjustments. in some examples, the MLOM 350 executes the system adjustments for the ML system 200 by causing containers on the various determined network levels, processing resources, and/or reallocated processing resources, to begin execution and instructs the ML functions to begin utilizing the containers on the determined network levels and processing resources. In some examples, the MLOM 350 uses a container based control messaging system to implement the one or more system adjustments.”]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify modified Malvankar with Byers to include the limitation(s) above as disclosed by Byers. Doing so would improve modified Malvankar’s (Malvankar) job scheduling via greater analysis of redeployment requirements [see at least Byers [0002] ]. Furthermore, all of the claimed elements were known in the prior arts of a) modified Malvankar and b) Byers and c) one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention. Regarding claim 9 (currently amended), modified Malvankar teaches the method according to claim 8, as well as the container monitoring information and Malvankar teaches wherein includes a request processing time and a GPU use, and the selecting of the container to be the preemption target selecting the container to be the preemption target based at least on the request processing time and the GPU use [for the limitations above, see at least [0036] use stored data “For calculating the predicted remaining time for completion of a respective candidate job, preemption optimization system 126 can use several different methods, including implicit and explicit methods. In one embodiment, preemption optimization system 126 maintains a data structure, e.g., in a job scheduler component, that indicates (i.e., stores) the predicted total time for completion for each running job and a start time of each running job. Thus, preemption optimization system 126 calculates the predicted remaining time for completion of a job using the data in the data structure as the difference between the predicted total time, the start time, and the current time. In several embodiments, preemption optimization system 126 predicts the total time or remaining time for a running job in multiple ways: (1) explicitly using a scheduler API by which a job indicates its predicted total time for completion (e.g., based on statistics); (2) implicitly by applying job profiling based on which resources are needed and which resources are available to predict the total time for completion of a job, this can be done using extrapolation or machine learning models; and (3) for AI training jobs, implicitly using information on a current training stage and future training stages to predict the remaining time for a job.”; [0038-0042] infer workload “In step 240, preemption optimization system 126 ranks the candidate jobs based on the dynamic and static information. In an embodiment, responsive to identifying the dynamic and static information for each candidate job, preemption optimization system 126 ranks the candidate jobs. In an embodiment, preemption optimization system 126 ranks the candidate jobs based on the dynamic and static information with the objective of minimizing loss of computation (i.e., computation time of candidate jobs for preemption) in addition to optimizing the benefit and utilization of the cluster resources.”; Table 1 and [0037] further define static information “In Table 1, an example set of jobs 1-4 is shown and the metrics for each, including job type (the type of model training), … resources requested (amount of compute resources requested), … and predicted time (output that the ML model predicts).” where Table 1 shows in example resources requested includes CPU, GPU, and memory size (GB) such that a resource can be one or all 3 items; [0043] select a container (job) “In step 250, preemption optimization system 126 attempts to preempt a top N candidate jobs whose released resources in combination with the available resources of the cluster satisfy a resource requirement of the pending job. N is the number of candidate jobs required whose released resources in combination with the available resources of the cluster satisfy a resource requirement of the pending job. In an embodiment, responsive to ranking the candidate jobs, preemption optimization system 126 attempts to preempt a top N candidate jobs based on the ranking whose released resources in combination with the available resources of the cluster satisfy a resource requirement of the pending job. If one of the top N candidate jobs has a no-preemption policy enabled, then preemption optimization system 126 will not be able to successfully preempt that candidate job and will go to a next top candidate job to attempt to preempt until a successful preemption occurs of candidate jobs whose released resources in combination with the available resources of the cluster satisfy a resource requirement of the pending job.”; [0044] “In step 260, responsive to a successful preemption of the top candidate jobs, preemption optimization system 126 initiates running the pending job.”]. Modified Malvankar (Malvankar) [0027-0028, 0035] teaches container but doesn’t/don’t explicitly teach however, in the field pertinent to the particular problem with which the applicant was concerned such as container scheduling, Beveridge discloses other data and a resource utilization rate for each of the plurality of containers, and the resource utilization rate [for the limitations above, see at least [0012] resource utilization of containers using non limiting resources “Techniques for auto-scaling of workloads are described herein. In particular, in certain aspects, a scaling agent is configured to determine utilization of resources of a data center, and based on the utilization scale a number of workloads running in the data center. In certain aspects, where the utilization is below a threshold, the scaling agent is configured to cause an increase in a number of VMs running in the data center, and in some cases, further cause additional instances of a containerized workload to run on the VMs running in the data center. In certain aspects, where the utilization is above a threshold, the scaling agent is configured to cause a decrease in a number of VMs running in the data center, and in some cases, further cause fewer instances of a containerized workload to run on the VMs running in the data center. In particular, the scaling agent is configured to take as input information regarding a lower layer of the data center (i.e., utilization of physical resources of the data center), and use such input information to affect operation at a higher layer of the data center (i.e., management of containerized workloads running in the data center). Such techniques solve the technical problem of how to use unused capacity of a data center, and provide a technical benefit in that they allow for higher compute densities. Though certain aspects are discussed with respect to pods or containers as workloads instantiated on VMs, the techniques herein are similarly applicable to other types of workloads instantiated on VMs.”; [0021] “Each container 130 may be assigned resources for running the application 132. For example, container 130 running on a VM 104 may be assigned VCPU resources and VRAM resources of the VM 104. For example, each container 130 may be allocated a certain number of VCPUs and a certain amount of VRAM, such as based on a request and/or limit associated with the container 130.”; [0074] “Continuing, at 210, the number (quantity) of containerized workloads (e.g., pods, containers, etc.) running on the VMs 104 is changed (e.g., increased or decreased) based on the change in the number of VMs 104 and/or on a change in quota for one or more resource types, as discussed, such as a CPU quota, memory allocation quota, etc. In certain aspects, container control plane 160 or an operator is configured to automatically change the number of containerized workloads based on the change in the number of VMs 104 and/or on a change in quota for one or more resource types. In certain aspects, scaling agent 180 determines a change to the number of containerized workloads based on the change in the number of VMs 104 and/or on a change in quota for one or more resource types and instructs container control plane 160 and/or an operator accordingly. For example, as discussed, like a VM 104 uses resources of a host 102, a container 130 uses virtual resources of a VM 104. The number of containers 130 on one or more VM 104 s for running a containerized workload may be changed according to any of the same or similar techniques discussed herein for changing the number of VMs 104 on one or more hosts 102, including reactively, predictively, with or without oversubscription, etc. In particular, a container 130 may have a container configuration indicating a number of resources (e.g., VCPUs, memory, etc.) used per container, and the one or more VMs 104 have a number of available resources (e.g., VCPUs, VRAM, etc.). Therefore, the number of containers is changed based on the number of available resources of the one or more VMs 104.”]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify modified Malvankar with Beveridge discloses to include the limitation(s) above as disclosed by Beveridge discloses. Doing so would improve Malvankar’s (Malvankar) job scheduling via greater information beyond generic priority to determine scheduling [see at least Beveridge discloses [0021, 0074] ]. Furthermore, all of the claimed elements were known in the prior arts of a) modified Malvankar and b) Beveridge and c) one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention. Claim(s) 4-5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malvankar in view of Martίnez, Byers and Beveridge as applied to claim(s) 1 above and further in view of Sakthivel et al. (US 2024/0069979 A1). Regarding claim 4 (currently amended), modified Malvankar teaches the management apparatus according to claim 1, as well as container program. Modified Malvankar (Malvankar) [0027-0028, 0035] teaches container but doesn’t/don’t explicitly teach however, in the field pertinent to the particular problem with which the applicant was concerned such as container scheduling, Byers discloses wherein the operations further comprising; following redeployment of the selected container, executing a container on at least one GPU based at least in part on the container having a higher processing requirement than the selected container, and executing the container of the selected container on the at least one CPU while the container is executed on the at least one GPU [for the limitations above, see at least [0016, 0031] low resource (CPU) to high resources (GPU) “For example, if the ML system 200 is not meeting performance requirements due to slow processing of data and data training by learning functions 205 and/or slow execution of a trained model by the inference functions 207, the learning functions 205 and/or the inference functions 207 may be moved to a faster processing resource type. For example, the functions may be moved from a CPU to a FPGA, GPU, and/or TPU.”; [0035] redeploy (as noted in [0044]) container to high resource or lower resource based on determined current container requirements “For example, the ML inference functions 207 are initially deployed on a certain set of the processing resources for a typical load (e.g., CPU 304 a), but if a surge in workloads is detected by the MLOM 350, the ML inference function 207 is redeployed to bring additional and/or higher performing resources (e.g., a FPGA 304 b or GPU 304 c) to bear on the additional workloads until the overload subsides”; [0042] redeploy from high resource to low resource “While described above in relation to increased performance for the ML learning function and the ML inference function, the MLOM 350 may also determine adjusted processing resource type changes to reduce a network utilization expense of the ML system. For example, after an increased capacity process resource is no longer needed for the ML learning functions 205, the MLOM 350 determines to adjust the processing resources utilized by the ML functions 205 to an optimized deployment for ML system costs on the network 300. For example, the ML learning functions 205 workloads may move from a TPU to a CPU.”; [0043-0044] redeploy from low resource need to high resource need “At block 418, the MLOM 350 determines a reallocation of the first and second allocations of resources to provide an increased performance to the ML system. For example, if ML inference functions are executing below the performance parameters on a network node and/or network level and the ML learning functions are over-performing, the allocation of the processing resource dedicated to the ML learning functions may be reallocated to the ML inference functions, such that the workloads of the inference functions may be processed more efficiently. The resource reallocation may also include a reallocation of resources across several network nodes and/or network levels. At block 420, the MLOM 350 executes the one or more system adjustments. in some examples, the MLOM 350 executes the system adjustments for the ML system 200 by causing containers on the various determined network levels, processing resources, and/or reallocated processing resources, to begin execution and instructs the ML functions to begin utilizing the containers on the determined network levels and processing resources. In some examples, the MLOM 350 uses a container based control messaging system to implement the one or more system adjustments.”]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify modified Malvankar with Byers to include the limitation(s) above as disclosed by Byers. Doing so would improve modified Malvankar’s (Malvankar) job scheduling via greater analysis of redeployment requirements [see at least Byers [0002] ]. Furthermore, all of the claimed elements were known in the prior arts of a) modified Malvankar and b) Byers and c) one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention. Modified Malvankar (Malvankar) [0027-0028, 0035] teaches container but doesn’t/don’t explicitly teach however, in the field pertinent to the particular problem with which the applicant was concerned such as container scheduling, Sakthivel discloses following redeployment of the selected container, executing a new container of a new container on at least one GPU based at least in part on the new container having a requirement, and executing the container of the selected container on the at least one CPU while the new container is executed on the at least one GPU [for the limitations above, see at least Tables 1 and 2 and [0035-0036; additionally 0037-0038] where Table 1 shows non limiting examples of currently containers and Table 2 adjustments of container(s) after redeployment “Further, responsive to receiving the request and identifying the container deployment request in the wait queue, the scheduling assistance sub-system 124 determines if the plurality of already-deployed containers C1-C11 includes a containers that can be preempted (hereinafter referred to as a set of preemptable containers). In some examples, scheduling assistance sub-system 124 may identify the set of preemptable containers, from the plurality of already-deployed containers, on a single member node of the plurality of member nodes based on resource allocations (e.g., see Table-1) of the plurality of already-deployed containers C1-C11 and the resource requirements (e.g., see Syntax-1) of the new container. The single member node on which the set of preemptable containers is hosted is hereinafter referred to as a target member node. Details of an example method for identifying the preemptable containers are described in conjunction with a flow diagram of FIG. 4 . For instance, by executing the example method of identifying the preemptable containers, the scheduling assistance sub-system 124 may identify the container C3 as the preemptable container. If the set of preemptable containers is identified, the scheduling assistance sub-system 124 may preempt the set of preemptable containers on the target member node. In one example, container C3 (i.e., one that is identified as preemptable) may be preempted from the member node 102 (e.g., the target member node). After the preemption of the set of preemptable containers, the scheduling assistance sub-system 124 may deploy the new container on the target member node. Based on the resource requirements of 4 CPUs and 4 GPUs of the new container and an instantaneous resource configuration of the member nodes 102-104 (see Table-1), the scheduling assistance sub-system 124 identified the container C3 as the preemptable container and the member node 102 as the target member node (i.e. the member node hosting the preemptable container) . Accordingly, container C3 has been preempted, and instead the new container “NC” (marked with a thicker outline in FIG. 1B) has been deployed on the member node 102. Without limiting the scope of the proposed examples, the container scheduler 120 may analyze the cluster configuration again and deploy the container C3 in the cluster 112 depending on the availability of the resources on the member nodes 102-106. In the present example, the container scheduler 120 may determine that the member node 102 has sufficient resources to meet the resource requirements of container C3 (e.g., 2 CPUs and 1 GPUs). Accordingly, the container scheduler 120 may deploy container C3 on the member node 104 (e.g., marked with a dashed outline in FIG. 1B). Table-2 presented below depicts the resource configuration of the member nodes after the deployment of the new container (NC) on the member node 102 and the redeployment of the container C3 on the member node 104.” [0027] “In some examples, the containers C1-C11 may be configured to execute one or more workloads (e.g., a banking application, a social media application, an online marketplace application, a website, etc.). It is to be noted that, while the containers are described as workload resources for illustration purposes in the description hereinafter, the use of other types of virtual resources, such as, but not limited to, applications (e.g., software programs), virtual machines (VMs), pods, databases, virtual data stores, logical disks, or combinations thereof is also envisioned as the workload resources.”]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify modified Malvankar with Sakthivel to include the limitation(s) above as disclosed by Sakthivel. Doing so would improve modified Malvankar’s (Malvankar) job scheduling via greater analysis of preempting [see at least Sakthivel [0001-0007] ]. Furthermore, all of the claimed elements were known in the prior arts of a) modified Malvankar and b) Sakthivel and c) one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention. Regarding claim 5, the claim(s) recite(s) analogous limitations to claim(s) 9 above and is/are therefore rejected on the same premise. Conclusion When responding to the office action, any new claims and/or limitations should be accompanied by a reference as to where the new claims and/or limitations are supported in the original disclosure. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP §706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES WEBB whose telephone number is (313)446-6615. The examiner can normally be reached on M-F 10-3. 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, Jerry O’Connor can be reached on (571) 272-6787. 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. /JAMES WEBB/Examiner, Art Unit 3624