DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed on 12/02/2025.
Claims 1-2, 4, 6-12, 14, and 16-21 are pending.
Claim Objections
Claim 21 is objected to because of the following informalities: “the service broker associated with the accelerator” should read “the service broker associated with the one or more accelerators”. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 21 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 21 recites the limitation "the service broker associated with the accelerator" in line 3. There is insufficient antecedent basis for this limitation in the claim. There is no mention of a service broker associated with the accelerator prior in the claim or in claim 1 from which the claim depends. Claim 1 does include “a service broker associated with the accelerator service instance”; however, it is unclear whether this limitation is meant to refer to the same service broker or not. For the sake of compact prosecution, Examiner will interpret this limitation to mean “a service broker associated with the accelerator”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 9-11, and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao (US 2023/0236902 A1) in view of Beeler (US 11449963 B1) in view of Ivanov (US 2023/0239301 A1) in view of Mellquist (US 2021/0397465 A1).
Regarding Claim 1, Zhao teaches:
A method comprising: identifying, by an accelerator management job (AMJ), “In light of these drawbacks, many enterprises would benefit from an automated system that provisions GPU VMs on demand to employees that need them, without interrupting the employee's ongoing work on a different, non-GPU VM” [Zhao ¶ 4]. “Examples described herein include systems and methods for dynamic VM provisioning across cloud service providers.” [Zhao ¶ 6]. “At stage 210, the VDI end user can submit a machine learning workload request through the virtual desktop of the non-GPU VM. As mentioned above, this workload request need not be limited to machine learning, but can instead be any computationally intensive workload, such as an artificial intelligence workload. The user can submit the workload request in a variety of manners” [Zhao ¶ 43].
an accelerator service instance associated with a workload, “If at least one GPU VM is available, then at stage 140 the control plane instructs the non-GPU VM to send the workload request to the GPU VM” [Zhao ¶ 27]. “The user can submit the workload request in a variety of manners. In one example, an application executing on the non-GPU VM recognizes a computationally intensive workload and prompts the user to accelerate the workload by utilizing a remote GPU. In this example, the application can be the same application in which the workload originates or is requested. In another example, the application is a standalone application that monitors for sufficiently heavy workloads and provides the prompt to the virtual desktop user” [Zhao ¶ 44].
wherein the AMJ runs in a same environment as the workload, “In yet another example, the user's application automatically identifies and submits a machine-learning workload to the control plane without the user being involved. In other examples, an operating system associated with the virtual desktop can perform some or all of the application-level functionality described above with respect to this stage” [Zhao ¶ 44, Fig. 2 Examiner notes the request for the use of GPUs 212 comes from the non-gpu vm in figure 2].
and wherein the environment is a container as a service (CAAS) environment, such that both the workload and the AMJ run in the CAAS environment; “Examples described herein include systems and methods for dynamic VM provisioning across cloud service providers” [Zhao ¶ 6]. “For example, each cloud service may utilize one or more hypervisors that manage VMs within that cloud service, but not other cloud services. This presents problems when an employee is utilizing a non-GPU VM on one cloud service provider but wants to run a machine learning workload that would benefit from a GPU VM provided by a different cloud service provider” [Zhao ¶ 4].
calling, by the AMJ, a service broker associated with the accelerator service instance to obtain information needed to use the accelerator service instance; “After receiving the workload request at stage 210, the non-GPU VM can request identification of an available GPU VM from the control plane (service broker) at stage 212. In some examples, this stage includes making an API call to the control plane, to which the control plane can respond by providing a list available GPU VMs at stage 214. The identification at stage 214 can be based on a record file stored by the control plane that maintains a record of the availability status of each GPU VM. The availability status can be based on information provided by each GPU VM, such as indications that each GPU VM is busy or not busy” [Zhao ¶ 45]. “Stage 214 can include sending a list of available GPU VMs to the non-GPU VM, including information sufficient to allow the non-GPU VM to connect to the available GPU VMs. In some examples, the control plane selects one particular GPU VM and provides the associated information for that GPU VM to the non-GPU VM at stage 214” [Zhao ¶ 45].
receiving, by the AMJ from the service broker, a catalog for selectable accelerator services; “After receiving the workload request at stage 210, the non-GPU VM can request identification of an available GPU VM from the control plane (service broker) at stage 212. In some examples, this stage includes making an API call to the control plane, to which the control plane can respond by providing a list available GPU VMs (catalog) at stage 214. The identification at stage 214 can be based on a record file stored by the control plane that maintains a record of the availability status of each GPU VM. The availability status can be based on information provided by each GPU VM, such as indications that each GPU VM is busy or not busy” [Zhao ¶ 45]. “Stage 214 can include sending a list of available GPU VMs to the non-GPU VM, including information sufficient to allow the non-GPU VM to connect to the available GPU VMs. In some examples, the control plane selects one particular GPU VM and provides the associated information for that GPU VM to the non-GPU VM at stage 214” [Zhao ¶ 45].
receiving, by the AMJ, an accelerator call and accelerator job information concerning an accelerator job, from the workload, “At stage 216, the non-GPU VM can send the workload request to one of the GPU VMs identified by the control plane at stage 214…In an example, the non-GPU VM formats the workload to a GPU-accessible form before transmission to the GPU VM” [Zhao ¶ 47].
in response to the accelerator call, spinning up, by the AMJ, a new process dedicated to the accelerator job; “At stage 220, the GPU VM can process the workload using the GPU to accelerate the processing. As explained in more detail with respect to FIG. 3, processing the workload can include receiving the workload at a virtual GPU server of the GPU VM, interpreting an API request payload to a graphics driver API, and then calling GPU resources to run the computing” [Zhao ¶ 49].
and returning data, by the AMJ, generated by running the accelerator job, to the workload, “For example, the virtual GPU server of the GPU VM can send the results of the workload to a virtual GPU client of the non-GPU VM at this stage. As part of stage 222, the non-GPU VM can receive the workload response and pass the result to the relevant application executing on the non-GPUVM” [Zhao ¶ 49].
wherein the accelerator service instance is listed in the catalog of the selectable accelerator services. “Stage 214 can include sending a list of available GPU VMs to the non-GPU VM, including information sufficient to allow the non-GPU VM to connect to the available GPU VMs. In some examples, the control plane selects one particular GPU VM and provides the associated information for that GPU VM to the non-GPU VM at stage 214” [Zhao ¶ 45]. “The control plane VM 544 can select an available GPU VM using the same methods described with respect to the VDI control plane 402 in FIG. 4. That is, the control plane VM 544 can access a record of availability for each GPU VM to determine which GPU VMs are available for use” [Zhao ¶ 70].
Zhao fails to explicitly teach wherein the accelerator job information includes inputs and outputs of the accelerator job; as part of the new process, running, by the AMJ, the accelerator job using either the accelerator service instance, or a locally available accelerator.
However, Beeler teaches:
wherein the accelerator job information includes inputs “In one embodiment, an API call from an application 108 is passed to the graphics API 112, such that the graphics API 112 can convert or otherwise translate the instructions into corresponding GPU commands (sometimes referred to as commands or graphics commands) to be processed by a GPU…The API call and the GPU commands may include or otherwise reference resources. For example, in the context of a video game application 108, an API call and/or a GPU command may include texture data and/or geometry data (inputs) that may be the subject of corresponding processing by a remote GPU 110 to generate a frame in a framebuffer” [Beeler Col. 3 Lines 9-15 and 22-27].
and outputs of the accelerator job; “As shown in FIG. 2, the method 200 can commence at operation 202 with receipt of a resource. For example, the replacement engine 152 may receive the resource from the display driver 114 at operation 202. The received resource 40 may be texture data or geometry data corresponding to a frame/portion of a frame to be displayed (outputs) to a user of the client computing device 102” [Beeler Col. 7 Lines 37-43]. “At operation 208, the replacement engine 152 transmits the received resource to the GPU server 104. In one embodiment, the resource is transmitted to the GPU server 104 along with a corresponding GPU command that the resource is part of or is associated with” [Beeler Col. 8 Lines 12-16].
as part of the new process, running, by the AMJ, the accelerator job using either the accelerator service instance, or a locally available accelerator; Although described in relation to the GPU server 104 and corresponding remote GPUs 110, in some embodiments, the display driver 114 may assign GPU commands to either the remote GPUs 110 of the GPU server 104 or a local GPU 116. This hybrid approach allows the local GPU 116 on the client computing device 102 to assist with the processing of GPU commands such that applications 108 running on the client computing device 102 potentially receive performance improvements from both the local GPU 116 and the remote GPUs 110 of the GPU server 104.” [Beeler Col. 13 and 14, Lines 66-67 and 1-8].
Zhao and Beeler are both considered to be analogous to the claimed invention because they are in the same field of accelerator task scheduling. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao to incorporate the teachings of Beeler and include that the accelerator job information includes inputs and outputs of the accelerator job and as part of the new process, running, by the AMJ, the accelerator job using either the accelerator service instance, or a locally available accelerator. Doing so supports efficiency when using costly remote GPUs and can preserve local battery life [Beeler Col. 14, Lines 3-19].
Zhao in view of Beeler fails to teach and wherein the environment is a container as a service (CAAS) environment, receiving, by the AMJ from the service broker, credentials for the selectable accelerator services, wherein the credentials were created by the service broker.
However, Ivanov teaches:
and wherein the environment is a container as a service (CAAS) environment, “The virtualization layer 108 of the illustrated example, and its associated components are configured to run virtual machines. However, in other examples, the virtualization layer 108 may additionally or alternatively be configured to run containers” [Ivanov ¶ 47]. “Virtualizing computer systems provides benefits such as the ability to execute multiple computer systems on a single hardware computer, replicating computer systems, moving computer systems among multiple hardware computers, and so forth. "Infrastructure-as-a-Service" (also commonly referred to as "IaaS") generally describes a suite of technologies provided by a service provider as an integrated solution to allow for elastic creation of a virtualized, networked, and pooled computing platform (sometimes referred to as a "cloud computing platform")” [Ivanov ¶ 2].
receiving, by the AMJ from the service broker, credentials for the selectable accelerator services, “The example vRealize Automation® cloud management platform 140 is provided with the example cloud provider hub circuitry 180 to manage and store account login credentials for different ones of the cloud providers 202, 204, 206 and to manage (e.g., generate, grant, expire, delete, etc.) access tokens (credentials) (e.g., login tokens) for different ones of the tenants 212, 214 to access resources in different ones of the cloud providers 202, 204, 206” [Ivanov ¶ 62]. “At block 1410, the example cloud-agnostic interface adapter 228 uses the first authorization state data (e.g., access configuration data 428) to retrieve an access token from example cloud provider hub circuitry 180” [Ivanov ¶ 167]. “Capability tags may be used to identify resource capabilities of different cloud providers. For example, a cloud provider may have a capability tag indicative of that cloud provider having graphic processor units (GPUs) that satisfy a particular performance threshold, while other cloud providers do not have such a capability tag” [Ivanov ¶ 74].
wherein the credentials were created by the service broker; “The example vRealize Automation® cloud management platform 140 is provided with the example cloud provider hub circuitry 180 to manage and store account login credentials for different ones of the cloud providers 202, 204, 206 and to manage (e.g., generate, grant, expire, delete, etc.) access tokens (credentials) (e.g., login tokens) for different ones of the tenants 212, 214 to access resources in different ones of the cloud providers 202, 204, 206” [Ivanov ¶ 62]. “The example cloud provider hub circuitry 180 is to generate access tokens based on user credentials (e.g., a username, a password, a organization identifier, etc.). The example cloud provider hub circuitry 180 generates valid access tokens for a specific period of time which may be used by the example first tenant 212 and/or the example second tenant 214 to impersonate the example service provider 210 when accessing cloud resources of the cloud providers 202, 204, 206” [Ivanov ¶ 90].
Ivanov is considered to be analogous to the claimed invention because it is in the same field of user data transfer. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler to incorporate the teachings of Ivanov and include that the environment is a container as a service (CAAS) environment, receiving, by the AMJ from the service broker, credentials for the selectable accelerator services, wherein the credentials were created by the service broker. Doing so allows users to access different resources without the need for them to make multiple login credentials. “Using the cloud provider account login credentials, the example service provider 210, the example first tenant 212, and/or the example second tenant 214 can log into (e.g., sign-in to) the example cloud providers 202, 204, 206 and access cloud resources of the example cloud providers 202, 204, 206 without needing to create multiple different cloud provider account login credentials for each of the example service provider 210, the example first tenant 212, and the example second tenant 214 for each of the example cloud providers 202, 204, 206” [Ivanov ¶ 62].
Zhao in view of Beeler in view of Ivanov fails to teach and wherein the environment is a container as a service (CAAS) environment.
However, Mellquist teaches and wherein the environment is a container as a service (CAAS) environment, “Cloud providers deliver cloud computing based services and solutions to businesses and/or individuals. Virtual hardware, software, and infrastructure may be rented and provider-managed to deliver services in accordance with a variety of cloud service models including Container as a Service (CaaS), Virtual Machine as a Service (VMaaS), Storage as a Service (STaaS), and Bare Metal as a Service (BMaaS)” [Mellquist ¶ 1].
Mellquist is considered to be analogous to the claimed invention because it is in the same field of techniques for rebalancing the load in a distributed system. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov to incorporate the teachings of Mellquist and include that the environment is a container as a service (CAAS) environment. Doing so would allow for further service management to be provided to users. “The managed container service may provide a fully-managed solution in which a managed service provider (MSP) operates CaaS instances and assist with the deployment and operation of customers' container-based workloads” [Mellquist ¶ 24].
Regarding Claim 9, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the method as recited in claim 1 as referenced above. Zhao further teaches:
Wherein the accelerator service instance or the locally available accelerator each comprise one of a QPU or a GPU. “If at least one GPU VM is available, then at stage 140 the control plane instructs the non-GPU VM to send the workload request to the GPU VM” [Zhao ¶ 27]. “In another example, the user manually selects a workload and requests acceleration by a remote GPU” [Zhao ¶ 25].
Regarding Claim 10, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the method as recited in claim 1 as referenced above. Zhao further teaches:
Wherein the accelerator service instance is provisioned by a catalog. “Examples described herein include systems and methods for dynamic VM provisioning across cloud service providers. An example method can include providing a VM pool that includes at least one GPU VM and at least one non-GPU VM” [Zhao ¶ 6].
Regarding Claim 11, Zhao teaches:
A non-transitory storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations comprising: “A non-transitory, computer-readable medium containing instructions that, when executed by a hardware-based processor, cause the processor to perform stages for dynamic virtual machine (VM) provisioning across cloud service providers, the stages comprising…” [Zhao Claim 8].
identifying, by an accelerator management job (AMJ), “In light of these drawbacks, many enterprises would benefit from an automated system that provisions GPU VMs on demand to employees that need them, without interrupting the employee's ongoing work on a different, non-GPU VM” [Zhao ¶ 4]. “Examples described herein include systems and methods for dynamic VM provisioning across cloud service providers.” [Zhao ¶ 6]. “At stage 210, the VDI end user can submit a machine learning workload request through the virtual desktop of the non-GPU VM. As mentioned above, this workload request need not be limited to machine learning, but can instead be any computationally intensive workload, such as an artificial intelligence workload. The user can submit the workload request in a variety of manners” [Zhao ¶ 43].
an accelerator service instance associated with a workload, “If at least one GPU VM is available, then at stage 140 the control plane instructs the non-GPU VM to send the workload request to the GPU VM” [Zhao ¶ 27]. “The user can submit the workload request in a variety of manners. In one example, an application executing on the non-GPU VM recognizes a computationally intensive workload and prompts the user to accelerate the workload by utilizing a remote GPU. In this example, the application can be the same application in which the workload originates or is requested. In another example, the application is a standalone application that monitors for sufficiently heavy workloads and provides the prompt to the virtual desktop user” [Zhao ¶ 44].
wherein the AMJ runs in a same environment as the workload, “In yet another example, the user's application automatically identifies and submits a machine-learning workload to the control plane without the user being involved. In other examples, an operating system associated with the virtual desktop can perform some or all of the application-level functionality described above with respect to this stage” [Zhao ¶ 44, Fig. 2 Examiner notes the request for the use of GPUs 212 comes from the non-gpu vm in figure 2].
and wherein the environment is a container as a service (CAAS) environment, such that both the workload and the AMJ run in the CAAS environment; “Examples described herein include systems and methods for dynamic VM provisioning across cloud service providers” [Zhao ¶ 6]. “For example, each cloud service may utilize one or more hypervisors that manage VMs within that cloud service, but not other cloud services. This presents problems when an employee is utilizing a non-GPU VM on one cloud service provider but wants to run a machine learning workload that would benefit from a GPU VM provided by a different cloud service provider” [Zhao ¶ 4].
calling, by the AMJ, a service broker associated with the accelerator service instance to obtain information needed to use the accelerator service instance; “After receiving the workload request at stage 210, the non-GPU VM can request identification of an available GPU VM from the control plane (service broker) at stage 212. In some examples, this stage includes making an API call to the control plane, to which the control plane can respond by providing a list available GPU VMs at stage 214. The identification at stage 214 can be based on a record file stored by the control plane that maintains a record of the availability status of each GPU VM. The availability status can be based on information provided by each GPU VM, such as indications that each GPU VM is busy or not busy” [Zhao ¶ 45]. “Stage 214 can include sending a list of available GPU VMs to the non-GPU VM, including information sufficient to allow the non-GPU VM to connect to the available GPU VMs. In some examples, the control plane selects one particular GPU VM and provides the associated information for that GPU VM to the non-GPU VM at stage 214” [Zhao ¶ 45].
receiving, by the AMJ from the service broker, a catalog for selectable accelerator services; “After receiving the workload request at stage 210, the non-GPU VM can request identification of an available GPU VM from the control plane (service broker) at stage 212. In some examples, this stage includes making an API call to the control plane, to which the control plane can respond by providing a list available GPU VMs (catalog) at stage 214. The identification at stage 214 can be based on a record file stored by the control plane that maintains a record of the availability status of each GPU VM. The availability status can be based on information provided by each GPU VM, such as indications that each GPU VM is busy or not busy” [Zhao ¶ 45]. “Stage 214 can include sending a list of available GPU VMs to the non-GPU VM, including information sufficient to allow the non-GPU VM to connect to the available GPU VMs. In some examples, the control plane selects one particular GPU VM and provides the associated information for that GPU VM to the non-GPU VM at stage 214” [Zhao ¶ 45].
receiving, by the AMJ, an accelerator call and accelerator job information concerning an accelerator job, from the workload, “At stage 216, the non-GPU VM can send the workload request to one of the GPU VMs identified by the control plane at stage 214…In an example, the non-GPU VM formats the workload to a GPU-accessible form before transmission to the GPU VM” [Zhao ¶ 47].
in response to the accelerator call, spinning up, by the AMJ, a new process dedicated to the accelerator job; “At stage 220, the GPU VM can process the workload using the GPU to accelerate the processing. As explained in more detail with respect to FIG. 3, processing the workload can include receiving the workload at a virtual GPU server of the GPU VM, interpreting an API request payload to a graphics driver API, and then calling GPU resources to run the computing” [Zhao ¶ 49].
and returning data, by the AMJ, generated by running the accelerator job, to the workload, “For example, the virtual GPU server of the GPU VM can send the results of the workload to a virtual GPU client of the non-GPU VM at this stage. As part of stage 222, the non-GPU VM can receive the workload response and pass the result to the relevant application executing on the non-GPUVM” [Zhao ¶ 49].
wherein the accelerator service instance is listed in the catalog of the selectable accelerator services. “Stage 214 can include sending a list of available GPU VMs to the non-GPU VM, including information sufficient to allow the non-GPU VM to connect to the available GPU VMs. In some examples, the control plane selects one particular GPU VM and provides the associated information for that GPU VM to the non-GPU VM at stage 214” [Zhao ¶ 45]. “The control plane VM 544 can select an available GPU VM using the same methods described with respect to the VDI control plane 402 in FIG. 4. That is, the control plane VM 544 can access a record of availability for each GPU VM to determine which GPU VMs are available for use” [Zhao ¶ 70].
Zhao fails to explicitly teach wherein the accelerator job information includes inputs and outputs of the accelerator job; as part of the new process, running, by the AMJ, the accelerator job using either the accelerator service instance, or a locally available accelerator.
However, Beeler teaches:
wherein the accelerator job information includes inputs “In one embodiment, an API call from an application 108 is passed to the graphics API 112, such that the graphics API 112 can convert or otherwise translate the instructions into corresponding GPU commands (sometimes referred to as commands or graphics commands) to be processed by a GPU…The API call and the GPU commands may include or otherwise reference resources. For example, in the context of a video game application 108, an API call and/or a GPU command may include texture data and/or geometry data (inputs) that may be the subject of corresponding processing by a remote GPU 110 to generate a frame in a framebuffer” [Beeler Col. 3 Lines 9-15 and 22-27].
and outputs of the accelerator job; “As shown in FIG. 2, the method 200 can commence at operation 202 with receipt of a resource. For example, the replacement engine 152 may receive the resource from the display driver 114 at operation 202. The received resource 40 may be texture data or geometry data corresponding to a frame/portion of a frame to be displayed (outputs) to a user of the client computing device 102” [Beeler Col. 7 Lines 37-43]. “At operation 208, the replacement engine 152 transmits the received resource to the GPU server 104. In one embodiment, the resource is transmitted to the GPU server 104 along with a corresponding GPU command that the resource is part of or is associated with” [Beeler Col. 8 Lines 12-16].
as part of the new process, running, by the AMJ, the accelerator job using either the accelerator service instance, or a locally available accelerator; Although described in relation to the GPU server 104 and corresponding remote GPUs 110, in some embodiments, the display driver 114 may assign GPU commands to either the remote GPUs 110 of the GPU server 104 or a local GPU 116. This hybrid approach allows the local GPU 116 on the client computing device 102 to assist with the processing of GPU commands such that applications 108 running on the client computing device 102 potentially receive performance improvements from both the local GPU 116 and the remote GPUs 110 of the GPU server 104.” [Beeler Col. 13 and 14, Lines 66-67 and 1-8].
Zhao and Beeler are both considered to be analogous to the claimed invention because they are in the same field of accelerator task scheduling. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao to incorporate the teachings of Beeler and include that the accelerator job information includes inputs and outputs of the accelerator job and as part of the new process, running, by the AMJ, the accelerator job using either the accelerator service instance, or a locally available accelerator. Doing so supports efficiency when using costly remote GPUs and can preserve local battery life [Beeler Col. 14, Lines 3-19].
Zhao in view of Beeler fails to teach and wherein the environment is a container as a service (CAAS) environment, receiving, by the AMJ from the service broker, credentials for the selectable accelerator services, wherein the credentials were created by the service broker.
However, Ivanov teaches:
and wherein the environment is a container as a service (CAAS) environment, “The virtualization layer 108 of the illustrated example, and its associated components are configured to run virtual machines. However, in other examples, the virtualization layer 108 may additionally or alternatively be configured to run containers” [Ivanov ¶ 47]. “Virtualizing computer systems provides benefits such as the ability to execute multiple computer systems on a single hardware computer, replicating computer systems, moving computer systems among multiple hardware computers, and so forth. "Infrastructure-as-a-Service" (also commonly referred to as "IaaS") generally describes a suite of technologies provided by a service provider as an integrated solution to allow for elastic creation of a virtualized, networked, and pooled computing platform (sometimes referred to as a "cloud computing platform")” [Ivanov ¶ 2].
receiving, by the AMJ from the service broker, credentials for the selectable accelerator services, “The example vRealize Automation® cloud management platform 140 is provided with the example cloud provider hub circuitry 180 to manage and store account login credentials for different ones of the cloud providers 202, 204, 206 and to manage (e.g., generate, grant, expire, delete, etc.) access tokens (credentials) (e.g., login tokens) for different ones of the tenants 212, 214 to access resources in different ones of the cloud providers 202, 204, 206” [Ivanov ¶ 62]. “At block 1410, the example cloud-agnostic interface adapter 228 uses the first authorization state data (e.g., access configuration data 428) to retrieve an access token from example cloud provider hub circuitry 180” [Ivanov ¶ 167]. “Capability tags may be used to identify resource capabilities of different cloud providers. For example, a cloud provider may have a capability tag indicative of that cloud provider having graphic processor units (GPUs) that satisfy a particular performance threshold, while other cloud providers do not have such a capability tag” [Ivanov ¶ 74].
wherein the credentials were created by the service broker; “The example vRealize Automation® cloud management platform 140 is provided with the example cloud provider hub circuitry 180 to manage and store account login credentials for different ones of the cloud providers 202, 204, 206 and to manage (e.g., generate, grant, expire, delete, etc.) access tokens (credentials) (e.g., login tokens) for different ones of the tenants 212, 214 to access resources in different ones of the cloud providers 202, 204, 206” [Ivanov ¶ 62]. “The example cloud provider hub circuitry 180 is to generate access tokens based on user credentials (e.g., a username, a password, a organization identifier, etc.). The example cloud provider hub circuitry 180 generates valid access tokens for a specific period of time which may be used by the example first tenant 212 and/or the example second tenant 214 to impersonate the example service provider 210 when accessing cloud resources of the cloud providers 202, 204, 206” [Ivanov ¶ 90].
Ivanov is considered to be analogous to the claimed invention because it is in the same field of user data transfer. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler to incorporate the teachings of Ivanov and include that the environment is a container as a service (CAAS) environment, receiving, by the AMJ from the service broker, credentials for the selectable accelerator services, wherein the credentials were created by the service broker. Doing so allows users to access different resources without the need for them to make multiple login credentials. “Using the cloud provider account login credentials, the example service provider 210, the example first tenant 212, and/or the example second tenant 214 can log into (e.g., sign-in to) the example cloud providers 202, 204, 206 and access cloud resources of the example cloud providers 202, 204, 206 without needing to create multiple different cloud provider account login credentials for each of the example service provider 210, the example first tenant 212, and the example second tenant 214 for each of the example cloud providers 202, 204, 206” [Ivanov ¶ 62].
Zhao in view of Beeler in view of Ivanov fails to teach and wherein the environment is a container as a service (CAAS) environment.
However, Mellquist teaches and wherein the environment is a container as a service (CAAS) environment, “Cloud providers deliver cloud computing based services and solutions to businesses and/or individuals. Virtual hardware, software, and infrastructure may be rented and provider-managed to deliver services in accordance with a variety of cloud service models including Container as a Service (CaaS), Virtual Machine as a Service (VMaaS), Storage as a Service (STaaS), and Bare Metal as a Service (BMaaS)” [Mellquist ¶ 1].
Mellquist is considered to be analogous to the claimed invention because it is in the same field of techniques for rebalancing the load in a distributed system. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov to incorporate the teachings of Mellquist and include that the environment is a container as a service (CAAS) environment. Doing so would allow for further service management to be provided to users. “The managed container service may provide a fully-managed solution in which a managed service provider (MSP) operates CaaS instances and assist with the deployment and operation of customers' container-based workloads” [Mellquist ¶ 24].
Regarding Claim 19, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the non-transitory storage medium as recited in claim 11 as referenced above. Zhao further teaches:
wherein the accelerator service instance or the locally available accelerator each comprise one of a QPU or a GPU. “If at least one GPU VM is available, then at stage 140 the control plane instructs the non-GPU VM to send the workload request to the GPU VM” [Zhao ¶ 27]. “In another example, the user manually selects a workload and requests acceleration by a remote GPU” [Zhao ¶ 25].
Regarding Claim 20, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the non-transitory storage medium as recited in claim 11 as referenced above. Zhao further teaches:
wherein the accelerator service instance is provisioned by a catalog. “Examples described herein include systems and methods for dynamic VM provisioning across cloud service providers. An example method can include providing a VM pool that includes at least one GPU VM and at least one non-GPU VM” [Zhao ¶ 6].
Regarding Claim 21, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the method as recited in claim 1 as referenced above. Zhao further teaches:
wherein the accelerator management job determines that a (virtual machine) container of the workload is bound to a service instance with one or more accelerators “At stage 216, the non-GPU VM can send the workload request to one of the GPU VMs identified by the control plane at stage 214” [Zhao ¶ 47].
and calls the service broker associated with the accelerator to obtain the information needed to run that service instance. “After receiving the workload request at stage 210, the non-GPU VM can request identification of an available GPU VM from the control plane (service broker) at stage 212. In some examples, this stage includes making an API call to the control plane, to which the control plane can respond by providing a list available GPU VMs at stage 214” [Zhao ¶ 45]. “Stage 214 can include sending a list of available GPU VMs to the non-GPU VM, including information sufficient to allow the non-GPU VM to connect to the available GPU VMs. In some examples, the control plane selects one particular GPU VM and provides the associated information for that GPU VM to the non-GPU VM at stage 214” [Zhao ¶ 45]. “The virtual GPU client 318 can be a software client executing on the first VM 310 that facilitates communication between the first VM 310 and the second VM 350. For example, the virtual GPU client 318 can open a secure communication channel with a virtual GPU server 352 of the second VM 350. In some examples, a network location associated with the virtual GPU server 352 is provided to the first VM 310 by the control plane. For example, the control plane can provide this information as part of stage 214 described with respect to FIG. 2” [Zhao ¶ 58].
Zhao in view of Beeler fails to explicitly teach wherein the accelerator management job determines that a container of the workload is bound to a service instance with one or more accelerators and calls the service broker associated with the accelerator to obtain the information needed to run that service instance.
However, Ivanov teaches:
wherein the accelerator management job determines that a container of the workload is bound to a service instance with one or more (services) accelerators and calls the service broker associated with the (service) accelerator to obtain the information needed to run that service instance. “In the example of FIG. 2, the service provider 210 allows the example first tenant 212 to access the first cloud provider 202 by providing the first tenant 212 with access to cloud provider account login credentials created by the example service provider 210 for accessing the first cloud provider 202. To manage access to the cloud provider account login credentials, the example cloud credential database 230 of FIG. 2 includes two example rows as follows: The first row is {id: 1, orgid: 2, data: {"providerOrgid": "1", "project": "3", "user": finance@enterprise.com, "password": "Passw0rd123"}} … The example first row above contains a project identification (e.g., "3") which is a project (e.g., location) that the example tenant 212 (e.g., the finance tenant) can access cloud infrastructure resources. The example project is further described below in connection with FIG. 4 … To obtain the cloud provider account login credentials of the second row above, the first tenant 212 submits its enterprise login credentials of the first row above to the cloud-agnostic interface adapter 228. In response, the example cloud-agnostic interface adapter 228 verifies the received enterprise login credentials against the first row above in the cloud credential database 230 and provides the first tenant 212 with access to the cloud provider account login credentials of the second row above” [Ivanov ¶ 67-68, 70, 73]. “The virtualization layer 108 of the illustrated example, and its associated components are configured to run virtual machines. However, in other examples, the virtualization layer 108 may additionally or alternatively be configured to run containers” [Ivanov ¶ 47].
Claims 2, 4, 12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao (US 2023/0236902 A1) in view of Beeler (US 11449963 B1) in view of Ivanov (US 2023/0239301 A1) in view of Mellquist (US 2021/0397465 A1) in view of Thyagaturu (US 2023/0153174 A1).
Regarding claim 2, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the method as recited in claim 1 as referenced above.
Zhao in view of Beeler in view of Ivanov in view of Mellquist fails to teach wherein the accelerator service instance is associated with a container of the workload.
However, Thyagaturu teaches wherein the accelerator service instance is associated with a container of the workload. “Applications (Apps.) 290, executing on platform 250, can cause accelerator device 270 to perform a workload using accelerator driver 282… Note that reference to an application can refer instead or additionally to a virtual machine (VM), container, microservice, processor, or other software” [Thyagaturu ¶ 28, 29].
Thyagaturu is considered to be analogous to the claimed invention because it is in the same field of accelerator task scheduling. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov in view of Mellquist to incorporate the teachings of Thyagaturu and include that the accelerator service instance is associated with a container of the workload. Implementing a container environment would bring flexibility and security benefits. “The isolated nature of containers provides several benefits. First, the software in a container will run the same in different environments. For example, a container that includes PHP and MySQL can run identically on both a Linux® computer and a Windows® machine. Second, containers provide added security since the software will not affect the host operating system” [Thyagaturu ¶ 31].
Regarding claim 4, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the method as recited in claim 1 as referenced above.
Zhao in view of Beeler in view of Ivanov in view of Mellquist fails to teach wherein the accelerator call is received from a container of the workload by way of an application program interface.
However, Thyagaturu teaches wherein the accelerator call is received from a container of the workload by way of an application program interface. “Various examples described herein can perform an application composed of microservices, where a micro service runs in its own process and communicates using protocols (e.g., application program interface (API), a Hypertext Transfer Protocol (HTTP) resource API, message service, remote procedure calls (RPC), or Google RPC (gRPC))… A microservice can be characterized by one or more of: polyglot programming (e.g., code written in multiple languages to capture additional functionality and efficiency not available in a single language), or lightweight container or virtual machine deployment, and decentralized continuous microservice delivery” [Thyagaturu ¶ 29].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov in view of Mellquist to incorporate the teachings of Thyagaturu and include that the accelerator service instance is associated with a container of the workload. Implementing a container environment would bring flexibility and security benefits. “The isolated nature of containers provides several benefits. First, the software in a container will run the same in different environments. For example, a container that includes PHP and MySQL can run identically on both a Linux® computer and a Windows® machine. Second, containers provide added security since the software will not affect the host operating system” [Thyagaturu ¶ 31].
Regarding claim 12, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the non-transitory storage medium as recited in claim 11 as referenced above.
Zhao in view of Beeler in view of Ivanov in view of Mellquist fails to teach wherein the accelerator service instance is associated with a container of the workload.
However, Thyagaturu teaches wherein the accelerator service instance is associated with a container of the workload. “Applications (Apps.) 290, executing on platform 250, can cause accelerator device 270 to perform a workload using accelerator driver 282… Note that reference to an application can refer instead or additionally to a virtual machine (VM), container, microservice, processor, or other software” [Thyagaturu ¶ 28, 29].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov in view of Mellquist to incorporate the teachings of Thyagaturu and include that the accelerator service instance is associated with a container of the workload. Implementing a container environment would bring flexibility and security benefits. “The isolated nature of containers provides several benefits. First, the software in a container will run the same in different environments. For example, a container that includes PHP and MySQL can run identically on both a Linux® computer and a Windows® machine. Second, containers provide added security since the software will not affect the host operating system” [Thyagaturu ¶ 31].
Regarding claim 14, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the non-transitory storage medium as recited in claim 11 as referenced above.
Zhao in view of Beeler in view of Ivanov in view of Mellquist fail to teach wherein the accelerator call is received from a container of the workload by way of an application program interface.
However, Thyagaturu teaches wherein the accelerator call is received from a container of the workload by way of an application program interface. “Various examples described herein can perform an application composed of microservices, where a micro service runs in its own process and communicates using protocols (e.g., application program interface (API), a Hypertext Transfer Protocol (HTTP) resource API, message service, remote procedure calls (RPC), or Google RPC (gRPC))… A microservice can be characterized by one or more of: polyglot programming (e.g., code written in multiple languages to capture additional functionality and efficiency not available in a single language), or lightweight container or virtual machine deployment, and decentralized continuous microservice delivery” [Thyagaturu ¶ 29].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov in view of Mellquist to incorporate the teachings of Thyagaturu and include that the accelerator service instance is associated with a container of the workload. Implementing a container environment would bring flexibility and security benefits. “The isolated nature of containers provides several benefits. First, the software in a container will run the same in different environments. For example, a container that includes PHP and MySQL can run identically on both a Linux® computer and a Windows® machine. Second, containers provide added security since the software will not affect the host operating system” [Thyagaturu ¶ 31].
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao (US 2023/0236902 A1) in view of Beeler (US 11449963 B1) in view of Ivanov (US 2023/0239301 A1) in view of Mellquist (US 2021/0397465 A1) in view of Li (US 2017/0293994 A1).
Regarding Claim 6, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the method as recited in claim 1 as referenced above.
Zhao in view of Beeler in view of Ivanov in view of Mellquist fails to explicitly teach wherein a number of accelerators used by the workload is dynamically adjusted while the workload is running.
However, Li teaches wherein a number of accelerators used by the workload is dynamically adjusted while the workload is running. “Generalizing, the system dynamically increases or decrease the number of GPUs during the workload executions. As will be appreciated, the approach herein provides for dynamic GPU resource allocation in a disaggregate system by adding and removing GPUs based on application needs” [Li ¶ 13].
Li is considered to be analogous to the claimed invention because it is in the same field of accelerator management. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov in view of Mellquist to incorporate the teachings of Li and include that a number of accelerators used by the workload is dynamically adjusted while the workload is running. Including dynamic scaling of a number of accelerators would allow for more efficient GPU utilization [Li ¶ 6, 7].
Regarding Claim 16, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the non-transitory storage medium as recited in claim 11 as referenced above.
Zhao in view of Beeler in view of Ivanov in view of Mellquist fails to explicitly teach wherein a number of accelerators used by the workload is dynamically adjusted while the workload is running.
However, Li teaches wherein a number of accelerators used by the workload is dynamically adjusted while the workload is running. “Generalizing, the system dynamically increases or decrease the number of GPUs during the workload executions. As will be appreciated, the approach herein provides for dynamic GPU resource allocation in a disaggregate system by adding and removing GPUs based on application needs” [Li ¶ 13].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov in view of Mellquist to incorporate the teachings of Li and include that a number of accelerators used by the workload is dynamically adjusted while the workload is running. Including dynamic scaling of a number of accelerators would allow for more efficient GPU utilization [Li ¶ 6, 7].
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao (US 2023/0236902 A1) in view of Beeler (US 11449963 B1) in view of Ivanov (US 2023/0239301 A1) in view of Mellquist (US 2021/0397465 A1) in view of Riera (US 2023/0080421 A1).
Regarding Claim 7, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the method as recited in claim 1 as referenced above.
Zhao in view of Beeler in view of Ivanov in view of Mellquist fails to teach wherein the workload is able to issue the accelerator call without being aware of a type, or number, of accelerators that are available for the accelerator job.
However, Riera teaches wherein the workload is able to issue the accelerator call without being aware of a type, or number, of accelerators that are available for the accelerator job. “The adoption of emerging accelerators is key to achieving greater scale and performance in heterogeneous computing systems. Accordingly, embodiments described herein provide a flexible hardware-agnostic environment that allows application developers to develop high-performance applications without knowledge of the underlying hardware” [Riera ¶ 7, Fig. 5].
Riera is considered to be analogous to the claimed invention because it is in the same field of accelerator management. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov in view of Mellquist to incorporate the teachings of Riera and include that the workload is able to issue the accelerator call without being aware of a type, or number, of accelerators that are available for the accelerator job. Including that the accelerator call can be issued while the workload has no knowledge of accelerator type or number allows for a flexible computing environment compatible with different accelerator technologies [Riera ¶ 7].
Regarding Claim 17, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the non-transitory storage medium as recited in claim 11 as referenced above.
Zhao in view of Beeler in view of Ivanov in view of Mellquist fails to teach wherein the workload is able to issue the accelerator call without being aware of a type, or number, of accelerators that are available for the accelerator job.
However, Riera teaches wherein the workload is able to issue the accelerator call without being aware of a type, or number, of accelerators that are available for the accelerator job. “The adoption of emerging accelerators is key to achieving greater scale and performance in heterogeneous computing systems. Accordingly, embodiments described herein provide a flexible hardware-agnostic environment that allows application developers to develop high-performance applications without knowledge of the underlying hardware” [Riera ¶ 7, Fig. 5].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov in view of Mellquist to incorporate the teachings of Riera and include that the workload is able to issue the accelerator call without being aware of a type, or number, of accelerators that are available for the accelerator job. Including that the accelerator call can be issued while the workload has no knowledge of accelerator type or number allows for a flexible computing environment compatible with different accelerator technologies [Riera ¶ 7].
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao (US 2023/0236902 A1) in view of Beeler (US 11449963 B1) in view of Ivanov (US 2023/0239301 A1) in view of Mellquist (US 2021/0397465 A1) in view of Sierra (US 2016/0117793 A1).
Regarding claim 8, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the method as recited in claim 1 as referenced above.
Zhao in view of Beeler in view of Ivanov in view of Mellquist fails to teach wherein an order of accelerators to be used for the accelerator job is configurable by a user.
However, Sierra teaches wherein an order of accelerators to be used for the accelerator job is configurable by a user. “Notebook computers have been provided with two internal graphics processing units (GPUs)-a power saving but lower performance internal integrated GPU (iGPU), and a higher performance (but less power efficient) internal discrete GPU ( dGPU)…This allows a notebook computer user to extend notebook computer battery life by allowing the user to select to use the lower power internal integrated GPU for more mundane graphics processing applications, and to enable the higher performance and higher power consuming internal discrete GPU only for applications with demanding graphics processing requirements such as gaming applications” [Sierra ¶ 3, 4].
Sierra is considered to be analogous to the claimed invention because it is in the same field of accelerator task scheduling. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov in view of Mellquist to incorporate the teachings of Sierra and include that an order of accelerators to be used for the accelerator job is configurable by a user. Implementing user accelerator configuration allows for user control and regulation of computing resources [Sierra ¶ 3, 4].
Regarding claim 18, the combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the non-transitory storage medium as recited in claim 11 as referenced above.
Zhao in view of Beeler in view of Ivanov in view of Mellquist fails to teach wherein an order of accelerators to be used for the accelerator job is configurable by a user.
However, Sierra teaches wherein an order of accelerators to be used for the accelerator job is configurable by a user. “Notebook computers have been provided with two internal graphics processing units (GPUs)-a power saving but lower performance internal integrated GPU (iGPU), and a higher performance (but less power efficient) internal discrete GPU (dGPU)…This allows a notebook computer user to extend notebook computer battery life by allowing the user to select to use the lower power internal integrated GPU for more mundane graphics processing applications, and to enable the higher performance and higher power consuming internal discrete GPU only for applications with demanding graphics processing requirements such as gaming applications” [Sierra ¶ 3, 4].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhao in view of Beeler in view of Ivanov in view of Mellquist to incorporate the teachings of Sierra and include that an order of accelerators to be used for the accelerator job is configurable by a user. Implementing user accelerator configuration allows for user control and regulation of computing resources [Sierra ¶ 3, 4].
Response to Arguments
Applicant's arguments filed 12 have been fully considered but they are not persuasive. Applicant argues in substance:
a. As now presented, the claims require that the AMJ run in the same environment as the workload. This environment is a container as a service (CAAS) environment. As a result, both the workload and the AMJ run in the CAAS environment. Applicant respectfully submits that the cited combination of art fails to teach or suggest a similar embodiment.
Zhao discloses a "control plane" that manages GPU virtual machines (VMs) across different cloud service providers. In Zhao, the control plane executes outside of the user's workload VM and simply assigns a GPU VM to handle the user's graphics or compute request. (See, e.g., Zhao 27, 45-47). Zhao's system thus relies on remote orchestration across multiple machines and providers.
In contrast, the claimed embodiments require that the AMJ be co-resident with the workload. That is, the AMJ must "run[] in the same containerized environment as the workload." With the claimed embodiments, the AMJ operates locally within that same environment to discover service bindings, obtain credentials, and spin up local job-specific processes. Nothing in Zhao contemplates a management process that executes within the same container or local runtime as the workload it manages. Zhao's separation between the "control plane" and the workload VM teaches away from such co-residency, as Zhao's purpose is to centralize scheduling for multiple tenants-not to provide per-workload orchestration within a shared environment.
Combinations of the other references are deficient for the same reason. Briefly, Beeler is directed to remote GPU rendering. Ivanov teaches centralized credential management for multi- tenant clouds-not local AMJ operation. Thyagaturu describes a network interface device. Thyagaturu does mention the use of containers, but Thyagaturu's description is different than a CAAS environment. Li describes disaggregated server resources. Riera describes a HALO system. Sierra describes a technique involving the orchestration of graphics. Applicant respectfully submits that no combination of the cited art teaches or suggests the current embodiments.
Accordingly, for at least these reasons, as discussed above, the pending claims should be found to be distinguished from and patentable over the cited art and rejections of record.
i. Examiner respectfully disagrees. As detailed in the rejection above, the AMJ of Zhao does run in the same environment as the workload [Zhao ¶ 43-44]. While the name accelerator management job is not used, the function of the AMJ is fulfilled by processes of the non-GPU VM of Zhao. This non-GPU VM requests the use of a GPU VM for a workload and communicates with this GPU VM in order to accelerate the workload [Zhao ¶ 49]. As a result, both the workload and the AMJ of Zhao run in the same environment, which is an environment where service virtual machines are provided to tenants [Zhao ¶ 4, 6]. Zhao does not teach containers; however, the cited prior art Ivanov does [Ivanov ¶ 47]. Ivanov allows for containers to be used as an alternative to virtual machines. The combination of Zhao in view of Beeler in view of Ivanov in view of Mellquist teaches the limitations of the independent claims, as detailed in the rejection above.
Further, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “run[] in the same containerized environment as the workload”, “the AMJ operates locally within that same environment to discover service bindings”, and “a management process that executes within the same container or local runtime as the workload it manages”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Further, Applicant presents arguments referencing the location of the control plane of Zhao. However, as detailed in the rejection above, the control plane is not mapped to the AMJ, but to the service broker. It is unclear how the location of the service broker is relevant to the limitations: “wherein the AMJ runs in a same environment as the workload, and wherein the environment is a container as a service (CAAS) environment, such that both the workload and the AMJ run in the CAAS environment”. The arguments have been considered, but have not been found to be persuasive.
Applicant’s further arguments with respect to claim(s) 1 and 11 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
b. To illustrate, new dependent claim 21 also appears to be distinguishable over the cited art. Claim 21 describes an embodiment where the accelerator management job determines that the container of the workload is bound to a service instance with one or more accelerators and calls the service broker associated with the accelerator to obtain the information needed to run that service instance. This embodiment also appears to be distinguishable.
i. Examiner respectfully disagrees. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Further, Zhao teaches: wherein the accelerator management job determines that a container of the workload is bound to a service instance with one or more accelerators [Zhao ¶ 47]. and calls the service broker associated with the accelerator to obtain the information needed to run that service instance. [Zhao ¶ 45, 58]. And additionally, Ivanov teaches: wherein the accelerator management job determines that a container of the workload is bound to a service instance with one or more accelerators and calls the service broker associated with the accelerator to obtain the information needed to run that service instance. [Ivanov ¶ 47, 67-68, 70, 73]. The arguments have been considered, but have not been found to be persuasive.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached on (571) 272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.F.R./Examiner, Art Unit 2197 /BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197