Prosecution Insights
Last updated: April 19, 2026
Application No. 18/471,104

UPGRADING SOFTWARE RUNNING IN HOSTS OF A VIRTUAL COMPUTING INFRASTRUCTURE

Non-Final OA §101§103§112
Filed
Sep 20, 2023
Examiner
LEE, ADAM
Art Unit
2198
Tech Center
2100 — Computer Architecture & Software
Assignee
VMware, Inc.
OA Round
1 (Non-Final)
85%
Grant Probability
Favorable
1-2
OA Rounds
3y 2m
To Grant
99%
With Interview

Examiner Intelligence

Grants 85% — above average
85%
Career Allow Rate
575 granted / 680 resolved
+29.6% vs TC avg
Strong +59% interview lift
Without
With
+58.9%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
41 currently pending
Career history
721
Total Applications
across all art units

Statute-Specific Performance

§101
24.8%
-15.2% vs TC avg
§103
40.1%
+0.1% vs TC avg
§102
14.4%
-25.6% vs TC avg
§112
15.0%
-25.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 680 resolved cases

Office Action

§101 §103 §112
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 . DETAILED ACTION Claims 1-20 are pending. Examiner Notes Examiner cites particular paragraphs and/or columns and lines in the references as applied to Applicant’s claims for the convenience of the Applicant. Although the specified citations are representative of the teachings in 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 that, in preparing responses, the Applicant fully consider 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. The prompt development of a clear issue requires that the replies of the Applicant meet the objections to and rejections of the claims. Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. Authorization for Internet Communications in a Patent Application Applicant is encouraged to file an Authorization for Internet Communications in a Patent Application form (http://www.uspto.gov/sites/default/files/documents/sb0439.pdf) along with the response to this office action to facilitate and expedite future communication between Applicant and the examiner. If the form is submitted then Applicant is requested to provide a contact email address in the signature block at the conclusion of the official reply. Abstract Objection The abstract of the disclosure is objected to because it duplicates the claim language. This is problematic because as the claims are amended over the prosecution history of the application, the original language of the abstract would no longer accurately reflect the claimed invention. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b). Applicant is reminded of the proper content of an abstract of the disclosure. A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art. If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives. Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps. Extensive mechanical and design details of an apparatus should not be included in the abstract. The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length. See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts. Applicant is reminded of the proper language and format for an abstract of the disclosure. The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details. The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more. Step 1: The claim is a process, machine, manufacture, or composition of matter: Claim 1. A method of upgrading a cluster of hosts that are running workloads, at least one of which is designated as critical, said method comprising. Step 2A Prong One: The claim recites an abstract idea because it includes limitations that can be considered mental processes (concepts performed in the human mind including an observation, evaluation, judgment, and/or opinion). If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind or via pen and paper, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea: (b) selecting one of the hosts for upgrade (abstract idea mental process); (c) determining whether any of the workloads running in the selected host are designated as critical (abstract idea mental process). Step 2A Prong Two: The abstract idea is not integrated into a practical application because the abstract idea is recited but for generically recited additional computer elements (i.e. data storage, processor, memory, computer readable medium, etc.) which do not add meaningful limitations to the abstract idea amounting to simply implementing the abstract idea on a generic computer using generic computing hardware and/or software (e.g. generally linking the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The generic computing components are recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception using the recited generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea: (a) adding a host that has been upgraded to the cluster of hosts (generic computing components performing extra-solution activity of modifying/updating data/information); (d) migrating all of the workloads from the selected host that are designated as critical to the added host (generic computing components performing extra-solution activity of migrating/transferring/sending/transmitting data/information); and (e) migrating each of the workloads from the selected host that are not designated as critical to a selected one of the hosts of the cluster (generic computing components performing extra-solution activity of migrating/transferring/sending/transmitting data/information). Step 2B: The claim includes limitations which can be considered extra-solution activity (see MPEP 2106.05(g)) insufficient to amount to significantly more than the abstract idea because the additional limitations only perform at least one of collecting, gathering, displaying, generating, modifying, updating, storing, retrieving, sending, and receiving data/information data which are well-understood, routine, conventional computer functions as recognized by the court decisions listed in MPEP § 2106.05(d)II. The claim further includes limitations that do not integrate the judicial exception into a practical application because they merely recite the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f). Therefore, the claim, and its limitations when considered separately and in combination, is directed to patent ineligible subject matter: (a) adding a host that has been upgraded to the cluster of hosts (extra-solution activity of modifying/updating data/information); (d) migrating all of the workloads from the selected host that are designated as critical to the added host (extra-solution activity of migrating/transferring/sending/transmitting data/information); and (e) migrating each of the workloads from the selected host that are not designated as critical to a selected one of the hosts of the cluster (extra-solution activity of migrating/transferring/sending/transmitting data/information). Claim 2. The method of claim 1, further comprising: upgrading the selected host (extra-solution activity of modifying/updating data/information); selecting another one of the hosts for upgrade (abstract idea mental process); determining whether any of the workloads running in the selected another host are designated as critical (abstract idea mental process); migrating each of the workloads from the selected another host that are designated as critical to a selected one of the hosts of the cluster that have been upgraded (extra-solution activity of migrating/transferring/sending/transmitting data/information); and migrating each of the workloads from the selected another host that are not designated as critical to a selected one of the hosts of the hosts (extra-solution activity of migrating/transferring/sending/transmitting data/information). Claim 3. The method of claim 1, further comprising: determining that one of the workloads to be migrated from the selected another host is a workload of an active-passive pair (abstract idea mental process), wherein when migrating the workload of the active-passive pair from the selected another host, the selection of one of the hosts as a migration destination is made from a group of hosts that exclude the host in which the other workload of the active-passive pair is running (abstract idea mental process). Claim 4. The method of claim 1, wherein when migrating each of the workloads from the selected another host that are designated as critical, the selection of one of the hosts that have been upgraded as a migration destination is made to achieve load balancing across the hosts that have been upgraded (abstract idea mental process). Claim 5. The method of claim 4, wherein when migrating each of the workloads from the selected another host that are not designated as critical, the selection of one of the hosts of the cluster as a migration destination is made to achieve load balancing across all of the hosts of the cluster (abstract idea mental process). Claim 6. The method of claim 1, further comprising: notifying each of the workloads running in the selected host that are designated as critical to prepare for migration before the host that has been upgraded is added to the cluster (extra-solution activity of sending/receiving data/information). Claim 7. The method of claim 1, wherein the hosts of the cluster include first hosts located in a first availability zone and second hosts located in a second availability zone (generic computing components), and steps (a)-(e) are carried out concurrently in each of the first and second availability zones (extra-solution activity of merely reciting the words "apply it" or an equivalent with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using the computer as a tool to perform the abstract idea). Claim 8. The method of claim 7, further comprising: determining that virtual machines executing a clustered application are running in the first and second hosts (abstract idea mental process), wherein in step (b) carried out in the second availability zone, one of the second hosts is selected for upgrade depending on which one of the first hosts is selected for upgrade in step (b) carried out in the first availability zone (abstract idea mental process). Claim 9. The method of claim 8, wherein the second host selected for upgrade does not have any of the virtual machines executing the clustered application running therein if the first host selected for upgrade has one of the virtual machines executing the clustered application running therein (abstract idea mental process). As per claim 10, it has similar limitations as claim 1 and is therefore rejected using the same rationale. As per claim 11, it has similar limitations as claim 2 and is therefore rejected using the same rationale. As per claim 12, it has similar limitations as claim 3 and is therefore rejected using the same rationale. As per claim 13, it has similar limitations as claim 4 and is therefore rejected using the same rationale. As per claim 14, it has similar limitations as claim 5 and is therefore rejected using the same rationale. As per claim 15, it has similar limitations as claim 6 and is therefore rejected using the same rationale. As per claim 16, it has similar limitations as claim 7 and is therefore rejected using the same rationale. As per claim 17, it has similar limitations as claim 8 and is therefore rejected using the same rationale. As per claim 18, it has similar limitations as claim 9 and is therefore rejected using the same rationale. As per claim 19, it has similar limitations as claim 1 and is therefore rejected using the same rationale. As per claim 20, it has similar limitations as claim 6 and is therefore rejected using the same rationale. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. Claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor regards as the invention. As per claim 1, step (b) recites “selecting one of the hosts for upgrade” and it is not clear as to why it would be possible to select the host that has already been upgraded and added to the cluster to be selected again for upgrade. Is the other host in the cluster (i.e., the one that was originally in the cluster and not the one that was added) upgraded? Or is the newly added host that has been upgraded then upgraded again? Furthermore, ll. 10 in step (e) recites “a selected one of the hosts of the cluster” and there is further confusion as to which host is being selected. For the purposes of examination, it is interpreted that any of the hosts can be selected. Clarification and correction is required. As per claim 2, ll. 2 recites “the selected host” while ll. 3 recites “selecting another one of the hosts” and it is unclear as to which host is being selected. Moreover, ll. 6-9 recite “the selected another host” and “a selected one of the hosts” multiple times, and there is further confusion as to which host is being selected. For the purposes of examination, it is interpreted that any of the hosts can be selected. Clarification and correction is required. As per claim 3, ll. 4-6 recite “the selected another host” and “the selection of one of the hosts” and “exclude the host”, and there is further confusion as to which host is being selected. For the purposes of examination, it is interpreted that any of the hosts can be selected. Clarification and correction is required. As per claim 4, ll. 2-3 recite “the selected another host” and “the selection of one of the hosts”, and there is further confusion as to which host is being selected. For the purposes of examination, it is interpreted that any of the hosts can be selected. Clarification and correction is required. As per claim 5, ll. 2-3 recite “the selected another host” and “the selection of one of the hosts” and “exclude the host”, and there is further confusion as to which host is being selected. For the purposes of examination, it is interpreted that any of the hosts can be selected. Clarification and correction is required. As per claim 6, ll. 2 recites “the selected host”, and there is further confusion as to which host is being selected. For the purposes of examination, it is interpreted that any of the hosts can be selected. Clarification and correction is required. As per claim 10, it has similar limitations as claim 1 and is therefore rejected using the same rationale. As per claim 11, it has similar limitations as claim 2 and is therefore rejected using the same rationale. As per claim 12, it has similar limitations as claim 3 and is therefore rejected using the same rationale. As per claim 13, it has similar limitations as claim 4 and is therefore rejected using the same rationale. As per claim 14, it has similar limitations as claim 5 and is therefore rejected using the same rationale. As per claim 15, it has similar limitations as claim 6 and is therefore rejected using the same rationale. As per claim 19, it has similar limitations as claim 1 and is therefore rejected using the same rationale. As per claim 20, it has similar limitations as claim 6 and is therefore rejected using the same rationale. 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, 4-5, 10-11, 13-14, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Rosenberg (US 2021/0026707) in view of Venkataraja et al. (US 2010/0313063) (hereinafter Venkataraja). As per claim 1, Rosenberg primarily teaches the invention as claimed including a method of upgrading a cluster of hosts that are running workloads ([0012] upgrading hardware devices on the host physical machine; abstract processes executing on the plurality of the other hosts), at least one of which is designated as critical ([0082] priority information may include an indicator specifying the priority of the first process corresponding to first process data, such as “mission critical,” “high,” “medium,” “low,” or none), said method comprising: (b) selecting one of the hosts (abstract selecting a host of a plurality of hosts); (c) determining whether any of the workloads running in the selected host are designated as critical ([0018] migration score or priority is the criticality of a process, which may be measured using a criticality score. For example, processes identified as mission critical may be prioritized, followed by those identified as high priority, medium priority, low priority, and so forth. Accordingly, higher priority processes may receive better criticality scores than lower priority processes); (d) migrating all of the workloads from the selected host that are designated as critical to the added host ([0020] the migration of processes from a source host to an eligible target host that is in the same host location as the source host may be prioritized over a similar migration to target hosts in a different host location. Other parameters and scoring systems may be used to determine an overall migration score. In some examples, the best migration score has the highest migration priority); and (e) migrating each of the workloads from the selected host that are not designated as critical to a selected one of the hosts of the cluster ([0018] higher priority processes may receive better criticality scores than lower priority processes. A better score is a score that makes a process more likely for a process to be migrated). Rosenberg does not explicitly teach: (a) adding a host that has been upgraded to the cluster of hosts; (b) selecting one of the hosts for upgrade. However, Venkataraja teaches: (a) adding a host that has been upgraded to the cluster of hosts ([0054] a set of upgraded nodes are added to the cluster); (b) selecting one of the hosts for upgrade ([0088] user selections and [0069] the identification of the specific nodes to be removed may be identified based on whether the nodes are processing user requests by the software sought to be upgraded and [0045] scheduler may be required to identify a specific set of nodes to be upgraded and to perform the upgrade of the software application on the identified set of nodes). Venkataraja and Rosenberg are both concerned with server/node management in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rosenberg in view of Venkataraja because it would provide for mitigating a reduction in availability level during maintenance of the nodes in a cluster. Due to the availability level at each time instance, a cluster at a secondary site can be ready to take over the operation of the cluster at the primary site in the event of a disaster. As per claim 2, the combination of references above teaches the method of claim 1, further comprising: upgrading the selected host (Venkataraja [0045] scheduler may be required to identify a specific set of nodes to be upgraded and to perform the upgrade of the software application on the identified set of nodes); selecting another one of the hosts for upgrade (Venkataraja [0088] user selections and [0069] the identification of the specific nodes to be removed may be identified based on whether the nodes are processing user requests by the software sought to be upgraded and [0045] scheduler may be required to identify a specific set of nodes to be upgraded and to perform the upgrade of the software application on the identified set of nodes); determining whether any of the workloads running in the selected another host are designated as critical (Rosenberg [0082] priority information may include an indicator specifying the priority of the first process corresponding to first process data, such as “mission critical,” “high,” “medium,” “low,” or none); migrating each of the workloads from the selected another host that are designated as critical to a selected one of the hosts of the cluster that have been upgraded (Rosenberg [0012] migration may also be used when upgrading hardware devices on the host physical machine, so that guest processes e.g., virtual machines may be safely relocated to other host physical machines. This means that the guest processes e.g., virtual machines do not experience any downtime for hardware improvements and [0020] the migration of processes from a source host to an eligible target host that is in the same host location as the source host may be prioritized over a similar migration to target hosts in a different host location. Other parameters and scoring systems may be used to determine an overall migration score. In some examples, the best migration score has the highest migration priority); and migrating each of the workloads from the selected another host that are not designated as critical to a selected one of the hosts of the hosts (Rosenberg [0018] higher priority processes may receive better criticality scores than lower priority processes. A better score is a score that makes a process more likely for a process to be migrated). As per claim 4, Venkataraja teaches wherein when migrating each of the workloads from the selected another host that are designated as critical, the selection of one of the hosts that have been upgraded as a migration destination is made to achieve load balancing across the hosts that have been upgraded ([0054] a set of upgraded nodes are added to the cluster and [0069] the identification of the specific nodes to be scaled-out/in may be identified based on the load balancing performed on the different software instances). As per claim 5, Rosenberg further teaches wherein when migrating each of the workloads from the selected another host that are not designated as critical, the selection of one of the hosts of the cluster as a migration destination is made to achieve load balancing across all of the hosts of the cluster ([0012] migration may be used for load balancing. In load balancing, guest processes e.g., virtual machines are moved to host physical machines with lower usage when their host physical machine becomes overloaded, or another host physical machine that is under-utilized). As per claim 10, it has similar limitations as claim 1 and is therefore rejected using the same rationale. As per claim 11, it has similar limitations as claim 2 and is therefore rejected using the same rationale. As per claim 13, it has similar limitations as claim 4 and is therefore rejected using the same rationale. As per claim 14, it has similar limitations as claim 5 and is therefore rejected using the same rationale. As per claim 19, it has similar limitations as claim 1 and is therefore rejected using the same rationale. Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Rosenberg in view of Venkataraja in view of Nutter et al. (US 2017/0046247) (hereinafter Nutter). As per claim 3, Rosenberg in view of Venkataraja do not explicitly teach determining that one of the workloads to be migrated from the selected another host is a workload of an active-passive pair, wherein when migrating the workload of the active-passive pair from the selected another host, the selection of one of the hosts as a migration destination is made from a group of hosts that exclude the host in which the other workload of the active-passive pair is running. However, Nutter teaches determining that one of the workloads to be migrated from the selected another host is a workload of an active-passive pair, wherein when migrating the workload of the active-passive pair from the selected another host, the selection of one of the hosts as a migration destination is made from a group of hosts that exclude the host in which the other workload of the active-passive pair is running ([0054] in an active-passive data center pairing, the resiliency component workloads can be moved from one data center to a standby data center, bringing the standby data center into a live production state for the tested resiliency component and full production workloads can continue to operate when a resiliency component, and the dependent resiliency components, are shifted from a primary or home hosting location to the alternate hosting location, such that a normal business routine can continue without being interrupted by the testing). Nutter and Rosenberg are both concerned with server/node management in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rosenberg in view of Venkataraja in view of Nutter because it would provide a robust test of applications so that application managers will have a higher level of confidence in their resiliency plan because the application managers will know that their applications are capable of maintaining their appropriate level of operation while in backup mode. This increased confidence for the application managers will help ensure that application managers will be more inclined to switch to the resiliency plan upon a notification that the original host location of the application may be significantly affected, thus protecting the application and the system as a whole from potential issues. Breaking the applications up into resiliency components not only improves the resiliency testing of the applications, but also improves on the processing speeds in running the applications because the locations at which the resiliency components may be stored can be changed in order to increase or decrease processing speeds and times based on functionality of the resiliency components. As per claim 12, it has similar limitations as claim 3 and is therefore rejected using the same rationale. Claims 6, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rosenberg in view of Venkataraja in view of Dugar et al. (US 10,657,154) (hereinafter Dugar). As per claim 6, Rosenberg in view of Venkataraja do not explicitly teach notifying each of the workloads running in the selected host that are designated as critical to prepare for migration before the host that has been upgraded is added to the cluster. However, Dugar teaches notifying each of the workloads running in the selected host that are designated as critical to prepare for migration before the host that has been upgraded is added to the cluster (col. 13, ll. 1-21 a migration event that triggers the migration of a partition from a first node to a second node may be detected or triggered by a user or other manual request which may specify a scale operation for a cluster of nodes e.g., to increase or decrease the number of nodes. The request may specify which partition to move to which node, or the partition to move may be automatically selected by a control or other migration management component. For example, partition load e.g., number of access requests to a partition may be considered so as to balance the workload for access requests amongst nodes. Migration events may be triggered as part of automated scaling techniques or workload balancing techniques that may migrate partitions in order to increase the capacity of a cluster to process requests or store data, or to safeguard or increase access request processing performance by balancing the workload automatically amongst nodes in cluster). Dugar and Rosenberg are both concerned with server/node management in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rosenberg in view of Venkataraja in view of Dugar because it would provide a way to adapt a distributed system to changing conditions by migration operations to move partitions from one location, such as a source node currently hosting the partition, to another location, a target node to host the partition. Techniques that provide access to data of a partition while the partition is being migrated can reduce or eliminate the delay that may be experienced by users or other clients that access the partition as part of accessing the data set in the distributed system. As per claim 15, it has similar limitations as claim 6 and is therefore rejected using the same rationale. As per claim 20, it has similar limitations as claim 6 and is therefore rejected using the same rationale. Claims 7-8 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Rosenberg in view of Venkataraja in view of Mritunjai et al. (US 11,809,404) (hereinafter Mritunjai). As per claim 7, Rosenberg in view of Venkataraja do not explicitly teach wherein the hosts of the cluster include first hosts located in a first availability zone and second hosts located in a second availability zone, and steps (a)-(e) are carried out concurrently in each of the first and second availability zones. However, Mritunjai teaches wherein the hosts of the cluster include first hosts located in a first availability zone and second hosts located in a second availability zone (fig. 1 storage nodes in different availability zones), and steps (a)-(e) are carried out concurrently in each of the first and second availability zones (col. 10, ll. 11-32 storage node concurrently replicates the zonal log entry to the leader storage node for the partition, which resolves the write operation in accordance with timestamped-based replication rules e.g., to resolve potential conflicts related to concurrent writes to a storage node. Once the write operation is accepted or rejected by the leader storage node, the leader storage node replicates the write operation among the storage nodes using its standard consensus-based replication protocol). Mritunjai and Rosenberg are both concerned with server/node management in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rosenberg in view of Venkataraja in view of Mritunjai because it would provide the use of zonally consistent database operations enables users to optimize performance of applications accessing a database table having a replicated copy within a same availability zone by avoiding cross-availability zone latency often associated with consistent and eventually consistent operations. The ability for a database service to provide a zonally consistent model can be implemented using an existing replication model provided by a database service, e.g., without requiring additional replicated copies of a database's partitions. As per claim 8, Mritunjai teaches determining that virtual machines (col. 5, ll. 18-38 virtual machines / compute instances) executing a clustered application are running in the first and second hosts (col. 6, ll. 1-19 clustered applications running in different availability zones), wherein in step (b) carried out in the second availability zone, one of the second hosts is selected for upgrade depending on which one of the first hosts is selected for upgrade in step (b) carried out in the first availability zone (col. 2, ll. 49-63 a key-value and document database service provides databases to users using a partitioned database architecture. A partition is an allocation of storage for a table, backed by a physical storage device and automatically replicated across multiple availability zones within a region of the cloud provider network. The consistency among replicas within a region during updates is maintained using quorum-based techniques and decentralized replica synchronization e.g., using Paxos or other consensus algorithms, where one storage node of a plurality of storage nodes storing a given partition is elected as the “leader” storage node at any given time and is definitionally up-to-date in terms of updates to the partition). As per claim 16, it has similar limitations as claim 7 and is therefore rejected using the same rationale. As per claim 17, it has similar limitations as claim 8 and is therefore rejected using the same rationale. Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Rosenberg in view of Venkataraja in view of Mritunjai in view of Adogla et al. (US 8,615,589) (hereinafter Adogla). As per claim 9, Rosenberg in view of Venkataraja in view of Mritunjai do not explicitly teach wherein the second host selected for upgrade does not have any of the virtual machines executing the clustered application running therein if the first host selected for upgrade has one of the virtual machines executing the clustered application running therein. However, Adogla teaches wherein the second host selected for upgrade does not have any of the virtual machines executing the clustered application running therein if the first host selected for upgrade has one of the virtual machines executing the clustered application running therein (col. 9, ll. 10-32 resource optimization manager (a) provides resource optimizations/recommendations for the target application by defining minimum or maximum virtual resources e.g., allocated memory, CPUs, etc. for the target application based on the minimum or maximums shared by the clustered applications, (b) publishes the resource optimizations/recommendations to the requesting client computing device or to a system administrator associated with the target application, (c) updates the clustered application to include the target application for future processing of new target applications, and (d) implements at least a portion of the resource optimizations in the target application by causing a new instance of a virtual machine incorporating at least a portion of the resource optimizations and causing the target application to be migrated to the newly instantiated virtual machine instance). Adogla and Rosenberg are both concerned with server/node management in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rosenberg in view of Venkataraja in view of Mritunjai in view of Adogla because it would provide for a resource optimization manager component which may define minimum, maximum, optimal, preferred, or prohibited or non-recommended resource values e.g., allocated memory, CPUs, etc. for a target application based on corresponding values or configurations shared by the clustered applications. The resource optimization manager component can generate the clustered set of applications, and store or otherwise associate other resource optimizations that facilitate the execution of the application in the instantiated instances of the virtual machine instance type. For example, the resource optimization may determine the selection of a particular operating environment, selection of available virtualized resources, and minimum physical resources for the environment. As per claim 18, it has similar limitations as claim 9 and is therefore rejected using the same rationale. Citation of Relevant Prior Art The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure: Wiggers et al. (US 2020/0042340) disclose migrating virtual machines between hosts. Szabo et al. (US 2010/0042869) disclose upgrading clusters. Ranjan et al. (US 2021/0279111) disclose upgrading hosts within an upgrade window. Panse et al. (US 2020/0201664) disclose upgrading hosts in a fault tolerant hyper-converged infrastructure environment. Olderdissen et al. (US 2020/0150946) disclose dynamic expansion of a cluster with co-nodes before an upgrade. Kapur et al. (US 2020/0104161) disclose migrating workloads in multi-cloud computing environments. Gao et al. (US 2021/0216353) disclose selecting a target host from a plurality of hosts for an upgrade. Dias et al. (US 2006/0130042) disclose software upgrades in nodes of a cluster. Chaliparambil et al. (US 2015/0188989) disclose migrating services between nodes. Blagodurov et al. (US 2014/0040474) disclose migrating running workloads between servers. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Adam Lee whose telephone number is (571) 270-3369. The examiner can normally be reached on M-TH 8AM-5PM. If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, Pierre Vital, can be reached at the following telephone number: (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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form. /Adam Lee/Primary Examiner, Art Unit 2198 February 9, 2026
Read full office action

Prosecution Timeline

Sep 20, 2023
Application Filed
Feb 06, 2026
Non-Final Rejection — §101, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12585502
VIRTUAL MACHINE MANAGEMENT IN DATA CENTERS
2y 5m to grant Granted Mar 24, 2026
Patent 12579007
CLUSTER COMPUTING SYSTEM AND OPERATING METHOD THEREOF
2y 5m to grant Granted Mar 17, 2026
Patent 12579002
PROACTIVE ADAPTATION IN HANDLING SERVICE REQUESTS IN CLOUD COMPUTING SYSTEMS
2y 5m to grant Granted Mar 17, 2026
Patent 12572826
ASYNCHRONOUS RULE COMPILATION IN A MULTI-TENANT ENVIRONMENT
2y 5m to grant Granted Mar 10, 2026
Patent 12566636
USING DEPLOYMENT PRIORITIES TO IMPLEMENT QOS FOR SERVICE CAPACITY REQUESTS IN MULTI-TENANT CLUSTERS
2y 5m to grant Granted Mar 03, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
85%
Grant Probability
99%
With Interview (+58.9%)
3y 2m
Median Time to Grant
Low
PTA Risk
Based on 680 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month