CTNF 19/077,487 CTNF 93309 DETAILED ACTION 07-03-aia AIA 15-10-aia 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 07-06 AIA 15-10-15 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 3/12/25. Claim(s) none is/are amended, claim(s) none 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 as there are no amendments. Therefore, Claims 1-10 is/are pending and have been addressed below. Information Disclosure Statement The information disclosure statement(s) (IDS) submitted on 3/12/25 was/were considered by the examiner. Response to Arguments There are no arguments. 07-30-03-h AIA Claim Interpretation 07-30-03 AIA The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. 07-30-05 The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph: (A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and (C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action and those claims are 1-6, specifically claims 1-2. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Claim Rejections - 35 USC § 112 07-30-02 AIA 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. 07-34-01 AIA Claim (s) 1-6 is/are 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 pre-AIA the applicant regards as the invention. Claims 1-6 s/are rejected . Claim(s) 1 and 2 state(s) the limitation “ configured to ” and as noted above invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification is devoid of adequate structure to perform the claimed function. In particular, the specification merely states the claimed function of the configured to. There is no disclosure of any particular structure, either explicitly or inherently, to perform the configured to. The specification does not provide sufficient details such that one of ordinary skill in the art would understand which structures perform(s) the claimed function as noted by instant specification [0022-0025, 0071]. Therefore, claims 1 and 2 is/are indefinite and is/are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. Appropriate correction/clarification is required. Claim(s) 2-6 is/are rejected because they depend on claim(s) 1 and 2. 07-30-01 AIA 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. Generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed. Ariad, 598 F.3d at 1350, 94 USPQ2d at 1171; Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement because it failed to support the scope of the genus claimed)”. Additionally, original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Ariad, 598 F.3d at 1349, 94 USPQ2d at 1171. Claim(s) 1-6 is/are rejected . Representative claims 1 and 2 recite(s) “ configured to .” Initially, Examiner notes the bolded portion recites “configured to” which does not appear to be supported by the originally filed disclosure. 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 pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. As described above in the 112b rejection, the disclosure does not provide adequate structure to perform the claimed function(s) of module configured to, generator configured to, module is further configured, generator is further configured to. Examiner notes the closest portions of the original disclosure include [0022-0025, 0071]. The specification does not demonstrate that applicant has made an invention that achieves the claimed function because the invention is not described with sufficient detail that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention. Therefore, claims 1 and 2 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 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Appropriate correction/clarification is required. Claim(s) 2-6 is/are rejected because they depend on claim(s) 1 and 2. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claim(s) 1-10 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter as noted below. The limitation(s) below for representative claims 1 and 7 that, under its broadest reasonable interpretation, is directed to container preemption. Step 1 : The claim(s) as drafted, is/are a process (claims 7-10 recites a series of steps) and system (claims 1-6 recites a series of components). Step 2A – Prong 1 : The claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s): Claim 7: an IT operation management method used by an IT operation management apparatus selecting a container to be a preemption target in accordance with characteristics of a workload of each of a plurality of containers in an operational environment, the IT operation management method comprising: acquiring, as container deployment instruction information, a deployment instruction of the containers with respect to the operational environment; acquiring, as container deployment information, a deployment of the containers with respect to the operational environment; acquiring, as container monitoring information, an operational status of resources operating in the operational environment; storing the container deployment instruction information, the container deployment information, and the container monitoring information; and inferring workload characteristics of running containers on the basis of the container deployment information and the container monitoring information and selecting a container to be a preemption target from among the plurality of containers . Claim 1: same analysis as claim(s) 7. Dependent claims 2-6 and 8-10 recite the same or similar abstract idea(s) as independent claim(s) 1 and 7 with merely a further narrowing of the abstract idea(s): . The identified limitations of the independent and dependent claims above fall well-within the groupings of subject matter identified by the courts as being abstract concepts of: certain methods of organizing human activity (commercial or legal interactions including advertising, marketing or sales activities or behaviors, or business relations) because the invention is directed to economic and/or business relationships as they are associated with container preemption. Step 2A – Prong 2 : This judicial exception is not integrated into a practical application because: The additional elements unencompassed by the abstract idea include computing, apparatus, units (claim 1), apparatus (claim 7), units (claim 2), processors (claim 3), GPU, CPU (claim(s) 4, 8), GPU (claim(s) 5, 9). The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements as described above with respect to Step 2A Prong 2 fails to describe: Improvements to the functioning of a computer, or to any other technology or technical field - see MPEP 2106.05(a) Applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition – see Vanda Memo Applying the judicial exception with, or by use of, a particular machine – see MPEP 2106.05(b) Effecting a transformation or reduction of a particular article to a different state or thing - see MPEP 2106.05(c) Applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception - see MPEP 2106.05(e) and Vanda Memo. Thus the additional elements as described above with respect to Step 2A Prong 2 are merely invoked as a tool and/or general purpose computer to apply instructions of an abstract idea in a particular technological environment, and/or mere application of an abstract idea in a particular technological environment and merely limiting the use of an abstract idea to a particular technological field do not integrate an abstract idea into a practical application (MPEP 2106.05(f)&(h)). Step 2B : The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Thus the additional elements as described above with respect to Step 2A Prong 2 are merely invoked as a tool and/or a general purpose computer to apply instructions of an abstract idea in a particular technological environment, and/or mere application of an abstract idea in a particular technological environment and merely limiting the use of an abstract idea to a particular technological field do not integrate an abstract idea into a practical application and thus similarly the combination and arrangement of the above identified additional elements when analyzed under Step 2B also fails to necessitate a conclusion that the claims amount to significantly more than the abstract idea for the same reasons as set forth above (MPEP 2106.05(f)&(h)). Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA 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. 07-37-05 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). 07-21-aia AIA Claim (s) 1-2 and 7 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) and Yamato (US 2023/0385178 A1) . Regarding claims 1 and 7 , Malvankar teaches an IT operation management method used by an IT operation management apparatus selecting a item to be a preemption target in accordance with characteristics of a workload of each of a plurality of items in an operational environment, the IT operation management method comprising [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.”] : acquiring, as container deployment instruction information, a deployment instruction with respect to the operational environment; acquiring information {a resource management unit configured to manage – claim 1 }; acquiring information { configured to acquire – claim 1 }; storing the container deployment instruction information, the information, and the information {an environmental information storage unit configured to store – claim 1 } [for the limitations above, see at least [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 inferring workload characteristics of running containers on the basis of the information and the information and selecting a item to be a preemption target from among the plurality of containers {the resource management unit configured to infer – claim 1 } [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.”; [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 an IT operation management method used by an IT operation management selecting a container to be a preemption target in accordance with characteristics of a workload of each of a plurality of containers in an operational environment, the IT operation management method comprising: acquiring, as container deployment instruction information, a deployment instruction of the containers with respect to 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 with respect to 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 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”] ; on the basis of the container deployment information and the container monitoring information and selecting a container 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, Yamato discloses {an operating information acquisition unit configured to perform an action – claim 1 } [see at least [0052] “As illustrated in FIG. 1 , the offload server 1 includes a control section 11, an input/output section 12, a storage section 13, and a verification machine 14 (an accelerator verification device).”; [0056] “The verification machine 14 includes an accelerator such as a GPU, an FPGA, and/or a many-core CPU as the verification environment of the environment adaptive software system.”; [0211] “The control section 11 deploys the execution file derived from the intermediate language to the verification machine 14 and causes the verification machine 14 to execute the execution file to verify the effect of offloading (steps from S21 to S22).”] 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 Yamato to include the limitation(s) above as disclosed by Yamato. Doing so would improve Malvankar in view of Martίnez’s (Malvankar) job scheduling via greater analysis of preempting [see at least Yamato [0001-0007] ]. Furthermore, all of the claimed elements were known in the prior arts of a) Malvankar in view of Martίnez and b) Yamato 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 , modified Malvankar teaches the IT operation management apparatus according to claim 1, and Malvankar teaches further comprising: acquire, as container deployment instruction information, a deployment instruction of the containers with respect to the operational environment, wherein the resource management unit is configured to select a container to be the preemption target on the basis of the container deployment instruction information, the information, and the information [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, Yamato discloses further comprising: a deployment instruction information acquisition unit configured perform an action [see at least [0052] “As illustrated in FIG. 1 , the offload server 1 includes a control section 11, an input/output section 12, a storage section 13, and a verification machine 14 (an accelerator verification device).”; [0054-0055] “The storage section 13 is composed of a hard disk, a flash memory, a RAM (Random Access Memory), and the like. The storage section 13 stores a test case database 131 and a code pattern database 133, and temporarily stores a program (offload program) for executing functions of the control section 11, and information required for the processing of the control section 11, for example, such as an intermediate language file 132. The test case database 131 stores data of test items for the software to be verified. For example, for a database system such as MySQL, a transaction test such as TPC-C is stored. The code pattern database 133 stores accelerator libraries or accelerator IP cores which are usable for replacement and correspond to library names.”] 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 Yamato to include the limitation(s) above as disclosed by Yamato. Doing so would improve modified Malvankar’s (Malvankar) job scheduling via greater analysis of preempting [see at least Yamato [0001-0007] ]. Furthermore, all of the claimed elements were known in the prior arts of a) modified Malvankar and b) Yamato 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 . 07-22-aia AIA Claim (s) 3-4 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malvankar in view of Martίnez and Yamato as applied to claim s 1 and 7 above and further in view of Raju published December 7, 2021 (reference V on the Notice of References Cited) . Regarding claim 3 , modified Malvankar teaches the IT operation management apparatus according to claim 1, and Malvankar teaches wherein the resources include a first processor and a second processor having a lower processing performance than the first processor, and the resource management unit is configured to select, as the preemption target, a container [for the limitations above, see at least 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]. 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, Raju discloses select, as the preemption target, a container to be redeployed from the first processor to the second processor [see at least [pg 2] “Why we need container migration? Container management solution Kubernetes employs preemption which removes existing Pods from a cluster under resource pressure to make room for higher priority pending Pods. Lower priority tasks often experience frequent preemptions. Such tasks can have a state in memory and run for hours doing a lot of computation. Cost of losing the state will be significant, if these tasks are restarted and all those computations have to be done again. Being able to move those stateful containers to new machines for higher resources or load balancing is called stateful migration. The basic steps to migrate running containers from one node to another are to checkpoint the container on the source node, transfer the checkpoint image to the destination node, and restore the container on the destination node. This way, the container is migrated without losing its state.”; Fig. 3 “Live migration using CRIU” and [pg 5] “Live migration using CRIU Live migration attempts to provide a seamless transfer of service between physical machines without impacting client processes or applications. The criu utility can be used to perform live migration of apps or containers. This can be achieved by using a shared file-system such as NFS.”]. 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 Raja discloses to include the limitation(s) above as disclosed by Raja discloses. Doing so would improve Malvankar’s (Malvankar) job scheduling via greater information beyond generic priority to determine scheduling [see at least Raja discloses [0021, 0074] ]. Furthermore, all of the claimed elements were known in the prior arts of a) modified Malvankar and b) Raja 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 4 , modified Malvankar teaches the IT operation management apparatus according to claim 3, and Malvankar teaches wherein the first processor is a GPU, and the second processor is a CPU [see at least 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]. Regarding claim 8 , modified Malvankar teaches the IT operation management method according to claim 7, and Malvankar teaches CPU without using a GPU among the resources [see at least 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]. 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, Raju discloses wherein the selecting of the container to be the preemption target involves deploying the container to be the preemption target in the operational environment such that the container is processed by a different resource [for the limitations above, see at least [pg 2] “Why we need container migration? Container management solution Kubernetes employs preemption which removes existing Pods from a cluster under resource pressure to make room for higher priority pending Pods. Lower priority tasks often experience frequent preemptions. Such tasks can have a state in memory and run for hours doing a lot of computation. Cost of losing the state will be significant, if these tasks are restarted and all those computations have to be done again. Being able to move those stateful containers to new machines for higher resources or load balancing is called stateful migration. The basic steps to migrate running containers from one node to another are to checkpoint the container on the source node, transfer the checkpoint image to the destination node, and restore the container on the destination node. This way, the container is migrated without losing its state.”; Fig. 3 “Live migration using CRIU” and [pg 5] “Live migration using CRIU Live migration attempts to provide a seamless transfer of service between physical machines without impacting client processes or applications. The criu utility can be used to perform live migration of apps or containers. This can be achieved by using a shared file-system such as NFS.”]. 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 Raja discloses to include the limitation(s) above as disclosed by Raja discloses. Doing so would improve Malvankar’s (Malvankar) job scheduling via greater information beyond generic priority to determine scheduling [see at least Raja discloses [0021, 0074] ]. Furthermore, all of the claimed elements were known in the prior arts of a) modified Malvankar and b) Raja 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 . 07-22-aia AIA Claim (s) 5 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malvankar in view of Martίnez, Yamato, and Raju as applied to claim 8 above and further in view of Beveridge (US 2024/0419470 A1) . Regarding claims 5 and 9 , modified Malvankar teaches the IT operation management 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 involves selecting the container to be the preemption target on the basis of 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 . 07-22-aia AIA Claim (s) 6 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Malvankar in view of Martίnez and Yamato as applied to claim s 1 and 7 above and further in view of Beveridge . Regarding claims 6 and 10 , modified Malvankar teaches the IT operation management 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 on the basis of 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 on the basis of 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 . 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. 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Yamato – WO 2022/079748 A1 (relevant because it teaches job processing of a computer as noted in the instant application specification) as noted in the IDS dated 3/12/25 Huerta – How to rightsize the Kubernetes resource limits (relevant because it teaches job processing) 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 Application/Control Number: 19/077,487 Page 2 Art Unit: 3624 Application/Control Number: 19/077,487 Page 3 Art Unit: 3624 Application/Control Number: 19/077,487 Page 4 Art Unit: 3624 Application/Control Number: 19/077,487 Page 5 Art Unit: 3624 Application/Control Number: 19/077,487 Page 6 Art Unit: 3624 Application/Control Number: 19/077,487 Page 7 Art Unit: 3624 Application/Control Number: 19/077,487 Page 8 Art Unit: 3624 Application/Control Number: 19/077,487 Page 9 Art Unit: 3624 Application/Control Number: 19/077,487 Page 10 Art Unit: 3624 Application/Control Number: 19/077,487 Page 11 Art Unit: 3624 Application/Control Number: 19/077,487 Page 12 Art Unit: 3624 Application/Control Number: 19/077,487 Page 13 Art Unit: 3624 Application/Control Number: 19/077,487 Page 14 Art Unit: 3624 Application/Control Number: 19/077,487 Page 15 Art Unit: 3624 Application/Control Number: 19/077,487 Page 16 Art Unit: 3624 Application/Control Number: 19/077,487 Page 17 Art Unit: 3624 Application/Control Number: 19/077,487 Page 18 Art Unit: 3624 Application/Control Number: 19/077,487 Page 19 Art Unit: 3624 Application/Control Number: 19/077,487 Page 20 Art Unit: 3624 Application/Control Number: 19/077,487 Page 21 Art Unit: 3624 Application/Control Number: 19/077,487 Page 22 Art Unit: 3624 Application/Control Number: 19/077,487 Page 23 Art Unit: 3624 Application/Control Number: 19/077,487 Page 24 Art Unit: 3624 Application/Control Number: 19/077,487 Page 25 Art Unit: 3624 Application/Control Number: 19/077,487 Page 26 Art Unit: 3624 Application/Control Number: 19/077,487 Page 27 Art Unit: 3624 Application/Control Number: 19/077,487 Page 28 Art Unit: 3624 Application/Control Number: 19/077,487 Page 29 Art Unit: 3624 Application/Control Number: 19/077,487 Page 30 Art Unit: 3624 Application/Control Number: 19/077,487 Page 32 Art Unit: 3624 Application/Control Number: 19/077,487 Page 33 Art Unit: 3624 Application/Control Number: 19/077,487 Page 34 Art Unit: 3624 Application/Control Number: 19/077,487 Page 35 Art Unit: 3624 Application/Control Number: 19/077,487 Page 36 Art Unit: 3624 Application/Control Number: 19/077,487 Page 37 Art Unit: 3624 Application/Control Number: 19/077,487 Page 38 Art Unit: 3624 Application/Control Number: 19/077,487 Page 39 Art Unit: 3624 Application/Control Number: 19/077,487 Page 40 Art Unit: 3624 Application/Control Number: 19/077,487 Page 41 Art Unit: 3624
Prosecution Insights