Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to Applicant’s Amendment filed 01/05/2026. Claims 1, 3-10, and 12-22 are pending. Claims 1, 10, 19, and 21-22 have been amended; Claims 2 and 11 were previously canceled. Any examiner’s note, objection, or rejection not repeated is withdrawn due to Applicant’s amendment.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/05/2026 has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/19/2022 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
Claims 1, 3, 5, 7-8, 10, 12, 14, 16-17, 19, and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Yanacek et al. (US 11119826 B2) in view of Gerdesmeier et al. (US 20180088993 A1), and further in view of Wennerström et al. (US 20220158926 A1), hereinafter referred to as Yanacek, Gerdesmeier, and Wennerstrom, respectively.
Regarding Claim 1, Yanacek discloses A computer-implemented method (Col. 23 Lines 16-18- the components can be implemented by a single computing device or multiple computing devices) for instantiating agents in task-specific containers (Col. 23 Line 1- The instances and/or the containers in a warming pool 130A; Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note the warming pool 130A is responsible for instantiating the instances (corresponding to Applicant’s agents) in containers.), the method comprising:
determining, via one or more processors in a cloud-based container service, whether a task- specific container has been deployed in a memory of the cloud-based container service (Col. 20 Lines 17-22- in a container […] the worker manager 140 may determine whether any of the instances in the active pool 140A is currently assigned to the user associated with the triggered task and has compute capacity to handle the triggered task; Col. 11, Lines 54-57-For example, the on-demand code execution system 110 or various constituents thereof could implement various Web services components, hosted or “cloud” computing environments; Col. 14, Lines 53-57-the call includes metadata that indicates […] the computing resources (e.g., memory, etc.) to be reserved for executing the source code. Please note that executing the source code with computer resources, including memory, as well as a processor, known in the art to be a computing resource, in a system implementing a cloud computing environment corresponds to Applicant’s via one or more processors in a cloud-based container service and a memory of the cloud-based container service. Please note that determining whether the instance handling the triggered task in a container is currently assigned corresponds to Applicant’s determining whether a container having a processing task performed by an instance of an agent has been deployed.);
receiving, via an Application Programming Interface (API) over a network and for the task- specific container based on a determination that the task-specific container has been deployed, a list of one or more instances of the agents that are designated to support execution, wherein the list identifies specific agent instances that should exist for the task-specific container to properly function (Col. 10, Lines 2-14 - The on-demand code execution system 110 may provide the user computing devices 102 with […] application programing interfaces (API) […] for […] the user-provided source code (e.g., submitting a request to execute the source code on the on-demand code execution system 110), scheduling event-based jobs or timed jobs […] viewing other logging or monitoring information related to their requests and/or source code; Col. 19 Lines 42-43- the worker managers 140 may maintain a list of instances in an active pool 140A.; Col. 19 Lines 59-60- existing container in one of the instances in an active pool 140A. Please note that providing APIs to computing devices to view logging and monitoring information related to requests corresponds to Applicant’s API over a network for the task-specific container, since it is known in the art that an API can operate over a network, and the monitoring information related to a request as part of the execution of the source code in this system would include a list of instances of the agents. Please note that the list of instances in an active pool 140A that are used by the worker manager 140 corresponds to Applicant’s receiving a list of one or more instances of agents for the container that are designated to support execution. Also note that Applicant’s determination that the container has been deployed corresponds to the active pool, as it consists of existing containers. Furthermore, since each instance of an agent is associated with a task-specific container, this corresponds to identifying specific agent instances that should exist for the task-specific container to properly function, as it requires a task-specific container as its environment in which to instantiate and complete the operation.);
receiving, via the API based on the determination and from an agent status server connected to the cloud-based container service via the network, current operational statuses of the one or more instances of the agents (Col. 22 Lines 26-29- monitoring service for managing monitoring information […] such as statuses of containers and instances. Please note that the statuses of instances being monitored by the monitoring service corresponds to Applicant’s receiving current operational statuses of one or more instances of the agents from an agent status server.);
and attempting to instantiate, via the one or more processors and in the cloud-based container service based on the agent object and the configuration information, the instance of the agent in the memory of the cloud-based container service (Col. 17 Lines 48-49- the manager 130 may operate to generate and configure that instance. Please note that generating the instance corresponds to Applicant’s attempting to instantiate the instance of the agent, and configuring the instance corresponds to doing so based on configuration information.)
Yanacek does not explicitly disclose receiving, via the API from an agent object repository and based on a determination that the instance of the agent expected to be instantiated is inactive, an agent object corresponding to the instance of the agent receiving, via the API from an agent configuration repository and based on the determination that the instance of the agent expected to be instantiated is inactive, configuration information for the instance of the agent; including attempting to connect the instance of the agent to the agent status server to provide agent status information to the agent status server.
However, Gerdesmeier discloses receiving, via the API from an agent object repository and based on a determination that the instance of the agent expected to be instantiated is inactive, an agent object corresponding to the instance of the agent ([0035] As instances are assigned to a customer, the instances may be removed from the available instances 110 in the instance pool 108. Please note that the instance pool 108 corresponds to Applicant’s agent object repository, the instance corresponds to the agent object, and removing the instance from the available instances 110 in the instance pool 108 corresponds to Applicant’s receiving an agent object corresponding to the agent from an agent object repository after determining the instance of the agent is inactive, as it provides an instance to the recipient after determining it is available, i.e., inactive, as it determines the instance is no longer being used by the customer and thus inactive.);
receiving, via the API from an agent configuration repository and based on the determination that the instance of the agent expected to be instantiated is inactive, configuration information for the instance of the agent ([0023] a task definition 102 is received at a container management service 104; [0036] The container management service 104 will select the instance 106 from the available instances 110 of the instance pool 108 based on the task definition 102, as described herein. For example, the task definition 102 may specify a set of parameters that define resources that may be used to instantiate a container on the instance and perform the task specified in the task definition. Please note that the instance pool 108 corresponds to Applicant’s agent configuration repository, the available instances 110 correspond to Applicant’s determination that the agent is inactive as it consists of instances that are inactive, i.e., not being utilized by other clients, and the task definition 102 corresponds to Applicant’s configuration information for the instance of the agent. This is then received by the container management service 104, corresponding to Applicant’s receiving step.);
including attempting to connect the instance of the agent to the agent status server to provide agent status information to the agent status server ([0059] instance 502 has a task 504 […] the task 504 may communicate with other services via the network interface 508. Please note that the instance’s task communicating with other services via the network interface 508 corresponds to Applicant’s attempting to connect the instance of the agent to the agent status server, as the network interface can facilitate connection to a server. This would allow the transmission of data such as agent status information, in this case, the statuses of instances as described by Yanacek.).
Yanacek and Gerdesmeier are both considered to be analogous to the claimed invention because they are in the same field of instance and container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek to incorporate the teachings of Gerdesmeier to modify the instantiation and configuration system of Yanacek to keep track of inactive instances and provide them as needed to complete tasks and provide a status of the instance of the agent to the agent status server, allowing for efficient allocation of instances based on usage and allowing for the management system to keep track of instance states for improved reliability, as described in Gerdesmeier.
Yanacek-Gerdesmeier does not explicitly disclose wherein the task-specific container is dedicated to executing a particular task and is configured with task- specific resources required for the particular task;
the predetermined list of one or more instances of the agents;
the particular task in the task-specific container;
comparing the received current operational statuses and the predetermined list, to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container;
However, Wennerstrom discloses wherein the task-specific container is dedicated to executing a particular task and is configured with task- specific resources required for the particular task ([0069] each container may omit an individual operating system and provide only an application suite and application-specific libraries. Please note that the container providing application-specific libraries corresponds to Applicant’s task-specific container being dedicated to executing a particular task and being configured with task- specific resources required for the particular task. );
the predetermined list of one or more instances of the agents ([0387] The interface_list type takes either the agents helper or a raw value as an input. The type is used for populating a template input with a list of Agents. Please note that the populated list of Agents corresponds to Applicant’s predetermined list of one or more instances of the agents.);
the particular task in the task-specific container ([0069] each container may omit an individual operating system and provide only an application suite and application-specific libraries. Please note that the application that is used in the container that has application-specific libraries corresponds to Applicant’s particular task in the task-specific container. );
comparing the received current operational statuses and the predetermined list, to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container ([0491] The plugin will ensure that there are no already running Ephemeral Agent for the Pod.sup.K before deploying a new one.; [0493] retrieve the targeted Pod.sup.K 's Ephemeral containers.; [0494] The plugin will then look for an Ephemeral Agent in the list of Ephemeral container that it has retrieved.; [0496] On the other hand, if there is no match, the plugin will not make any changes to the Pod.sup.K, resulting in a no-op. Please note that checking whether the Ephemeral Agent is running, looking for an Ephemeral Agent in the list of Ephemeral containers that it has retrieved, and determining if there is no match, corresponds to Applicant’s comparing the received current operational statuses and the predetermined list to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container, as it may not be running, i.e., inactive, and may not be found as a match, i.e., is missing.);
Yanacek-Gerdesmeier and Wennerstrom are both considered to be analogous to the claimed invention because they are in the same field of instance and container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek-Gerdesmeier to incorporate the teachings of Wennerstrom to modify the previously described system of Yanacek-Gerdesmeier to have the task-specific containers be dedicated to executing a particular task, be configured with task-specific resources required for the particular task, and compare the received current operational statuses and the predetermined list to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container, allowing for improved resource usage, as described in Wennerstrom.
Regarding Claim 3, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 1 discloses from Gerdesmeier providing, to the agent status server, a status of the instance of the agent ([0060] provides status updates on the […] instance 502 to the container management service 524. Please note the container management service 524 corresponds to Applicant’s agent status server, and providing status updates on the instance 502 corresponds to providing a status of the instance of the agent.).
Regarding Claim 5, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 1 discloses from Yanacek receiving, based on a determination that the attempt to instantiate the instance of the agent failed and from the agent object repository, a replacement agent object corresponding to the instance of the agent (Col. 29 Lines 22-24-In the case of such a rejection, the frontend 120 may retry the request with an alternative worker manager 140. Please note that retrying a request with an alternative worker manager 140 in case of a rejection corresponds to Applicant’s receiving a replacement agent object from the agent object repository based on a determination that the attempt to instantiate failed, as each worker manager 140 contains a list of instances corresponding to instances of agents and fulfills a request with the replacement worker manager.); receiving, from the agent configuration repository and based on the determination that the attempt to instantiate the instance of the agent failed, replacement configuration information for the instance of the agent (Col. 19 Lines 43-45- The list of instances may further specify the configuration (e.g., OS, runtime, container, etc.) of the instances. Please note that the list of instances specifying the configuration of the instances corresponds to Applicant’s replacement configuration information for the instance of the agent.); and attempting to instantiate, based on the replacement agent object and the replacement configuration information, a replacement instance of the agent (Col. 17 Lines 48-49- the manager 130 may operate to generate and configure that instance. Please note that generating the instance corresponds to Applicant’s attempting to instantiate the replacement instance of the agent, and configuring the instance corresponds to doing so based on configuration information.).
Yanacek-Gerdesmeier-Wennerstrom further discloses from Gerdesmeier determining, based on the attempting to instantiate the instance of the agent, whether the instantiation of the instance of the agent was successful ([0071] if the container management service cannot obtain and provision any instances. Please note that this determination that the container management service cannot obtain and provision any instances corresponds to Applicant’s determination whether the instantiation of the instance of the replacement agent was successful; in this case, it was not.);
Regarding Claim 7, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 1 discloses from Gerdesmeier attempting to connect, based on a successful attempt to instantiate the instance of the agent, the instance of the agent to a processing task performed by the task- specific container ([0061] process 600 for instantiating […] a container instance […] The container management service may next create 606 the task framework […] a “task framework” is the execution environment for the task […] The task framework […] connects with the instance agent; Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note that connecting the instance agent to task framework corresponds to Applicant’s connecting the instance of the agent to the processing task performed by the container, as it allows the instance agent to communicate with the task. Furthermore, please note that the container management service proceeding to create the task framework corresponds to Applicant’s successful attempt to instantiate the instance of the agent, as connection to the task framework is an ordered series of steps that occurs after the instantiation).
Regarding Claim 8, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 7 discloses from Yanacek receiving, based on a determination that the attempt to connect the instance of the agent to the processing task failed and from the agent object repository, a replacement agent object corresponding to the instance of the agent (Col. 29 Lines 22-24-In the case of such a rejection, the frontend 120 may retry the request with an alternative worker manager 140. Please note that retrying a request with an alternative worker manager 140 in case of a rejection corresponds to Applicant’s receiving a replacement agent object from the agent object repository based on a determination that the attempt to instantiate failed, as each worker manager 140 contains a list of instances corresponding to instances of agents and fulfills a request with the replacement worker manager.); receiving, from the agent configuration repository and based on the determination that the attempt to connect the instance of the agent to the processing task failed, replacement configuration information for the instance of the agent (Col. 19 Lines 43-45- The list of instances may further specify the configuration (e.g., OS, runtime, container, etc.) of the instances. Please note that the list of instances specifying the configuration of the instances corresponds to Applicant’s replacement configuration information for the instance of the agent.); instantiating, based on the replacement agent object and the replacement configuration information, a replacement instance of the agent (Col. 17 Lines 48-49- the manager 130 may operate to generate and configure that instance. Please note that generating the instance corresponds to Applicant’s attempting to instantiate the replacement instance of the agent, and configuring the instance corresponds to doing so based on configuration information.);
Yanacek-Gerdesmeier-Wennerstrom further discloses from Gerdesmeier determining, based on the attempting to connect the instance of the agent, whether the attempt to connect the instance of the agent to the processing task was successful ([0071] if the container management service cannot obtain and provision any instances. Please note that this determination that the container management service cannot obtain and provision any instances corresponds to Applicant’s determination whether the connection of the instance of the agent to the processing task was successful; in this case, it was not.); and attempting to connect, based on the instantiation of the replacement instance of the agent, the replacement instance of the agent in the task- specific container to the processing task ([0061] process 600 for instantiating […] a container instance […] The container management service may next create 606 the task framework […] a “task framework” is the execution environment for the task […] The task framework […] connects with the instance agent; Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note that connecting the instance agent to task framework corresponds to Applicant’s connecting the replacement instance of the agent to the processing task performed by the container, as it allows the instance agent to communicate with the task. Furthermore, please note that the container management service proceeding to create the task framework corresponds to Applicant’s doing so based on the instantiation of the agent, as connection to the task framework is an ordered series of steps that occurs after the instantiation).
Regarding Claim 10, Yanacek discloses An apparatus comprising: one or more processors (Col. 33, Lines 63-66- All of the methods and processes described above may be embodied in, and fully automated via, software code modules executed by one or more computers or processors); and memory storing instructions that, when executed by the one or more processors (Col. 33, Line 67; Col. 34, Line 1 - The code modules may be stored in any type of non-transitory computer-readable medium), cause the apparatus to:
determine, in a cloud-based container service, whether a task-specific container, has been deployed in a memory of the cloud-based container service (Col. 20 Lines 17-22- in a container […] the worker manager 140 may determine whether any of the instances in the active pool 140A is currently assigned to the user associated with the triggered task and has compute capacity to handle the triggered task; Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Col. 11, Lines 54-57-For example, the on-demand code execution system 110 or various constituents thereof could implement various Web services components, hosted or “cloud” computing environments; Col. 14, Lines 53-57-the call includes metadata that indicates […] the computing resources (e.g., memory, etc.) to be reserved for executing the source code. Please note that executing the source code with computer resources, including memory, as well as a processor, known in the art to be a computing resource, in a system implementing a cloud computing environment corresponds to Applicant’s via one or more processors in a cloud-based container service and a memory of the cloud-based container service. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note that determining whether the instance handling the triggered task in a container is currently assigned corresponds to Applicant’s determining whether a container having a processing task performed by an instance of an agent has been deployed. As the instance handles the task within the container, this corresponds to Applicant’s container being controlled by the agent.);
receive, via an Application Programming Interface (API) over a network and for the task- specific container based on a determination that the task-specific container has been deployed, a list of one or more instances of the agents that are designated to support execution, wherein the list identifies specific agent instances that should exist for the task-specific container to properly function (Col. 10, Lines 2-14 - The on-demand code execution system 110 may provide the user computing devices 102 with […] application programing interfaces (API) […] for […] the user-provided source code (e.g., submitting a request to execute the source code on the on-demand code execution system 110), scheduling event-based jobs or timed jobs […] viewing other logging or monitoring information related to their requests and/or source code; Col. 19 Lines 42-43- the worker managers 140 may maintain a list of instances in an active pool 140A.; Col. 19 Lines 59-60- existing container in one of the instances in an active pool 140A. Please note that providing APIs to computing devices to view logging and monitoring information related to requests corresponds to Applicant’s API over a network for the task-specific container, since it is known in the art that an API can operate over a network, and the monitoring information related to a request as part of the execution of the source code in this system would include a list of instances of the agents. Please note that the list of instances in an active pool 140A that are used by the worker manager 140 corresponds to Applicant’s receiving a list of one or more instances of agents for the container that are designated to support execution. Also note that Applicant’s determination that the container has been deployed corresponds to the active pool, as it consists of existing containers. Furthermore, since each instance of an agent is associated with a task-specific container, this corresponds to identifying specific agent instances that should exist for the task-specific container to properly function, as it requires a task-specific container as its environment in which to instantiate and complete the operation.);
receive, via the API based on the determination and from an agent status server connected to the cloud-based container service via the network, current operational statuses of the one or more instances of the agents (Col. 22 Lines 26-29- monitoring service for managing monitoring information […] such as statuses of containers and instances. Please note that the statuses of instances being monitored by the monitoring service corresponds to Applicant’s receiving current operational statuses of one or more instances of the agents from an agent status server.);
and attempt to instantiate, in the cloud-based container service based on the agent object and the configuration information, the instance of the agent in the memory of the cloud-based container service (Col. 17 Lines 48-49- the manager 130 may operate to generate and configure that instance. Please note that generating the instance corresponds to Applicant’s attempting to instantiate the instance of the agent, and configuring the instance corresponds to doing so based on configuration information.),
Yanacek does not explicitly disclose receive, via the API from an agent object repository and based on a determination that the instance of the agent expected to be instantiated is inactive, an agent object corresponding to the instance of the agent; receive, via the API from an agent configuration repository and based on the determination that the agent expected to be instantiated is inactive, configuration information for the instance of the agent; including attempt to connect the instance of the agent to the agent status server to provide agent status information to the agent status server.
However, Gerdesmeier discloses receive, via the API from an agent object repository and based on a determination that the instance of the agent expected to be instantiated is inactive, an agent object corresponding to the instance of the agent ([0035] As instances are assigned to a customer, the instances may be removed from the available instances 110 in the instance pool 108. Please note that the instance pool 108 corresponds to Applicant’s agent object repository, the instance corresponds to the agent object, and removing the instance from the available instances 110 in the instance pool 108 corresponds to Applicant’s receiving an agent object corresponding to the agent from an agent object repository after determining the instance of the agent is inactive, as it provides an instance to the recipient after determining it is available, i.e., inactive, as it determines the instance is no longer being used by the customer and thus inactive.);
receive, via the API from an agent configuration repository and based on the determination that the agent expected to be instantiated is inactive, configuration information for the instance of the agent ([0023] a task definition 102 is received at a container management service 104; [0036] The container management service 104 will select the instance 106 from the available instances 110 of the instance pool 108 based on the task definition 102, as described herein. For example, the task definition 102 may specify a set of parameters that define resources that may be used to instantiate a container on the instance and perform the task specified in the task definition. Please note that the instance pool 108 corresponds to Applicant’s agent configuration repository, the available instances 110 correspond to Applicant’s determination that the agent is inactive as it consists of instances that are inactive, i.e., not being utilized by other clients, and the task definition 102 corresponds to Applicant’s configuration information for the instance of the agent. This is then received by the container management service 104, corresponding to Applicant’s receive step.);
including attempt to connect the instance of the agent to the agent status server to provide agent status information to the agent status server ([0059] instance 502 has a task 504 […] the task 504 may communicate with other services via the network interface 508. Please note that the instance’s task communicating with other services via the network interface 508 corresponds to Applicant’s attempting to connect the instance of the agent to the agent status server, as the network interface can facilitate connection to a server. This would allow the transmission of data such as agent status information, in this case, the statuses of instances as described by Yanacek.).
Yanacek and Gerdesmeier are both considered to be analogous to the claimed invention because they are in the same field of instance and container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek to incorporate the teachings of Gerdesmeier to modify the instantiation and configuration system of Yanacek to keep track of inactive instances and provide them as needed to complete tasks and provide a status of the instance of the agent to the agent status server, allowing for efficient allocation of instances based on usage and allowing for the management system to keep track of instance states for improved reliability, as described in Gerdesmeier.
Yanacek-Gerdesmeier does not explicitly disclose wherein the task-specific container is dedicated to executing a particular task and is configured with task- specific resources required for the particular task;
the predetermined list of one or more instances of the agents;
the particular task in the task-specific container;
comparing the received current operational statuses and the predetermined list, to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container;
However, Wennerstrom discloses wherein the task-specific container is dedicated to executing a particular task and is configured with task- specific resources required for the particular task ([0069] each container may omit an individual operating system and provide only an application suite and application-specific libraries. Please note that the container providing application-specific libraries corresponds to Applicant’s task-specific container being dedicated to executing a particular task and being configured with task- specific resources required for the particular task. );
the predetermined list of one or more instances of the agents ([0387] The interface_list type takes either the agents helper or a raw value as an input. The type is used for populating a template input with a list of Agents. Please note that the populated list of Agents corresponds to Applicant’s predetermined list of one or more instances of the agents.);
the particular task in the task-specific container ([0069] each container may omit an individual operating system and provide only an application suite and application-specific libraries. Please note that the application that is used in the container that has application-specific libraries corresponds to Applicant’s particular task in the task-specific container. );
comparing the received current operational statuses and the predetermined list, to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container ([0491] The plugin will ensure that there are no already running Ephemeral Agent for the Pod.sup.K before deploying a new one.; [0493] retrieve the targeted Pod.sup.K 's Ephemeral containers.; [0494] The plugin will then look for an Ephemeral Agent in the list of Ephemeral container that it has retrieved.; [0496] On the other hand, if there is no match, the plugin will not make any changes to the Pod.sup.K, resulting in a no-op. Please note that checking whether the Ephemeral Agent is running, looking for an Ephemeral Agent in the list of Ephemeral containers that it has retrieved, and determining if there is no match, corresponds to Applicant’s comparing the received current operational statuses and the predetermined list to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container, as it may not be running, i.e., inactive, and may not be found as a match, i.e., is missing.);
Yanacek-Gerdesmeier and Wennerstrom are both considered to be analogous to the claimed invention because they are in the same field of instance and container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek-Gerdesmeier to incorporate the teachings of Wennerstrom to modify the previously described system of Yanacek-Gerdesmeier to have the task-specific containers be dedicated to executing a particular task, be configured with task-specific resources required for the particular task, and compare the received current operational statuses and the predetermined list to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container, allowing for improved resource usage, as described in Wennerstrom.
Regarding Claim 12, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 10 discloses from Gerdesmeier provide, to the agent status server, a status of the instance of the agent ([0060] provides status updates on the […] instance 502 to the container management service 524. Please note the container management service 524 corresponds to Applicant’s agent status server, and providing status updates on the instance 502 corresponds to provide a status of the instance of the agent.).
Regarding Claim 14, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 10 discloses from Yanacek receive, based on a determination that the attempt to instantiate the instance of the agent failed and from the agent object repository, a replacement agent object corresponding to the instance of the agent (Col. 29 Lines 22-24-In the case of such a rejection, the frontend 120 may retry the request with an alternative worker manager 140. Please note that retrying a request with an alternative worker manager 140 in case of a rejection corresponds to Applicant’s receiving a replacement agent object from the agent object repository based on a determination that the attempt to instantiate failed, as each worker manager 140 contains a list of instances corresponding to instances of agents and fulfills a request with the replacement worker manager.); receive, from the agent configuration repository and based on the determination that the attempt to instantiate the instance of the agent failed, replacement configuration information for the instance of the agent (Col. 19 Lines 43-45- The list of instances may further specify the configuration (e.g., OS, runtime, container, etc.) of the instances. Please note that the list of instances specifying the configuration of the instances corresponds to Applicant’s replacement configuration information for the instance of the agent.); and attempt to instantiate, based on the replacement agent object and the replacement configuration information, a replacement instance of the agent (Col. 17 Lines 48-49- the manager 130 may operate to generate and configure that instance. Please note that generating the instance corresponds to Applicant’s attempting to instantiate the replacement instance of the agent, and configuring the instance corresponds to doing so based on configuration information.).
Yanacek-Gerdesmeier-Wennerstrom further discloses from Gerdesmeier determine, based on the attempt to instantiate the instance of the agent, whether the instantiation of the instance of the agent was successful ([0071] if the container management service cannot obtain and provision any instances. Please note that this determination that the container management service cannot obtain and provision any instances corresponds to Applicant’s determination whether the instantiation of the instance of the agent was successful; in this case, it was not.);
Regarding Claim 16, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 10 discloses from Gerdesmeier attempt to connect, based on a successful attempt to instantiate the instance of the agent, the instance of the agent to a processing task in the task- specific container ([0061] process 600 for instantiating […] a container instance […] The container management service may next create 606 the task framework […] a “task framework” is the execution environment for the task […] The task framework […] connects with the instance agent; Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note that connecting the instance agent to task framework corresponds to Applicant’s connecting the instance of the agent to the processing task performed by the container, as it allows the instance agent to communicate with the task. Furthermore, please note that the container management service proceeding to create the task framework corresponds to Applicant’s successful attempt to instantiate the instance of the agent, as connection to the task framework is an ordered series of steps that occurs after the instantiation).
Regarding Claim 17, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 16 discloses from Yanacek receive, based on a determination that the attempt to connect the instance of the agent to the processing task failed and from the agent object repository, a replacement agent object corresponding to the instance of the agent (Col. 29 Lines 22-24-In the case of such a rejection, the frontend 120 may retry the request with an alternative worker manager 140. Please note that retrying a request with an alternative worker manager 140 in case of a rejection corresponds to Applicant’s receiving a replacement agent object from the agent object repository based on a determination that the attempt to connect the instance of the agent to the processing task failed, as each worker manager 140 contains a list of instances corresponding to instances of agents and fulfills a request with the replacement worker manager.); receive, from the agent configuration repository and based on the determination that the attempt to connect the instance of the agent to the processing task failed, replacement configuration information for the instance of the agent (Col. 19 Lines 43-45- The list of instances may further specify the configuration (e.g., OS, runtime, container, etc.) of the instances. Please note that the list of instances specifying the configuration of the instances corresponds to Applicant’s replacement configuration information for the instance of the agent.); instantiate, based on the replacement agent object and the replacement configuration information, a replacement instance of the agent (Col. 17 Lines 48-49- the manager 130 may operate to generate and configure that instance. Please note that generating the instance corresponds to Applicant’s attempting to instantiate the replacement instance of the agent, and configuring the instance corresponds to doing so based on configuration information.); and attempt to connect, based on the instantiation of the replacement instance of the agent, the replacement instance of the agent to the processing task in the task-specific container ([0061] process 600 for instantiating […] a container instance […] The container management service may next create 606 the task framework […] a “task framework” is the execution environment for the task […] The task framework […] connects with the instance agent; Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note that connecting the instance agent to task framework corresponds to Applicant’s connecting the instance of the agent to the processing task performed by the container, as it allows the instance agent to communicate with the task. Furthermore, please note that the container management service proceeding to create the task framework corresponds to Applicant’s attempt to instantiate the replacement instance of the agent, as connection to the task framework is an ordered series of steps that occurs after the instantiation).
Yanacek-Gerdesmeier-Wennerstrom further discloses from Gerdesmeier determine, based on the attempt to connect the instance of the agent, whether the attempt to connect the instance of the agent to the processing task was successful ([0071] if the container management service cannot obtain and provision any instances. Please note that this determination that the container management service cannot obtain and provision any instances corresponds to Applicant’s determination whether the connection of the instance of the agent to the processing task was successful; in this case, it was not.);
Regarding Claim 19, Yanacek discloses One or more non-transitory media storing instructions (Col. 33, Line 67; Col. 34, Line 1 - The code modules may be stored in any type of non-transitory computer-readable medium) that, when executed by one or more processors in a cloud-based container service (Col. 11, Lines 54-57-For example, the on-demand code execution system 110 or various constituents thereof could implement various Web services components, hosted or “cloud” computing environment; Col. 33, Lines 63-66- All of the methods and processes described above may be embodied in, and fully automated via, software code modules executed by one or more computers or processors. Please note that the processors executing the software code modules that are implemented in a cloud computing environment corresponds to Applicant’s processors in a cloud-based container service.), cause the one or more processors to perform steps comprising:
determining, via the one or more processors in the cloud-based container service, whether a task-specific container has been deployed in a memory of the cloud-based container service (Col. 20 Lines 17-22- in a container […] the worker manager 140 may determine whether any of the instances in the active pool 140A is currently assigned to the user associated with the triggered task and has compute capacity to handle the triggered task; Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Col. 11, Lines 54-57-For example, the on-demand code execution system 110 or various constituents thereof could implement various Web services components, hosted or “cloud” computing environments; Col. 14, Lines 53-57-the call includes metadata that indicates […] the computing resources (e.g., memory, etc.) to be reserved for executing the source code. Please note that executing the source code with computer resources, including memory, as well as a processor, known in the art to be a computing resource, in a system implementing a cloud computing environment corresponds to Applicant’s via one or more processors in a cloud-based container service and a memory of the cloud-based container service. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note that determining whether the instance handling the triggered task in a container is currently assigned corresponds to Applicant’s determining whether a container having a processing task performed by an instance of an agent has been deployed.);
receiving, via an Application Programming Interface (API) over a network and for the task- specific container based on a determination that the task-specific container has been deployed, a list of one or more instances of the agents that are designated to support execution, wherein the list identifies specific agent instances that should exist for the task-specific container to properly function (Col. 10, Lines 2-14 - The on-demand code execution system 110 may provide the user computing devices 102 with […] application programing interfaces (API) […] for […] the user-provided source code (e.g., submitting a request to execute the source code on the on-demand code execution system 110), scheduling event-based jobs or timed jobs […] viewing other logging or monitoring information related to their requests and/or source code; Col. 19 Lines 42-43- the worker managers 140 may maintain a list of instances in an active pool 140A.; Col. 19 Lines 59-60- existing container in one of the instances in an active pool 140A. Please note that providing APIs to computing devices to view logging and monitoring information related to requests corresponds to Applicant’s API over a network for the task-specific container, since it is known in the art that an API can operate over a network, and the monitoring information related to a request as part of the execution of the source code in this system would include a list of instances of the agents. Please note that the list of instances in an active pool 140A that are used by the worker manager 140 corresponds to Applicant’s receiving a list of one or more instances of agents for the container that are designated to support execution. Also note that Applicant’s determination that the container has been deployed corresponds to the active pool, as it consists of existing containers. Furthermore, since each instance of an agent is associated with a task-specific container, this corresponds to identifying specific agent instances that should exist for the task-specific container to properly function, as it requires a task-specific container as its environment in which to instantiate and complete the operation.);
receiving, via the API based on the determination and from an agent status server connected to the cloud-based container service via the network, current operational statuses of the one or more instances of the agents (Col. 22 Lines 26-29- monitoring service for managing monitoring information […] such as statuses of containers and instances. Please note that the statuses of instances being monitored by the monitoring service corresponds to Applicant’s receiving current operational statuses of one or more instances of the agents.);
attempting to instantiate, via the one or more processors and in the cloud-based container service, based on the agent object and the configuration information, the instance of the agent in the memory of the cloud-based container service (Col. 17 Lines 48-49- the manager 130 may operate to generate and configure that instance. Please note that generating the instance corresponds to Applicant’s attempting to instantiate the instance of the agent, and configuring the instance corresponds to doing so based on configuration information.);
Yanacek does not explicitly disclose receiving, via the API from an agent object repository and based on a determination that the instance of the agent is inactive, an agent object corresponding to the instance of the agent; receiving, from an agent configuration repository and based on the determination that the instance of the agent is inactive, configuration information for the instance of the agent; including attempting to connect the instance of the agent to the agent status server to provide agent status information to the agent status server; and connecting, based on the instantiation of the agent, the instance of the agent to a processing task performed in the task-specific container
However, Gerdesmeier discloses receiving, via the API from an agent object repository and based on a determination that the instance of the agent is inactive, an agent object corresponding to the instance of the agent ([0035] As instances are assigned to a customer, the instances may be removed from the available instances 110 in the instance pool 108. Please note that the instance pool 108 corresponds to Applicant’s agent object repository, the instance corresponds to the agent object, and removing the instance from the available instances 110 in the instance pool 108 corresponds to Applicant’s receiving an agent object corresponding to the agent from an agent object repository after determining the instance of the agent is inactive, as it provides an instance to the recipient after determining it is available, i.e., inactive, as it determines the instance is no longer being used by the customer and thus inactive.);
and connecting, based on the instantiation of the agent, the instance of the agent to a processing task performed in the task-specific container ([0061] process 600 for instantiating […] a container instance […] The container management service may next create 606 the task framework […] a “task framework” is the execution environment for the task […] The task framework […] connects with the instance agent. Please note that connecting the instance agent to task framework corresponds to Applicant’s connecting the instance of the agent to the processing task performed by the container, as it allows the instance agent to communicate with the task. Furthermore, please note that the container management service proceeding to create the task framework corresponds to Applicant’s doing so based on the instantiation of the agent, as connection to the task framework is an ordered series of steps that occurs after the instantiation); receiving, from an agent configuration repository and based on the determination that the instance of the agent is inactive, configuration information for the instance of the agent ([0023] a task definition 102 is received at a container management service 104; [0036] The container management service 104 will select the instance 106 from the available instances 110 of the instance pool 108 based on the task definition 102, as described herein. For example, the task definition 102 may specify a set of parameters that define resources that may be used to instantiate a container on the instance and perform the task specified in the task definition. Please note that the instance pool 108 corresponds to Applicant’s agent configuration repository, the available instances 110 correspond to Applicant’s determination that the instance of the agent is inactive as it consists of instances that are inactive, i.e., not being utilized by other clients, and the task definition 102 corresponds to Applicant’s configuration information for the instance of the agent. This is then received by the container management service 104, corresponding to Applicant’s receiving step.);
including attempting to connect the instance of the agent to the agent status server to provide agent status information to the agent status server ([0059] instance 502 has a task 504 […] the task 504 may communicate with other services via the network interface 508. Please note that the instance’s task communicating with other services via the network interface 508 corresponds to Applicant’s attempting to connect the instance of the agent to the agent status server, as the network interface can facilitate connection to a server. This would allow the transmission of data such as agent status information, in this case, the statuses of instances as described by Yanacek.).
Yanacek and Gerdesmeier are both considered to be analogous to the claimed invention because they are in the same field of instance and container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek to incorporate the teachings of Gerdesmeier to modify the instantiation and configuration system of Yanacek to keep track of inactive instances and provide them as needed to complete tasks and provide a status of the instance of the agent to the agent status server, allowing for efficient allocation of instances based on usage and allowing for the management system to keep track of instance states for improved reliability, as described in Gerdesmeier.
Yanacek-Gerdesmeier does not explicitly disclose wherein the task-specific container is dedicated to executing a particular task and is configured with task- specific resources required for the particular task;
the predetermined list of one or more instances of the agents;
the particular task in the task-specific container;
comparing the received current operational statuses and the predetermined list, to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container;
However, Wennerstrom discloses wherein the task-specific container is dedicated to executing a particular task and is configured with task- specific resources required for the particular task ([0069] each container may omit an individual operating system and provide only an application suite and application-specific libraries. Please note that the container providing application-specific libraries corresponds to Applicant’s task-specific container being dedicated to executing a particular task and being configured with task- specific resources required for the particular task. );
the predetermined list of one or more instances of the agents ([0387] The interface_list type takes either the agents helper or a raw value as an input. The type is used for populating a template input with a list of Agents. Please note that the populated list of Agents corresponds to Applicant’s predetermined list of one or more instances of the agents.);
the particular task in the task-specific container ([0069] each container may omit an individual operating system and provide only an application suite and application-specific libraries. Please note that the application that is used in the container that has application-specific libraries corresponds to Applicant’s particular task in the task-specific container. );
comparing the received current operational statuses and the predetermined list, to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container ([0491] The plugin will ensure that there are no already running Ephemeral Agent for the Pod.sup.K before deploying a new one.; [0493] retrieve the targeted Pod.sup.K 's Ephemeral containers.; [0494] The plugin will then look for an Ephemeral Agent in the list of Ephemeral container that it has retrieved.; [0496] On the other hand, if there is no match, the plugin will not make any changes to the Pod.sup.K, resulting in a no-op. Please note that checking whether the Ephemeral Agent is running, looking for an Ephemeral Agent in the list of Ephemeral containers that it has retrieved, and determining if there is no match, corresponds to Applicant’s comparing the received current operational statuses and the predetermined list to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container, as it may not be running, i.e., inactive, and may not be found as a match, i.e., is missing.);
Yanacek-Gerdesmeier and Wennerstrom are both considered to be analogous to the claimed invention because they are in the same field of instance and container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek-Gerdesmeier to incorporate the teachings of Wennerstrom to modify the previously described system of Yanacek-Gerdesmeier to have the task-specific containers be dedicated to executing a particular task, be configured with task-specific resources required for the particular task, and compare the received current operational statuses and the predetermined list to determine whether any agent instance from the predetermined list is inactive and missing from the task-specific container, allowing for improved resource usage, as described in Wennerstrom.
Regarding Claim 21, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 1, Wennerstrom further discloses the predetermined list ([0387] The interface_list type takes either the agents helper or a raw value as an input. The type is used for populating a template input with a list of Agents. Please note that the populated list of Agents corresponds to Applicant’s predetermined list.);
Gerdesmeier further discloses determining, based on the predetermined list of the one or more instances of the agents expected to be instantiated and the current operational statuses of the one or more instances of the agents expected to be instantiated, whether a second instance of a second agent of the one or more instances of the agents expected to be instantiated is inactive ([0035] As instances are released by a customer when, for example, the instance is terminated, the instances may be returned to the available instances 110 in the instance pool 108. Please note that returning an instance to the instance pool 108 when the instance is released by a customer corresponds to Applicant’s determining whether a second instance of a second agent is inactive, as it determines the instance is no longer being used by the customer and thus inactive. Furthermore, since a list inherently may have multiple items included, this corresponds to Applicant’s second instance of a second agent, distinct from another instance of an agent.);
receiving, via the API from the agent configuration repository and based on the determination that the second instance of the second agent expected to be instantiated is inactive, second configuration information for the second instance of the second agent ([0023] a task definition 102 is received at a container management service 104; [0036] The container management service 104 will select the instance 106 from the available instances 110 of the instance pool 108 based on the task definition 102, as described herein. For example, the task definition 102 may specify a set of parameters that define resources that may be used to instantiate a container on the instance and perform the task specified in the task definition. Please note that the instance pool 108 corresponds to Applicant’s agent configuration repository, the available instances 110 correspond to Applicant’s determination that the second agent is inactive as it consists of instances that are inactive, i.e., not being utilized by other clients, and the task definition 102 corresponds to Applicant’s second configuration information for the instance of the agent. This is then received by the container management service 104, corresponding to Applicant’s receiving step. It is known in the art that a repository may have multiple items; therefore, it would be obvious that an agent object repository would have a second agent object distinct from another.);
including attempting to connect the second instance of the second agent to the agent status server to provide second agent status information to the agent status server ([0059] instance 502 has a task 504 […] the task 504 may communicate with other services via the network interface 508. Please note that the instance’s task communicating with other services via the network interface 508 corresponds to Applicant’s attempting to connect the second instance of the agent to the agent status server, as the network interface can facilitate connection to a server. This would allow the transmission of data such as agent status information, in this case, the statuses of instances as described by Yanacek.).
Yanacek further discloses receiving, via the API from the agent object repository and based on a determination that the second instance of the second agent expected to be instantiated is inactive, a second agent object corresponding to the second instance of the second agent ([0035] As instances are assigned to a customer, the instances may be removed from the available instances 110 in the instance pool 108. Please note that the instance pool 108 corresponds to Applicant’s agent object repository, the instance corresponds to the second agent object, and removing the instance from the available instances 110 in the instance pool 108 corresponds to Applicant’s receiving a second agent object corresponding to the second instance of the second agent from an agent object repository after determining the instance of the agent is inactive, as it provides an instance to the recipient after determining it is available, i.e., inactive. It is known in the art that a repository may have multiple items; therefore, it would be obvious that an agent object repository would have a second agent object distinct from another.);
and attempting to instantiate, via the one or more processors and in the cloud-based container service based on the second agent object and the second configuration information, the second instance of the second agent in the memory of the cloud-based container service (Col. 17 Lines 48-49- the manager 130 may operate to generate and configure that instance. Col. 11, Lines 54-57-For example, the on-demand code execution system 110 or various constituents thereof could implement various Web services components, hosted or “cloud” computing environments; Col. 14, Lines 53-57-the call includes metadata that indicates […] the computing resources (e.g., memory, etc.) to be reserved for executing the source code. Please note that executing the source code with computer resources, including memory, as well as a processor, known in the art to be a computing resource, in a system implementing a cloud computing environment corresponds to Applicant’s via one or more processors in a cloud-based container service and a memory of the cloud-based container service. Please note that generating the instance corresponds to Applicant’s attempting to instantiate the second instance of the second agent, and configuring the instance corresponds to doing so based on configuration information.)
Regarding Claim 22, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 10, Wennerstrom further discloses the predetermined list ([0387] The interface_list type takes either the agents helper or a raw value as an input. The type is used for populating a template input with a list of Agents. Please note that the populated list of Agents corresponds to Applicant’s predetermined list.);
Gerdesmeier further discloses determine based on the predetermined list of the one or more instances of the agents expected to be instantiated and the current operational statuses of the one or more instances of the agents expected to be instantiated, whether a second instance of a second agent of the one or more instances of the agents expected to be instantiated is inactive ([0035] As instances are released by a customer when, for example, the instance is terminated, the instances may be returned to the available instances 110 in the instance pool 108. Please note that returning an instance to the instance pool 108 when the instance is released by a customer corresponds to Applicant’s determining whether a second instance of a second agent is inactive, as it determines the instance is no longer being used by the customer and thus inactive. Furthermore, since a list inherently may have multiple items included, this corresponds to Applicant’s second instance of a second agent, distinct from another instance of an agent.);
receive, via the API from the agent configuration repository and based on the determination that the second instance of the second agent expected to be instantiated is inactive, second configuration information for the second instance of the second agent ([0023] a task definition 102 is received at a container management service 104; [0036] The container management service 104 will select the instance 106 from the available instances 110 of the instance pool 108 based on the task definition 102, as described herein. For example, the task definition 102 may specify a set of parameters that define resources that may be used to instantiate a container on the instance and perform the task specified in the task definition. Please note that the instance pool 108 corresponds to Applicant’s agent configuration repository, the available instances 110 correspond to Applicant’s determination that the second agent is inactive as it consists of instances that are inactive, i.e., not being utilized by other clients, and the task definition 102 corresponds to Applicant’s second configuration information for the instance of the agent. This is then received by the container management service 104, corresponding to Applicant’s receiving step. It is known in the art that a repository may have multiple items; therefore, it would be obvious that an agent object repository would have a second agent object distinct from another.);
including attempt to connect the second instance of the second agent to the agent status server to provide second agent status information to the agent status server ([0059] instance 502 has a task 504 […] the task 504 may communicate with other services via the network interface 508. Please note that the instance’s task communicating with other services via the network interface 508 corresponds to Applicant’s attempting to connect the second instance of the agent to the agent status server, as the network interface can facilitate connection to a server. This would allow the transmission of data such as agent status information, in this case, the statuses of instances as described by Yanacek.).
Yanacek further discloses receive, via the API from the agent object repository and based on a determination that the second instance of the second agent expected to be instantiated is inactive, a second agent object corresponding to the second instance of the second agent ([0035] As instances are assigned to a customer, the instances may be removed from the available instances 110 in the instance pool 108. Please note that the instance pool 108 corresponds to Applicant’s agent object repository, the instance corresponds to the second agent object, and removing the instance from the available instances 110 in the instance pool 108 corresponds to Applicant’s receiving a second agent object corresponding to the second instance of the second agent from an agent object repository after determining the instance of the agent is inactive, as it provides an instance to the recipient after determining it is available, i.e., inactive. It is known in the art that a repository may have multiple items; therefore, it would be obvious that an agent object repository would have a second agent object distinct from another.);
and attempt to instantiate, in the cloud-based container service based on the second agent object and the second configuration information, the second instance of the second agent in the memory of the cloud-based container service (Col. 17 Lines 48-49- the manager 130 may operate to generate and configure that instance. Col. 11, Lines 54-57-For example, the on-demand code execution system 110 or various constituents thereof could implement various Web services components, hosted or “cloud” computing environments; Col. 14, Lines 53-57-the call includes metadata that indicates […] the computing resources (e.g., memory, etc.) to be reserved for executing the source code. Please note that executing the source code with computer resources, including memory, as well as a processor, known in the art to be a computing resource, in a system implementing a cloud computing environment corresponds to Applicant’s via one or more processors in a cloud-based container service and a memory of the cloud-based container service. Please note that generating the instance corresponds to Applicant’s attempting to instantiate the second instance of the second agent, and configuring the instance corresponds to doing so based on configuration information.)
Claims 4, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Yanacek et al. (US 11119826 B2) in view of Gerdesmeier et al. (US 20180088993 A1) and further in view of Wennerström et al. (US 20220158926 A1) as applied to claims 1, 10, and 19 above, and further in view of Singh et al. (US 9256467 B1), hereinafter referred to as Yanacek, Gerdesmeier, Wennerstrom, and Singh, respectively.
Regarding Claim 4, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 1 does not explicitly disclose storing configuration information of the instance of the agent in the agent configuration repository
However, Singh discloses storing configuration information of the instance of the agent in the agent configuration repository (Col. 13, lines 22-33- the container manager backend services may receive information from individual container agents 222 regularly, such as information related to life-cycle events and heartbeats (e.g., periodic signals sent by the container agents 222 to indicate normal operation […] this information may be communicated to […] the agent communication services 220, which […] stores the information in the database 216 . Please note that information related to life-cycle events and heartbeats of individual container agents 222 corresponds to Applicant’s configuration information of the instance of the agent, and storing it in the database 216 corresponds to Applicant’s storing it in the agent configuration repository.).
Yanacek-Gerdesmeier-Wennerstrom and Singh are both considered to be analogous to the claimed invention because they are in the same field of instance management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek-Gerdesmeier-Wennerstrom to incorporate the teachings of Singh to modify the instantiation and configuration system of Yanacek-Gerdesmeier-Wennerstrom to store configuration information of the instance of the agent in the agent configuration repository, allowing for improved monitoring of life-cycle events and heartbeats of agents as described in Singh.
Regarding Claim 13, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 10 does not explicitly disclose store configuration information of the instance of the agent in the agent configuration repository.
However, Singh discloses store configuration information of the instance of the agent in the agent configuration repository (Col. 13, lines 22-33- the container manager backend services may receive information from individual container agents 222 regularly, such as information related to life-cycle events and heartbeats (e.g., periodic signals sent by the container agents 222 to indicate normal operation […] this information may be communicated to […] the agent communication services 220, which […] stores the information in the database 216. Please note that information related to life-cycle events and heartbeats of individual container agents 222 corresponds to Applicant’s configuration information of the instance of the agent, and storing it in the database 216 corresponds to Applicant’s storing it in the agent configuration repository.).
Yanacek-Gerdesmeier-Wennerstrom and Singh are both considered to be analogous to the claimed invention because they are in the same field of instance management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek-Gerdesmeier-Wennerstrom to incorporate the teachings of Singh to modify the instantiation and configuration system of Yanacek-Gerdesmeier-Wennerstrom to store configuration information of the instance of the agent in the agent configuration repository, allowing for improved monitoring of life-cycle events and heartbeats of agents as described in Singh.
Regarding Claim 20, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 19 does not explicitly disclose wherein the instructions further cause the one or more processors to perform steps comprising: storing configuration information of the instance of the agent in the agent configuration repository.
However, Singh discloses wherein the instructions further cause the one or more processors to perform steps comprising: storing configuration information of the instance of the agent in the agent configuration repository (Col. 13, lines 22-33- the container manager backend services may receive information from individual container agents 222 regularly, such as information related to life-cycle events and heartbeats (e.g., periodic signals sent by the container agents 222 to indicate normal operation […] this information may be communicated to […] the agent communication services 220, which […] stores the information in the database 216. Please note that information related to life-cycle events and heartbeats of individual container agents 222 corresponds to Applicant’s configuration information of the instance of the agent, and storing it in the database 216 corresponds to Applicant’s storing it in the agent configuration repository.).
Yanacek-Gerdesmeier-Wennerstrom and Singh are both considered to be analogous to the claimed invention because they are in the same field of instance management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek-Gerdesmeier-Wennerstrom to incorporate the teachings of Singh to modify the instantiation and configuration system of Yanacek-Gerdesmeier-Wennerstrom to store configuration information of the instance of the agent in the agent configuration repository, allowing for improved monitoring of life-cycle events and heartbeats of agents as described in Singh.
Claims 6, 9, 15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Yanacek et al. (US 11119826 B2) in view of Gerdesmeier et al. (US 20180088993 A1) and further in view of Wennerström et al. (US 20220158926 A1) as applied to claims 5, 9, 14, and 17 above, and further in view of Browning et al. (US 20060242389 A1), hereinafter referred to as Yanacek, Gerdesmeier, Wennerstrom, and Browning, respectively.
Regarding Claim 6, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 5 discloses from Yanacek the replacement instance of the agent (Col. 29 Lines 22-24- an alternative worker manager 140. Please note that an alternative worker manager 140 corresponds to Applicant’s replacement instance of the agent, as each worker manager 140 contains a list of instances corresponding to agents.); the task- specific container (Col. 27, Lines 40-41- an execution environment (e.g., a […] container; Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note the container that is the execution environment corresponds to Applicant’s container);
Yanacek-Gerdesmeier-Wennerstrom does not explicitly disclose retrieving a quantity threshold of attempts to instantiate; determining whether the quantity threshold of attempts has been satisfied and has not been successfully instantiated; and inactivating, based on a determination that the quantity threshold of attempts has been satisfied and has not been successfully instantiated.
However, Browning discloses retrieving a quantity threshold of attempts to instantiate ([0082] to start a sibling hardware thread […] a predetermined number of attempts. Please note that a predetermined number of attempts to start a sibling hardware thread corresponds to Applicant’s retrieving a quantity threshold of attempts to instantiate); determining whether the quantity threshold of attempts has been satisfied and has not been successfully instantiated ([0082] if a predetermined number of attempts is reached or if the attempt fails. Please note that a predetermined number of attempts has been reached or if the attempt fails corresponds to Applicant’s determining whether the quantity threshold of attempts has been satisfied and has not been successfully instantiated.); and inactivating, based on a determination that the quantity threshold of attempts has been satisfied and has not been successfully instantiated ([0082] if a predetermined number of attempts is reached or if the attempt fails for a predetermined reason, then the process may terminate. Please note that terminating the process corresponds to Applicant’s inactivating.).
Yanacek-Gerdesmeier-Wennerstrom and Browning are both considered to be analogous to the claimed invention because they are in the same field of instance and container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek-Gerdesmeier-Wennerstrom to incorporate the teachings of Browning to modify the instantiation and configuration system of Yanacek-Gerdesmeier-Wennerstrom to attempt instantiation of the replacement instance of the agent up to a threshold quantity of attempts, allowing for improved efficiency when encountering errors and not wasting resources making excessive attempts, as described in Browning.
Regarding Claim 9, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 8 discloses from Yanacek the replacement instance of the agent (Col. 29 Lines 22-24- an alternative worker manager 140. Please note that an alternative worker manager 140 corresponds to Applicant’s replacement instance of the agent, as each worker manager 140 contains a list of instances corresponding to agents.); the task- specific container (Col. 27, Lines 40-41- an execution environment (e.g., a […] container; Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note the container that is the execution environment corresponds to Applicant’s container);
Yanacek-Gerdesmeier-Wennerstrom further discloses from Gerdesmeier connect the replacement instance of the agent to the processing task in the task- specific container ([0061] The container management service may next create 606 the task framework […] a “task framework” is the execution environment for the task […] The task framework […] connects with the instance agent. Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note that connecting the instance agent to task framework corresponds to Applicant’s connecting the replacement instance of the agent to the processing task performed by the container, as it allows the instance agent to communicate with the task.)
Yanacek-Gerdesmeier-Wennerstrom does not explicitly disclose retrieving a quantity threshold of attempts; determining whether the quantity threshold of attempts has been satisfied and has not been successfully; and inactivating, based on a determination that the quantity threshold of attempts has been satisfied and has not been successfully.
However, Browning discloses retrieving a quantity threshold of attempts ([0082] to start a sibling hardware thread […] a predetermined number of attempts. Please note that a predetermined number of attempts to start a sibling hardware thread corresponds to Applicant’s retrieving a quantity threshold of attempts); determining whether the quantity threshold of attempts has been satisfied and has not been successfully ([0082] if a predetermined number of attempts is reached or if the attempt fails. Please note that a predetermined number of attempts has been reached or if the attempt fails corresponds to Applicant’s determining whether the quantity threshold of attempts has been satisfied and has not been successful.); and inactivating, based on a determination that the quantity threshold of attempts has been satisfied and has not been successfully ([0082] if a predetermined number of attempts is reached or if the attempt fails for a predetermined reason, then the process may terminate. Please note that terminating the process corresponds to Applicant’s inactivating.).
Yanacek-Gerdesmeier-Wennerstrom and Browning are both considered to be analogous to the claimed invention because they are in the same field of instance and container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek-Gerdesmeier-Wennerstrom to incorporate the teachings of Browning to modify the instantiation and configuration system of Yanacek-Gerdesmeier-Wennerstrom to attempt connection of the replacement instance of the agent to the processing task in the container up to a threshold quantity of attempts, allowing for improved efficiency when encountering errors and not wasting resources making excessive attempts, as described in Browning.
Regarding Claim 15, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 14 discloses from Yanacek the replacement instance of the agent (Col. 29 Lines 22-24- an alternative worker manager 140. Please note that an alternative worker manager 140 corresponds to Applicant’s replacement instance of the agent, as each worker manager 140 contains a list of instances corresponding to agents.); the task- specific container (Col. 27, Lines 40-41- an execution environment (e.g., a […] container; Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note the container that is the execution environment corresponds to Applicant’s container);
Yanacek-Gerdesmeier-Wennerstrom does not explicitly disclose retrieve a quantity threshold of attempts to instantiate; determine whether the quantity threshold of attempts has been satisfied and has not been successfully instantiated; and inactivate, based on a determination that the quantity threshold of attempts has been satisfied and has not been successfully instantiated.
However, Browning discloses retrieve a quantity threshold of attempts to instantiate ([0082] to start a sibling hardware thread […] a predetermined number of attempts. Please note that a predetermined number of attempts to start a sibling hardware thread corresponds to Applicant’s retrieving a quantity threshold of attempts to instantiate); determine whether the quantity threshold of attempts has been satisfied and has not been successfully instantiated ([0082] if a predetermined number of attempts is reached or if the attempt fails. Please note that a predetermined number of attempts has been reached or if the attempt fails corresponds to Applicant’s determining whether the quantity threshold of attempts has been satisfied and has not been successfully instantiated.); and inactivate, based on a determination that the quantity threshold of attempts has been satisfied and has not been successfully instantiated ([0082] if a predetermined number of attempts is reached or if the attempt fails for a predetermined reason, then the process may terminate. Please note that terminating the process corresponds to Applicant’s inactivate.).
Yanacek-Gerdesmeier-Wennerstrom and Browning are both considered to be analogous to the claimed invention because they are in the same field of instance and container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek-Gerdesmeier-Wennerstrom to incorporate the teachings of Browning to modify the instantiation and configuration system of Yanacek-Gerdesmeier-Wennerstrom to attempt instantiation of the replacement instance of the agent up to a threshold quantity of attempts, allowing for improved efficiency when encountering errors and not wasting resources making excessive attempts, as described in Browning.
Regarding Claim 18, Yanacek-Gerdesmeier-Wennerstrom as described in Claim 17 discloses from Yanacek the replacement instance of the agent (Col. 29 Lines 22-24- an alternative worker manager 140. Please note that an alternative worker manager 140 corresponds to Applicant’s replacement instance of the agent, as each worker manager 140 contains a list of instances corresponding to agents.); the task- specific container (Col. 27, Lines 40-41- an execution environment (e.g., a […] container; Col. 2, Lines 30-36-providing reserved, pre-warmed capacity in a serverless system that can be used to service calls to a specific set of code (a “task”) […] increas[ing] the chances that the call is routed to a “warm” (e.g., pre-provisioned) environment; Col. 2, Lines 57-59-a variety of execution environments (e.g., […] software containers, etc.) pre-provisioned. Please note that this corresponds to Applicant’s task-specific containers, as the containers of the environment are task-specific, servicing calls for a specific set of code of a task. Please note the container that is the execution environment corresponds to Applicant’s container);
Yanacek-Gerdesmeier-Wennerstrom further discloses from Gerdesmeier connect the replacement instance of the agent to the processing task in the task- specific container ([0061] The container management service may next create 606 the task framework […] a “task framework” is the execution environment for the task […] The task framework […] connects with the instance agent. Please note that connecting the instance agent to task framework corresponds to Applicant’s connecting the instance of the agent to the processing task performed by the container, as it allows the instance agent to communicate with the task.)
Yanacek-Gerdesmeier-Wennerstrom does not explicitly disclose retrieve a quantity threshold of attempts; determine whether the quantity threshold of attempts has been satisfied and has not been successfully; and inactivate, based on a determination that the quantity threshold of attempts has been satisfied and has not been successfully connected.
However, Browning discloses retrieve a quantity threshold of attempts ([0082] to start a sibling hardware thread […] a predetermined number of attempts. Please note that a predetermined number of attempts to start a sibling hardware thread corresponds to Applicant’s retrieving a quantity threshold of attempts); determine whether the quantity threshold of attempts has been satisfied and has not been successfully ([0082] if a predetermined number of attempts is reached or if the attempt fails. Please note that a predetermined number of attempts has been reached or if the attempt fails corresponds to Applicant’s determining whether the quantity threshold of attempts has been satisfied and has not been successful.); and inactivate, based on a determination that the quantity threshold of attempts has been satisfied and has not been successfully ([0082] if a predetermined number of attempts is reached or if the attempt fails for a predetermined reason, then the process may terminate. Please note that terminating the process corresponds to Applicant’s inactivate.).
Yanacek-Gerdesmeier-Wennerstrom and Browning are both considered to be analogous to the claimed invention because they are in the same field of instance and container management. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Yanacek-Gerdesmeier-Wennerstrom to incorporate the teachings of Browning to modify the instantiation and configuration system of Yanacek-Gerdesmeier-Wennerstrom to attempt connection of the replacement instance of the agent to the processing task in the container up to a threshold quantity of attempts, allowing for improved efficiency when encountering errors and not wasting resources making excessive attempts, as described in Browning.
Response to Arguments
Applicant’s arguments filed 01/05/2026 have been fully considered but they are not persuasive.
Applicant’s arguments are summarized as follows:
Yanacek’s container does not teach the task-specific container required in amended independent Claim 1, as it teaches general-purpose execution environments that can run any task assigned to them. Though the Office Action states that specific code in the containers makes them task-specific, the Applicant argues that the specific code refers to all Yanacek’s containers performing the same generic task, since they may serve any user’s calls. The virtual machine instances of Yanacek are configured in a similar manner, and do not relate to task specific containers with specific agents but to different operating environments and different languages. Yanacek additionally does not teach containers pre-configured for a specific task with specific agents, as it maintains pools of generic containers with various runtime configurations, and selects an appropriate container when a task call is received-the “warm” environment is warm in the sense of being pre-booted, not pre-configured for a specific task.
Additionally, Gerdesmeier also does not teach the task-specific containers, as it teaches selecting instances from a pool based on task definition parameters specifying resource requirements, not specific agents. Even combining the two references, there is no suggestion that containers should be pre-designated for specific tasks, each task-specific container should have a predetermined list of expected agents, or that the system should check which expected agents are missing and instantiate only those missing agents.
Furthermore, the Claim has been amended to state that the list of agents is a predetermined list that identifies specific agent instances that should exist for the task-specific container to properly function, but neither Yanacek nor Gerdesmeier teach a logic that compares a live state against an internal list of expected agents in a specific container, and only track if the container itself is busy or idle. Amended Claim 1 compares the predetermined list of agents and the actually instantiated agents, but Yanacek looks for a warm container, and retrieves a container for the pool of containers if one does not exist. Both Yanacek and Gerdesmeier are silent regarding comparing the predetermined list with the actually instantiated agents in a container.
Lastly, Gerdesmeier is cited as determining whether an agent is inactive and for receiving agent objects/configuration, but it describes returning generic instances to a pool when released by a customer and instance lifecycle management in the pool, not about determining which specific agents are missing from a task-specific container by comparing a predetermined list with the actually instantiated agents in a container. Furthermore, the available instances are a pool of generic unassigned instances, not a repository of agent objects for specific task-specific containers.
Thus, the independent claims are patent eligible, the dependent claims 3, 5, 7-8, 12, 14, 16-17, 19, and 21-22 are also patent eligible, and overcome the rejections under 35 U.S.C. 103.
Since Yanacek in view of Gerdesmeier does not teach the recitations of claims 1, 10, and 19, as previously mentioned, and Singh additionally does not teach those recitations, dependent claims 4, 13, and 20 are allowable since they are dependent on allowable independent claims.
Since Yanacek in view of Gerdesmeier does not teach the recitations of claims 1, 10, and 19, as previously mentioned, and Browning additionally does not teach those recitations, dependent claims 6, 9, 15, and 18 are allowable since they are dependent on allowable independent claims.
Regarding A), the examiner respectfully disagrees. The Applicant’s arguments are moot, as the rejections of the Claims now rely on a new grounds of rejection, Yanacek-Geredesmeier-Wennerstrom, which discloses the limitations stated by the Applicant via the combination of references, as stated above. Therefore, the recited features can be found in the cited combination of references, the independent Claims remain rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. As a result, contrary to Applicant’s arguments, because the dependent claims 3, 5, 7-8, 12, 14, 16-17, 19, and 21-22 depend on unpatentable claims and do not add limitations that overcome the rejection, they likewise remain rejected, and the application is not in condition for allowance. The rejections under 35 U.S.C. 103 are maintained.
Regarding B), the examiner respectfully disagrees. As previously stated, independent claims 1, 10, and 19 remain rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. Therefore, contrary to Applicant’s arguments, because the dependent claims 4, 13, and 20 depend on unpatentable claims and do not add limitations that overcome the rejection, they likewise are rejected, and the application is not in condition for allowance.
Regarding C), the examiner respectfully disagrees. As previously stated, independent claims 1, 10, and 19 remain rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. Therefore, contrary to Applicant’s arguments, because the dependent claims 6, 9, 15, and 18 depend on unpatentable claims and do not add limitations that overcome the rejection, they likewise are rejected, and the application is not in condition for allowance.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rosoff et al. (US 20210311764 A1) discloses agents in pods, using an API to allow deployment of containerized applications, probing containers for liveness and readiness, and providing the status of containers to a controller, as well as determining if pod VM is live or ready (see [0004, 0025, 0061, 0070, 0073]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARAZ T AKBARI whose telephone number is (571)272-4166. The examiner can normally be reached Monday-Thursday 9:30am-7:30pm ET.
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, April Blair can be reached at (571)270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/FARAZ T AKBARI/Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights