DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This final office action is responsive to the amendments filed on 02/17/2026.
Claims 1-20 are pending.
Response to Amendment
Applicant has amended independent claims 17, 20 and dependent claims 14, 16 to include new/old limitations in a form not previously presented necessitating new search and considerations.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fakhouri et al. (US 2020/0278857 A1, hereafter Fakhouri) in view of Chittigala et al. (US 2018/0101374 A1, hereafter Chittigala).
Fakhouri and Chittigala were cited in the last office action.
As per claim 1, Fakhouri teaches the invention substantially as claimed including a method, comprising:
determining, by a container orchestration system (COS) executing on a computing device ([0007] orchestrator, Pivotal container service, kubernetes cluster, container orchestrator [0015] software platform, one or more containers, upgrade, rolled out by platform orchestrator), that an executing first operator process is to be upgraded to a second operator process in an upgrade process ([0033] workload, platform orchestrator should upgrade the computing resource of the software platform), wherein the first operator process maintains on a cluster of compute nodes a desired identified state of an application ([0012] fig. 1 platform nodes 150 [0003] workload, software tasks, [0007] workload continue stateful execution i.e. maintaining the state [0020] stateful application on the software platform [0036] workloads of stateful applications, observing a particular ordering of tasks during deployment of tasks on particular nodes and during updates of the software platform );
prior to initiating the second operator process ([0046] Optionally, the system executes a pre-upgrade process before upgrading platform nodes), determining, by the COS, that the upgrade process will cause an initiation of a new container of the application 300 for updating a software platform, [0041] receives a request to upgrade the computing resources of a software platform 310 [0042] obtains a workload specification 320 [0046] execute pre-upgrade process before upgrading platform nodes 350 [0019] system upgrades, software platform, launching, an entirely separate software platform that has the requested updates );
taking, by the COS, an upgrade request action based on the determination ([0044] upgrading, platform node, installing an upgrade to a virtual machine /container ).
Fakhouri doesn’t specifically teaches to replace existing container of the application, determining, by the COS, that an upgrade mode associated with the first operator process is a rolling upgrade mode, wherein the existing container and the new container will execute concurrently for a period of time; making a determination, by the COS, whether computing resources needed to execute the existing container and the new container concurrently are available.
Chittigala, however, teaches upgrade process to initiate container to replace existing container of the application ([0053] fig. 4 upgrade management, LPAR, virtual machines, perform one or more tasks or functions, dynamically upgrading, using a surrogate LPAR node [0057] fig. 4 generation of a first surrogate LPAR node to succeed the first original LPAR node as a first established member of the set of established members may be initiated 420 [0065] replacing the first original LPAR node with a first surrogate LPAR node having an upgraded configuration), determining, by the COS, that an upgrade mode associated with the first operator process is a rolling upgrade mode ([0017] managing upgrades for LPAR node clusters, continuous application and service availability for the node cluster may be maintained e.g., as upgrades are performed without node downtime), wherein the existing container and the new container will execute concurrently for a period of time (fig. 4 initiate generation of first surrogate LPAR node 420 identify the first surrogate node as new original LPAR node 430 join the first surrogate LPAR with the set of LPAR nodes 440 450 establish the first surrogate LPAR node as the member 460 [0017] original node, maintain cluster activities and system/application availability until completion of the upgrades to the surrogate node, at which point the surrogate node may join the cluster, surrogate node, replace, the original node i.e. concurrency)
making a determination, by the COS, whether computing resources needed to execute the existing container and the new container concurrently are available ([0051] management layer 330, resource provisioning, Service level management provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA [0056] initiating performance of the LKU operation while the original assets are running may include collecting information about the node for use during the upgrade process e.g., system properties, performance characteristics, workload attributes; management widget may collect information about the degree of system usage e.g., disk storage, processor resources, memory resources, input and output data traffic, and other aspects of the in-use first LPAR node e.g., for use when generating a first surrogate LPAR node for the first original LPAR node [0074] upgrading, additional storage).
It would have been obvious to one of ordinary skills in the art before the effective filing date of the invention was made to combine the teachings of Fakhouri with the teachings of Chittigala of upgrade process launching a surrogate LPAR and joining the surrogate LPAR as new LPAR and replacing the original LPAR, pre-arrangement for cloud resources by collecting resource usage information to improve efficiency and allow to replace existing container, determining upgrade mode is a rolling upgrade mode, wherein the existing container and the new container will execute concurrently for a period of time; determining whether computing resources needed to execute the existing container and the new container concurrently are available to the method of Fakhouri as in the instant invention. The combination of analogous prior art would have been obvious because applying known method of generating surrogate LPAR/VM and replacing the original LPAR/VM to the method of Fakhouri for upgrading the containers to yield predictable result and improved efficiency.
As per claim 2, Fakhouri teaches wherein determining, by the COS executing on a computing device, that an executing first operator process is to be upgraded to a second operator process in an upgrade process comprises:
obtaining a resource file that corresponds to the first operator process, wherein the resource file is used to instantiate a resource ([0010] orchestrator, launch multiple different software platform, according to different specification, creation and deletion of virtual machines and containers); and
determining, based on the resource, that a desired state of the resource
Chittigala teaches remaining claim elements of desired resource state differs from a current stat of the resource ([0064] cluster state of the first original LPAR node, acquire the cluster state i.e. original and acquired state).
Claim 17 recites a computing device, comprising: a memory; and a processor device coupled to the memory, the processor device to perform elements similar to claim 1. Therefore, it is rejected for the same rationale.
Claim 20 recites non-transitory computer-readable storage medium that includes computer-executable instructions that, when executed, cause one or more processor devices to perform elements similar to claim 1. Therefore, it is rejected for the same rationale.
Claims 3-12, 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fakhouri in view of Chittigala, as applied to above claims, and further in view of Kumar et al. (US 9,639,502 B1, hereafter Kumar).
Kumar was cited in the last office action.
As per claim 3, Chittigala teaches wherein determining, by the COS, that the upgrade process will cause an initiation of a new container of the application to replace an existing container of the application comprises:
on, surrogate LPAR [0057] a new e.g., newest, up-to-date system configuration may be installed on the first surrogate LPAR node e.g., newest software version, newest cluster software version); and
determining that the container image for the existing container and the container image for the new container differ ([0057] new/newest up-to-date system configuration, newest cluster software version [0058] system image, generated, original ).
Fakhouri and Chittigala, in combination, do not specifically teach obtaining a first file that corresponds to the first operator process and a second file that corresponds to the second operator process.
Kumar, however, teaches obtaining a first file that corresponds to the first operator process (fig. 4 receive VM management configurations 404; col 7 lines 5-25) and a second file that corresponds to the second operator process (fig. 4 receive VM management configurations 404; col 7 lines 5-25).
It would have been obvious to one of ordinary skills in the art before the effective filing date of the invention was made to combine the teachings of Fakhouri and Chittigala with the teachings of Kumar of receiving desired VM management configuration to improve efficiency and allow obtaining a first file that corresponds to the first operator process and a second file that corresponds to the second operator process to the method of Fakhouri and Chittigala as in the instant invention. The combination would have been obvious because applying the known method of receiving virtual machine management configurations as taught by Kumar with the container management method taught by the combination of Fakhouri and Chittigala to yield predictable results with improved efficiency.
As per claim 4, Chittigala teaches
Kumar teaches remaining claim elements of first files includes deployment associated with first process, and wherein the second file includes deployment associated with the second operator process (fig. 4 receive VM management configurations 404 implement VM configuration 416; col 7 lines 5-25).
As per claim 5, Chittigala teaches
Kumar teaches remaining claim elements of wherein obtaining a first file that corresponds to the first operator process and a second file that corresponds to the second operator process comprises sending the first file and the second file to an operator manager platform (col 7 lines 5-25 The received virtual machine management configuration may then be passed to a virtual machine management daemon).
As per claim 6, wherein determining that an upgrade mode associated with the first operator process is a rolling upgrade mode comprises ([0017] managing upgrades for LPAR node clusters, continuous application and service availability for the node cluster may be maintained e.g., as upgrades are performed without node downtime):
determining, , continuous application and service availability for the node cluster may be maintained e.g., as upgrades are performed without node downtime).
Kumar teaches obtaining a file that corresponds to the first operator process, wherein the file includes at least one deployment associated with the first operator process (fig. 4 receive VM management configurations 404 implement VM configuration 416; col 7 lines 5-25) ; and
determining, based on the file, upgrade (fig. 6 receive updated VM configuration 604-yes).
As per claim 7, Chittigala teaches wherein making a determination whether computing resources needed to execute the existing container and the new container concurrently are available (fig. 4 initiate generation of first surrogate LPAR node 420 identify the first surrogate node as new original LPAR node 430 join the first surrogate LPAR with the set of LPAR nodes 440 450 establish the first surrogate LPAR node as the member 460 [0017] original node, maintain cluster activities and system/application availability until completion of the upgrades to the surrogate node, at which point the surrogate node may join the cluster, surrogate node, replace, the original node i.e. concurrency [0051] management layer 330, resource provisioning, Service level management provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA [0056] initiating performance of the LKU operation while the original assets are running may include collecting information about the node for use during the upgrade process e.g., system properties, performance characteristics, workload attributes; management widget may collect information about the degree of system usage e.g., disk storage, processor resources, memory resources, input and output data traffic, and other aspects of the in-use first LPAR node e.g., for use when generating a first surrogate LPAR node for the first original LPAR node [0074] upgrading, additional storage) comprises:
Kumar teaches remaining claim elements of obtaining a first file that corresponds to the first operator process (fig. 4 receive VM management configurations 404 implement VM configuration 416; col 7 lines 5-25);
obtaining a second file that corresponds to the second operator process (fig. 4 receive VM management configurations 404 implement VM configuration 416; col 7 lines 5-25);
calculating an expected amount of computing resources, wherein the expected amount of computing resources comprises the computing resources needed to execute the existing container and the computing resources needed to execute the new container ( fig. 6 can currently available VM resources satisfy updated configuration 610; fig. 4 compare available resources to VM management configuration 410);
identifying computing resources available in the cluster of compute nodes (fig. 6 determine currently available VM resources 608); and
determining that the expected amount of computing resources is less than the computing resources available in the cluster of compute nodes ( fig. 6 can currently available VM resources satisfy updated configuration - Yes 610).
As per claim 8, Fakhouri teaches wherein identifying computing resources available in the cluster of compute nodes comprises:
identifying each container in the cluster of compute nodes (fig. 4 cloud env 110 software platforms 140 platform nodes 150 [0012] each platform node, virtual machine, container or both), wherein the cluster of compute nodes comprises a plurality of containers ([0012] each platform node, virtual machine, container or both);
determining computing resources provisioned for each node of the compute nodes ([0007] provisions resources for component of software platforms, provisioning resources for nodes of cluster [0010] software platform, hardware resources, creation of virtual machine and containers), wherein each container in the cluster of compute nodes is hosted on at least one node of the cluster of compute nodes [0012] each platform node, virtual machine, container or both); and
Kumar teaches remaining claim elements of determining computing resources needed for each container in the cluster of compute nodes (fig. 4 receive desired VM management configuration 404 col 8 lines 59-67 ; fig. 6 604);
calculating a difference between the computing resources provisioned for each node of the compute nodes and the computing resources needed for each container in the cluster of compute nodes (fig. 4 compare available resources to VM management configuration 410 can available VM resources satisfy configuration-yes/no 412);
wherein the computing resources available in the cluster of compute nodes comprises the difference between the computing resources provisioned and the computing resources needed for each container in the cluster of compute nodes (fig. 4 compare available resources to VM management configuration 410 can available VM resources satisfy configuration-yes/no 412).
As per claim 9, Fakhouri teaches wherein taking an upgrade request action based on the determination comprises performing an upgrade of the executing first operator process to the second operator process ([0044] fig. 3 system upgrades platform nodes, installing upgrade to virtual machine / container 330), wherein the upgrade request action comprises performing the upgrade of the executing first operator process to the second operator process ([0044] fig. 3 system upgrades platform nodes, installing upgrade to virtual machine / container 330).
Kumar teaches remaining claim elements of upgrade based on the determination ( fig. 4 can available VM resources satisfy configuration-yes 412 implement VM configuration 416).
As per claim 10, Kumar teaches wherein making a determination whether computing resources needed to execute the existing container and the new container concurrently are available comprises:
obtaining a first file that corresponds to the first operator process (fig. 4 receive VM management configuration 404 ) and identifies the existing container (fig. 4 determine available resources ), wherein the first file identifies computing resources needed to execute the existing container (fig. 4 receive VM management configuration 404 );
obtaining a second file that corresponds to the second operator process (fig. 4 receive VM management configuration 404 ) and identifies the new container (fig. 4 receive VM management configuration 404 ), wherein the second file identifies computing resources needed to execute the new container (fig. 4 receive VM management configuration 404 );
calculating an expected amount of computing resources, wherein the expected amount of computing resources comprises the computing resources needed to execute the existing container and the computing resources needed to execute the new container (fig. 5 VM resource change 504-yes- 506-508 fig. 4 404 410);
identifying computing resources available in the cluster of compute nodes (fig. 4 determine available resources 408 ); and
determining that the expected amount of computing resources is greater than the computing resources available in the cluster of compute nodes ((fig. 4 compare available resources to VM management configuration 410 can available VM resources satisfy configuration - yes/no 412).
As per claim 11, Kumar teaches wherein taking an upgrade request action based on the determination comprises stopping an upgrade of the executing first operator process to the second operator process (fig. 5 can currently available VM resources to VM management configuration 508 -No i.e. upgrade is not possible), wherein the upgrade request action comprises stopping the upgrade of the executing first operator process to the second operator process (fig. 5 can currently available VM resources to VM management configuration 508 -No, notify user 516 i.e. VM configuration change is not implemented 514, col 12 lines 16-29).
As per claim 12, Kumar teaches subsequent to stopping the upgrade of the executing first operator process to the second operator process, sending an alert that indicates that there are insufficient computing resources to perform the upgrade of the executing first operator process to the second operator process (fig. 5 can currently available VM resources to VM management configuration 508 -No, notify user 516 i.e. VM configuration change is not implemented 514 i.e. similar to stopping the upgrade, col 12 lines 16-29).
As per claim 14, Fakhouri teaches provisioning the new compute node in the cluster of compute nodes ([0007] provisions resources for and configures the components of a software platform);
wherein taking an upgrade request action comprises performing an upgrade of the executing first operator process to the second operator process ([0033] workload, platform orchestrator should upgrade the computing resource of the software platform), wherein the upgrade request action comprises performing the upgrade of the executing first operator process to the second operator process ([0033] workload, platform orchestrator should upgrade the computing resource of the software platform [0074] upgrading, platform nodes, installing an upgrade to a virtual machine or a container).
Chittigala teaches remaining claim elements of requesting a new compute node with computing resources ([0021] on-demand network access to a shared pool of configurable computing resources [0022] provision computing capabilities, as needed [0051] resource provisioning, provides, dynamic procurement of computing resources).
Kumar teaches remaining claim elements of in response to determining that the expected amount of computing resources is greater than the computing resources available in the cluster of compute nodes (fig. 4 compare available resources to VM management configuration 410 can available VM resources satisfy configuration-No 412), determining a difference between the expected amount of computing resources and the computing resources available in the cluster of compute nodes (fig. 4 compare available resources to VM management configuration 410 can available VM resources satisfy configuration-No 412);
requesting computing resources of at least the difference between the expected amount of computing resources and the computing resources available in the cluster of compute nodes (fig. 4 compare available resources to VM management configuration 410 can available VM resources satisfy configuration-No 412; col 10 lines 29-40 modify the underlying VM resources by specifying a different set of machines to satisfy the desired configurations).
As per claim 15, Fakhouri teaches subsequent to performing the upgrade of the executing first operator process to the second operator process (fig. 3 upgrade platform nodes executing tasks 330, post-upgrade process 340 upgrade another group 350 360), determining that the computing resources available in the cluster of compute nodes exceed an amount of computing resources needed for the cluster of compute nodes; determining that the new compute node can be removed from the cluster of compute nodes ([0010] deletion of virtual machines and containers as needed); and
removing the new compute node from the cluster of compute nodes ([0010] deletion of virtual machines and containers as needed).
Chittigala also teaches removing the new compute node ([0021] computing resources, rapidly provisioned and released [0026]) .
Kumar teaches remaining claim elements of determining that the computing resources available in the cluster of compute nodes exceed an amount of computing resources needed for the cluster of compute nodes (fig. 4 compare resources 410 can available resources to VM management configuration 412 - yes fig. 5 510 -yes).
Claim 18 recites the computing device performing elements similar to claim 7. Therefore, it is rejected for the same rationale.
Claim 19 recites the computing device performing elements similar to claim 10. Therefore, it is rejected for the same rationale.
Allowable Subject Matter
Claims 13 and 16 would be allowable if rewritten to overcome the rejection(s) to include all of the limitations of the base claim and any intervening claims.
Response to Arguments
The previous 112(b) objections have been withdrawn in view of the Applicant’s arguments.
Applicant's arguments filed on 02/17/2026 have been fully considered but they are not persuasive. In Applicant’s response filed on 02/17/2026, Applicant argues the following:
Even before executing the new container, it is determined whether computing resources will be available for the new container. Nowhere does Fakhouri, Chittigala, or a combination therefor teach or suggest these features.
Applicant’s claim 1 recites: determining, by a container orchestration system (COS) executing on a computing device, that an executing first operator process is to be first operator process maintains on a cluster of compute nodes a desired identified state of an application. Applicant respectfully disagrees that Fakhouri [0007], [0015], [0033], [0012], [0036] and [0020] teaches these limitations.
Nowhere does Fakhouri [0012] disclose “desired identified state of an application”.
Moreover, and more important, Fakhouri [0012] discloses attributes of the software platform itself (i.e. the COS), not an “executing first process” that is separate from the COS, as recited in Applicant’s claim 1.
In other words, Applicant’s claim 1 recites two components, a COS and an operator process. It is clear that the components are separate because the COS determines that the first operator process is to be upgraded. Cited prior art appears to assert that a single component discloses both of these components.
No where does Fakhouri teach or suggest both a COS and an operator process that “maintains on a cluster of compute nodes a desired identified state of an application”.
Examiner assert that “determining, by a container orchestration system (COS) executing on a computing device, that an executing first operator process is to be upgraded to a second operator process in an upgrade process” is disclosed by Fakhouri [0033]. However, Fakhouri [0033] simply discloses a “workload specified ordering in which the platform orchestrator should upgrade the computing resource of the software platform”. Fakhouri [0015] discloses that “The computing resources can include, e.g. one or more virtual machines (VMs) and/or one of more containers”. Nothing in Fakhouri [0015] teaches or suggest that the “one or more virtual machines (VMs) and/or one or containers” are operator processes that “maintains on a cluster of compute nodes a desired identified state of an application”.
In fact, the Examiner asserted previously asserted that Applicant’s recited “first operator process” was disclosed by the Platform orchestrator itself (see above). Now the Examiner appears to assert that the “first operator process” is disclosed by “one or more virtual machines (VMs) and/or one or more containers”. Examiner’s inconsistency in what discloses Applicant’s recited “firs operator process” highlights the fact that Fakhouri fails to teach of suggest the recited features.
In fact, to be consistent, if the Examiner maintains that the “first operator process” is disclosed by the platform orchestrator itself, then under this interpretation Fakhouri would disclose that the platform orchestrator makes a determination that the platform orchestrator is to be upgraded.
Nowhere does Fakhouri disclose that the platform orchestrator makes a determination that the platform orchestrator is to be upgraded.
Examiner has thoroughly considered Applicant’s arguments, but respectfully, find them unpersuasive for at least the following reasons:
With respect to point a: Examiner respectfully disagree. Chittigala teaches upgrade management of configurable computing resources ([0002]). Chittigala teaches management layer provide resource provisioning; service level management provide cloud computing resource allocation and management such that required service levels are met. Service level planning and fulfillment provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA. A cloud manager 350 is representative of a cloud and can span all of the levels ([0051]). Chittigala further teaches to avoid system restarts and application shutdown during upgrade ([0056]), and collecting information about the node for use during the upgrade process. An LKU management widget may collect information about the degree of system usage (e.g., disk storage, processor resources, memory resources), input and output data traffic, and other aspects of the in-use first LPAR node (e.g., for use when generating a first surrogate LPAR node for the first original LPAR node) ([0056]). Chittigala also teaches performing updates or upgrades with respect to a single surrogate LPAR node that may then be joined to the set of LPAR nodes upon upgrade completion, such that system downtime, service unavailability, and excessive disk space usage can be avoided ([0074]). Therefore, Chittigala at least teaches i.) method to upgrade of LPAR i.e. container like entity; ii.) pre-arrangement of resources for which a future requirement is anticipated i.e. before initiation of new container, iii.) cloud manager i.e. orchestration system for performing management functions, which are, in combination, similar to the idea of claimed limitations in as argued “even before executing the new container, it is determined whether computing resources will be available for the new container”.
With respect to point b. Fakhouri teaches software system known as platform orchestrator that provisions resources for and configures the components of a software platform. One example of a platform orchestrator is Pivotal Container Service (PKS). PKS provides developers with an interface that allows them to set up and configure a Kubernetes cluster, which is an example of a cloud software platform. A Kubernetes cluster is a container orchestrator ([0007]). Platform orchestrator, PKS, and kubernetes cluster are various variation of equivalent container orchestration system (COS) executing on a computing device. Fakhouri further teaches container orchestrator that manages the execution of workloads in containers. Each software task in a kubernetes cluster can be referred to as pod, and each pod can have one or more containers that each execute the task. Therefore, POD/container/VMs managed by the COS are examples of operator process that are operating workloads. A Kubernetes cluster generally includes a master node and one or more worker nodes that can execute workloads in containers and ensure that the workloads continue stateful execution ([0007]), which is at least directed to stateful execution of the workloads in containers. Fakhouri teaches workload-specified ordering in which the platform orchestrator should upgrade the computing resources of the software platform. In particular, the workload specification 214 identifies different groups of one or more tasks, and specifies that the computing resources executing some particular groups of tasks should be upgraded before the computing resources executing other particular groups of tasks when upgrading the computing resources of the software platform 230 ([0033][0020] [0036]), which is directed towards ordered upgrade of the computing resources (i.e. VM / containers) of the software platform. Stateful execution of workload and ordered upgrade of the computing resource is similar to the idea of operator process maintaining on a cluster of compute node a desired identified state of an application e.g. workload executing on the POD/VM/containers as illustrated in fig. 1 ([0012]) i.e. platform orchestrator 130 is mapped to the COS and container/pod/ executing the workloads are examples of operator process that are being upgraded. Maintaining the order of upgrade of the computing resources executing the tasks and stateful execution of the workload as specified is similar to the idea of first operator process maintains on a cluster of compute nodes a desired identified state of an application.
With respect to point c.) Examiner respectfully indicate that platform orchestrator ([0012] fig. 1 130) is mapped to the claimed container orchestrator. Platform nodes of the software platform (fig. 1 140 150) that may be POD/VM/containers are mapped to one or more operator process. Various tasks (112) running on the platform nodes are the workloads and are mapped to the claimed applications. Fakhouri teaches i.) stateful execution of the workload ([0007], which at least suggests that these workloads/tasks (i.e. similar to claimed application) at least has certain states; and further teaches ii.) workload specification that specifies a workload-specified ordering in which the platform orchestrator should upgrade the computing resources of the software platform ([0033] [0036]), which is similar to the idea of desired identified state of an application.
With respect to point d.) As explained above with respect to point c.), Examiner respectfully indicate that platform orchestrator ([0012] fig. 1 130) is mapped to the claimed container orchestrator. Platform nodes of the software platform (fig. 1 140 150) that may be POD/VM/containers are mapped to one or more operator process. Various tasks (112) running on the platform nodes are the workloads and are mapped to the claimed applications. Thus platform nodes of the software platform comprising containers/VM/POD etc are considered operator process and is separate from the platform orchestrator as illustrated in fig. 1.
With respect to point e.) consistent with the response with respect to point c. and d.) above, Fakhouri teaches he computing resources can include, e.g., one or more virtual machines (VMs) and/or one or more containers. Generally, the upgrade can be rolled out by a platform orchestrator of the software platform ([0015]) i.e. while the VM/containers are being considered to be upgrade, the process of upgrade is rolled out by a platform orchestrator. Platform orchestrator and platform nodes/software components are two different entity and orchestrator provision resources for the software components and also configures the component of the software platform ([0007]).
With respect to point f.) same response as b.- e. above.
With respect to point g. ) As explained above with respect to point a.-e.), Fakhouri teaches execution of workload and upgrade of the container/VM i.e. operator process executing the workload (i.e. application) in an order specified in workload specification ([0033]), which is similar to the idea of claimed limitations of “maintains on a cluster of compute nodes a desired identified state of an application”.
With respect to point h.) consistent in view of the responses above with respect to points a-e., Examiner respectfully indicates that the mapping in question indicates orchestrator should upgrade the computing resources ([0033]) i.e. while orchestrator is the rolling out the upgrade, it is the software component (i.e. VM/container) that is being upgraded.
With respect to point i.) Same as response above a-h.
With respect to point j.) Examiner respectfully indicates that platform orchestrator 130 can launch multiple different software platforms, according to the different specification, on the hardware resources. Platform orchestrator, after launching a software platform, can orchestrate the creation and deletion of virtual machines and containers within the software platforms and is responsible for maintaining and updating the software platform ([0010], [0015]). Platform orchestrators, obtaining information about the topologies of workloads, can ensure that the software platform is upgraded with reduced disruption to the executing workloads([0016]). Fakhouri further teaches a workload specification 214 that specifies a workload-specified ordering in which the platform orchestrator should upgrade the computing resources of the software platform ([0033] [0039]). These are various examples in Fakhouri that teaches the platform orchestrator rolls out the upgrade according to the workload specifications and workload topologies.
Examiners Note
Applicant is further reminded of that the cited paragraphs and in the references as applied to the claims above for the convenience of the applicant(s) and although the specified citations are representative of the teachings of the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider all of the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Conclusion
Authorization for Internet Communication
Applicant is encouraged to submit an authorization to communicate with the Examiner via the internet by making the following statement (MPEP 502.03)
“Recognizing that internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only by submitted via Central Fax (not Examiner’s Fax), Regular postal mail, or EFS Web using PTO/SB/439.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU ZAR GHAFFARI whose telephone number is (571)270-3799. The examiner can normally be reached on Monday-Thursday 9:00 - 17:00 Hrs.
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, Aimee Lee can be reached on 571-272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ABU ZAR GHAFFARI/Primary Examiner, Art Unit 2195
Prosecution Insights