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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-4 and 6-22 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 1-4, 6, 7, 10, 12-14, 19, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hu (US 2020/0389352) and further in view of Nabi (US 2019/0034240) and further in view of Gao (US 11,886,905).
Regarding claim 1, Hu teaches: A method comprising:
identifying a plurality of compute nodes scheduled to undergo an upgrade process (¶ 30, “In operation 202, the application topology of multiple hosts to be upgraded is obtained or determined”), wherein at least two of the plurality of compute nodes are redundant nodes (¶ 17, “any number of instances of any given application may be executed by any given host”);
identifying an application executed by one or more of the plurality of compute nodes including identifying a plurality of applications (¶ 17, “Each host 102 (e.g., hosts 102a, 102b, 102c) executes one or more instances of each of one or more target applications 104 to be upgraded (e.g., application A 104a, application B 104b, application C 104c, application E 104e, application F 104f)”) and generating a mapping of each application of the plurality of applications to a specific subset of the plurality of compute nodes upon which the corresponding application is hosted (¶ 19, “Supervisor 120 may also store (or have access to) other useful data, such as identities (e.g., names, network addresses) of the hosts to be upgraded, profiles of the hosts (e.g., which applications are deployed on each host, how many instances of each application each host executes)”);
determining a minimum node availability budget for each of the plurality of applications (¶ 22, “identify the maximum number of instances of each application that can be offline at a time during an upgrade procedure”); and
complying with the minimum node availability budget for each of the plurality applications (¶ 24, “some or all hosts in computing environment 110, and/or other entities (e.g., other supervisors or monitors), may be polled to identify the total number of application instances (i.e., topology 122), and historical data may be consulted to determine a number or percentage of instances of each application that should remain online to satisfactorily handle an expected workload (e.g., with a desired quality of service). Semaphore limits 126 can then be calculated for each application by subtracting the number of instances to remain online from the total instances”).
Hu does not teach, however, Nabi teaches: generating a batch upgrade scheme for the plurality of upgrades (¶ 44, “The batch size for hosts (Z.sub.i) is calculated at each iteration (step 103)”);
wherein the batch upgrade scheme is based on the mapping of each of the plurality of applications with the corresponding specific subset of the plurality of compute nodes (¶ 35, “The calculation takes into account the placement constraints of the VMs, and that scaling requests may arrive concurrently with failure of some hosts during the upgrade”), and wherein the batch upgrade scheme upgrades the maximum quantity of the plurality of compute nodes in parallel (¶ 43, “To maximize the batch size, the system is consolidated in terms of the VMs in the old and new partitions (step 102)” and ¶ 40, “hosts in each batch are upgraded in parallel”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of generating a batch upgrade scheme for the plurality of upgrades; wherein the batch upgrade scheme is based on the mapping of each of the plurality of applications with the corresponding specific subset of the plurality of compute nodes, and wherein the batch upgrade scheme upgrades the maximum quantity of the plurality of compute nodes in parallel, as taught by Nabi, in the same way to the upgrade method, as taught by Hu. Both inventions are in the field of upgrading nodes, and combining them would have predictably resulted in a “rolling upgrade in a cloud computing environment,” as indicated by Nabi (¶ 1).
Hu and Nabi do not teach as clearly as Gao teaches: wherein the minimum node availability budget for the plurality of applications requires that at least one compute node for each of the plurality of applications be running and live at all times (col. 9:56-67 and col. 10:1-7, “a maximum shutdown quantity corresponding to a service group is a maximum quantity of virtual machines that are allowed to be shut down in the service group when the service of the service group keeps running” and “It is ensured that the total quantity of virtual machines that are deployed on the at least one target host and that are in each target service group is less than or equal to the maximum shutdown quantity corresponding to the corresponding target service group, so that it can be ensured that when the at least one target host is shut down to be upgraded, a virtual machine outside the at least one target host may still support running of a service to an extent, and shutting down the virtual machines on the at least one target host does not affect a service of the one or more target service groups”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of wherein the minimum node availability budget for the plurality of applications requires that at least one compute node for each of the plurality of applications be running and live at all times, as taught by Gao, in the same way to the node availability budget, as taught by Hu and Nabi. Both inventions are in the field of batch upgrading of compute nodes, and combining them would have predictably resulted in an upgrade method such that “it is ensured that a service of the virtual machines deployed on the at least one target host is not interrupted,” as indicated by Gao (col. 2:31-32).
Regarding claim 2, Hu teaches: The method of claim 1, wherein the upgrade process will render the plurality of compute nodes unavailable for a time period (¶ 40, “In operation 214, the selected host is taken offline and upgraded”).
Regarding claim 3, Hu teaches: The method of claim 1, wherein at least a portion of the plurality of applications is executed with redundancy (¶ 10, “a sufficient pool of other instances of the host's applications (e.g., instances that operate on other hosts) are online to handle the application's workload”) such that the portion of the plurality of applications is executed by two or more compute nodes simultaneously (¶ 17, “Each host 102 (e.g., hosts 102a, 102b, 102c) executes one or more instances of each of one or more target applications 104 to be upgraded”).
Regarding claim 4, Hu teaches: The method of claim 3, wherein one compute node of the plurality of compute nodes is configured to execute two or more of the plurality of applications (¶ 17, “The method of claim 3, wherein one compute node of the plurality of compute nodes is configured to execute two or more of the plurality of applications.”).
Regarding claim 6, Hu teaches: The method of claim 1, wherein generating the batch upgrade scheme to comply with the minimum node availability budget for the application comprises ensuring that fewer than all compute nodes running the application are upgraded simultaneously (¶ 48, “If each application's semaphore is greater than or equal to the number of instances of the application executing on the host, the candidate host can be taken offline and upgraded, and the illustrated method ends”) such that at least one compute node running the application is live at all times (¶ 24, “some or all hosts in computing environment 110, and/or other entities (e.g., other supervisors or monitors), may be polled to identify the total number of application instances (i.e., topology 122), and historical data may be consulted to determine a number or percentage of instances of each application that should remain online to satisfactorily handle an expected workload (e.g., with a desired quality of service)”).
Regarding claim 7, Nabi teaches: The method of claim 1, wherein generating the batch upgrade scheme further comprises optimizing the batch upgrade scheme to ensure that sufficient resources are available to continue operations during the upgrade process (¶ 29, “the upgrade process starts when the system has enough capacity for scaling, failure handling and upgrade. The upgrade continues as long as the capacity exists, while maximizing the number of resources upgraded in each iteration”).
Regarding claim 10, Nabi teaches: The method of claim 1, wherein the method is implemented in a containerized workload management platform (¶ 33, “VMs are referred to as the hosted entities in the examples below, VMs may be hosting entities for other resources such as containers, which in turn may be hosting entities themselves”).
Regarding claim 12, Nabi teaches: The method of claim 1, wherein the application comprises a plurality of applications, and wherein generating the batch upgrade scheme comprises ensuring that none of the plurality of applications become unavailable during the upgrade process (¶ 27, “To maintain the system availability during upgrades, cloud providers may perform rolling upgrades. With rolling upgrades, the system is upgraded in a number of batches”).
Regarding claim 13, Nabi teaches: The method of claim 1, wherein the batch upgrade scheme comprises a plurality of upgrade groups, wherein each of the plurality of upgrade groups comprises one or more compute nodes to be upgraded in parallel, and wherein the plurality of upgrade groups are upgraded serially (¶ 27, “The system is upgraded iteratively one batch at a time in a rolling fashion. In each iteration, a batch size number of hosts are taken out of service for upgrade and subsequently added back to the system.”).
Regarding claim 14, Hu teaches: The method of claim 1, wherein each of the plurality of compute nodes is associated with a cluster within a containerized workload management system (¶ 47, “the hosts may be upgraded according to their location, meaning that the supervisor may attempt to upgrade all hosts in one location (e.g., rack, cluster, data center) before tending to those in another location”).
Regarding claim 19, Nabi teaches: The method of claim 1, wherein the application is a cloud-based application and wherein the plurality of compute nodes are implemented within a cloud-native network platform (¶ 29, “A system and method for rolling upgrade of a cloud system is provided herein”).
Regarding claim 20, Nabi teaches: The method of claim 1, wherein each of the plurality of compute nodes comprises one or more pods (col. 11:65-67, “the measured upgrade phase selects a first set or sets of one or more nodes for upgrading that will minimize the startup of pods or containers on non-updated nodes”), and wherein generating the batch upgrade scheme comprises upgrading a plurality of pods in parallel (col. 2:56-57, “the optimal set may include a single node or a plurality of nodes for concurrent update”).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hu, Nabi, and Gao, as applied above, and further in view of Ranjan (US 2021/0279111).
Regarding claim 8, Hu, Nabi, and Gao do not teach; however, Ranjan discloses: the sufficient resources comprises: sufficient CPU (central processing unit) resources are available to continue operations (¶ 64, “the application may be tuned to lower CPU and/or RAM usage”); sufficient GPU (graphics processing unit) resources are available to continue operations (¶ 55, “the cluster is at or near capacity or one or more applications running on the host to be upgraded can only be run on a limited number of hosts in the cluster that have specialized hardware capabilities (e.g., GPU(s), NICs, large storage capacity, etc.) that are running at or near capacity”); sufficient RAM (random access memory) resources are available to continue operations (¶ 64, “the application may be tuned to lower CPU and/or RAM usage”); and sufficient disk storage resources are available to continue operations (¶ 55, “the cluster is at or near capacity or one or more applications running on the host to be upgraded can only be run on a limited number of hosts in the cluster that have specialized hardware capabilities (e.g., GPU(s), NICs, large storage capacity, etc.) that are running at or near capacity”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of the sufficient resources comprises: sufficient CPU (central processing unit) resources are available to continue operations; sufficient GPU (graphics processing unit) resources are available to continue operations; sufficient RAM (random access memory) resources are available to continue operations; and sufficient disk storage resources are available to continue operations, as taught by Ranjan, in the same way to the optimizing the batch upgrade scheme, as taught by Hu, Nabi, and Gao. Both inventions are in the field of upgrading cluster hosts while keeping hosted applications operable, and combining them would have predictably resulted in “maintaining operability of the application at issue,” as indicated by Ranjan (¶ 65).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hu, Nabi, and Gao, as applied above, and further in view of Allen (US 11,853,738).
Regarding claim 9, Sabath, Nabi, and Gao do not teach; however, Allen discloses: optimizing the batch upgrade scheme to ensure that sufficient data is available to execute the application during the upgrade process (col. 5:56-59, “With the NDU, the data storage system can continue to provide uninterrupted service and access to the data while the software is being upgraded to the next version across all appliances of the system”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of optimizing the batch upgrade scheme to ensure that sufficient data is available to execute the application during the upgrade process, as taught by Allen, in the same way to the optimizing the batch upgrade scheme, as taught by Hu, Nabi, and Gao. Both inventions are in the field of updating systems’ software, and combining them would have predictably resulted in “uninterrupted service and access to the data while the software is being upgraded,” as indicated by Allen (col. 5:56-59).
Claim(s) 11, 15, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hu, Nabi, and Gao, as applied above, and further in view of Beard (US 2021/0311763).
Regarding claim 11, Hu, Nabi, and Gao do not teach; however, Beard discloses: the containerized workload management platform comprises a Kubernetes® construct (¶ 37, “Supervisor cluster 101 integrates an orchestration control plane, such as Kubernetes, with host cluster 118”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of the containerized workload management platform comprises a Kubernetes® construct, as taught by Beard, in the same way to the optimizing the containerized workload management system, as taught by Hu, Nabi, and Gao. Both inventions are in the field of upgrading hosts that run containerized workloads, and combining them would have predictably resulted in “a platform for automating deployment, scaling, and operations of application containers across clusters of hosts,” as indicated by Beard (¶ 1).
Regarding claim 15, Hu, Nabi, and Gao do not teach; however, Beard discloses: a plurality of clusters, and wherein each of the plurality of clusters comprises: a control plane node comprising an API (application program interface) server in communication with all compute nodes mapped to the applicable cluster (¶ 57, “orchestration control plane 115 is extended to support orchestration of native VMs, VM images, and guest clusters”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of a plurality of clusters, and wherein each of the plurality of clusters comprises: a control plane node comprising an API (application program interface) server in communication with all compute nodes mapped to the applicable cluster, as taught by Beard, in the same way to the optimizing the containerized workload management system, as taught by Hu, Nabi, and Gao. Both inventions are in the field of updating systems’ software, and combining them would have predictably resulted in “an orchestration control plane managing the guest cluster,” as indicated by Beard (¶ 4).
Regarding claim 16, Beard discloses: generating the batch upgrade scheme comprises first upgrading the control plane node of each of the plurality of clusters prior to upgrading the plurality of compute nodes (¶ 89, “Supervisor cluster patch 1202 includes an upgrade of orchestration control plane 115, including orchestration control plane core 1002 and GCIS 405”).
Claim(s) 17 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hu, Nabi, and Gao, as applied above, and further in view of Gupta (US 2017/0192771).
Regarding claim 17, Hu, Nabi, and Gao do not teach; however, Gupta discloses: generating the batch upgrade scheme further comprises selecting an optimal date and time to execute the batch upgrade scheme (¶ 21, “The patching schedule generated in accordance with the present invention is characterized by maximization, subject to one or more constraints, of an objective function” and ¶ 22, “FIG. 1 illustrates scheduling of patching virtual machines of redundancy groups into time windows, in accordance with embodiments of the present invention”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of generating the batch upgrade scheme further comprises selecting an optimal date and time to execute the batch upgrade scheme, as taught by Gupta, in the same way to the method of claim 1, as taught by Hu, Nabi, and Gao. Both inventions are in the field of updating systems’ software, and combining them would have predictably resulted in “scheduling patches and in particular, to scheduling patches, in sequential time windows, applicable to virtual machines within redundancy groups,” as indicated by Gupta (¶ 1).
Regarding claim 18, Gupta discloses: The method of claim 17, wherein selecting the optimal date and time to execute the batch upgrade scheme comprises selecting based on time-based usage history for the application (¶ 76, “Data obtained from a historical database 36 (e.g., VM failure probability, request arrival rates to components, etc.) is provided to the Patch Optimization Problem Generator 37”).
Claim(s) 21 and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hu, Nabi, and Gao, as applied above, and further in view of Xu (US 2020/0218453).
Regarding claim 21, Hu, Nabi, and Gao do not teach; however, Xu discloses: calculating the maximum quantity of the plurality of compute nodes for a concurrent upgrade batch (¶ 59, “obtaining the maximum quantity of nodes that are allowed to be upgraded simultaneously in each group” and ¶ 58, “grouping a plurality of nodes into at least one batch”) by identifying a set of nodes of the plurality of compute nodes whose simultaneous unavailability represents a largest possible batch that does not reduce a number of operational nodes for any individual application of the plurality of applications below its respective minimum node availability budget (¶ 48, “The constraint condition includes a maximum quantity of nodes that are allowed to be upgraded simultaneously in each group. A purpose of setting the constraint condition is to avoid a great impact on service execution or system performance caused by the parallel upgrade”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of calculating the maximum quantity of the plurality of compute nodes for a concurrent upgrade batch by identifying a set of nodes of the plurality of compute nodes whose simultaneous unavailability represents a largest possible batch that does not reduce a number of operational nodes for any individual application of the plurality of applications below its respective minimum node availability budget, as taught by Xu, in the same way to generating the batch upgrade scheme, as taught by Hu, Nabi, and Gao. Both inventions are in the field of parallel upgrade of clustered compute nodes, and combining them would have predictably resulted in “a shorter time consumed for the upgrade,” as indicated by Xu (¶ 60).
Regarding claim 22, Hu, Nabi, and Gao do not teach; however, Xu discloses: the batch upgrade scheme optimizes upgrade velocity (¶ 60, “fewer upgrade batches indicate a shorter time consumed for the upgrade”) by maximizing a number of nodes in each upgrade batch to a highest integer value that satisfies an intersection of the minimum node availability budgets for each of the plurality of applications hosted across the plurality of compute nodes (¶ 58, “grouping a plurality of nodes into at least one batch, where all nodes in each batch meet each constraint condition” and ¶ 48, “The constraint condition includes a maximum quantity of nodes that are allowed to be upgraded simultaneously in each group. A purpose of setting the constraint condition is to avoid a great impact on service execution or system performance caused by the parallel upgrade”).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to have applied the known technique of the batch upgrade scheme optimizes upgrade velocity by maximizing a number of nodes in each upgrade batch to a highest integer value that satisfies an intersection of the minimum node availability budgets for each of the plurality of applications hosted across the plurality of compute nodes, as taught by Xu, in the same way to the batch upgrade scheme, as taught by Hu, Nabi, and Gao. Both inventions are in the field of parallel upgrade of clustered compute nodes, and combining them would have predictably resulted in “a shorter time consumed for the upgrade,” as indicated by Xu (¶ 60).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-5:00.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/JACOB D DASCOMB/Primary Examiner, Art Unit 2198
Prosecution Insights