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
This action is in response to the preliminary amendment filed on 07/05/2024.
Claims 1-18 are amended by the applicants.
Claims 19-20 are added by the applicants.
Claims 1-20 are pending.
Examiner’s Note
Please note that Examiner cites particular columns and line numbers in the references as applied to the claims below 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 entirely 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.
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 non-statutory subject matter.
Claim 1, this claim is within at least one of the four categories of patent eligible subject matter as it is directing to a method claim under Step 1.
1. (Currently Amended) A method, comprising:
receiving, from a client, an upgrade request message comprising a first identifier of a service cluster and a second identifier of a target version;
obtaining a version baseline of the service cluster based on the first identifier;
adding a first node to the service cluster in a scale-out;
determining, based on the version baseline, a first software version running on the first node; and
upgrading, when the first software version is different from the target version, the first node to an upgraded first node such that a second software version running on the upgraded first node is the target version.
Regarding claim 1, the limitations “determining, based on the version baseline, a first software version running” as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. For example, a person is capable of finding based on the received request with the aid of pen and paper to look up in a table or map with the request to find the current version running. Therefore, these limitations encompass a human mind carrying out the function through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, the additional elements “a client,” “first node” and “upgrading, when the first software version is different from the target version, the first node to an upgraded first node such that a second software version running on the upgraded first node is the target version” is recited at a high-level of generality such that it amounts no more than mere instructions for executing/running software tool which merely using generic computing equipment to apply/execute/run the software tool to perform the abstract idea. See MPEP 2106.05(f). For the additional elements “receiving, from a client, an upgrade request message comprising a first identifier of a service cluster and a second identifier of a target version; obtaining a version baseline of the service cluster based on the first identifier; adding a first node to the service cluster in a scale-out” do nothing more than to add insignificant extra solution activity to the judicial exception of merely storing/gathering data for automation. See MPEP § 2106.05(h).
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “a client,” “first node” and “upgrading, when the first software version is different from the target version, the first node to an upgraded first node such that a second software version running on the upgraded first node is the target version” amount to no more than mere instructions, or generic computer and/or computer components to carry out the judicial exception, thus, cannot amount to an inventive concept. See MPEP 2105.06(f). For the additional elements “registering the identified model in a central registry for use by data scientists” and “automating the regular scoring and monitoring of the model” the courts have recognized storing and retrieving information in memory as a well‐understood, routine, and conventional functions in a merely generic manner (e.g., at a high level of generality) or an insignificant extra-solution activity (Berkheimer v. HP, Inc., 881 F.3d 1360, 1368, 125 USPQ2d 1649, 1654 (Fed. Cir. 2018)), See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 USC 101.
2. (Currently Amended) The method of claim 1, wherein upgrading the first node comprises: creating the upgraded first node; and switching traffic on the first node to the upgraded first node.
The limitations, creating the upgraded [first node], for this claim further recite an additional mental process under Step 2A, Prong 1. For the limitations, switching traffic on the first node to the upgraded [first node], are an additional insignificant extra solution activity under step 2A, Prong 2.
3. (Currently Amended) The method of claim 1, wherein after receiving the upgrade request message the method further comprises: upgrading a second node in the service cluster to an upgraded second node such that a third software version running on the upgraded second node is the target version, and wherein the second node is in the service cluster before the scale-out.
The limitations, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2.
4. (Currently Amended) The method of claim 2, wherein when a node upgrade rate of the service cluster has reached a preset indicator, the method further comprises updating the version baseline to indicate that a third software version running on a second node added to the service cluster in the scale-out is the target version.
The limitations, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2.
5. (Currently Amended) The method of claim wherein the upgrade request message further comprises an upgrade manner, wherein the upgrade manner indicates to upgrade nodes in the service cluster in batches, and wherein the nodes comprise the first node and the second node.
The limitations for this claim further recite an additional insignificant extra solution activity under step 2A, Prong 2.
6. (Currently Amended) The method of claim 4, wherein before updating the version baseline, the method further comprises completing gray verification of software on an upgraded second node in at least one batch.
The limitations for this claim further recite an additional mental process under Step 2A, Prong 1.
7. (Currently Amended) The method of claim 1, wherein after upgrading the first node, the method further comprises: receiving, from the client, a rollback request message comprising the first identifier and a third identifier of a historical version running on the first node during the scale-out; and rolling back the upgraded first node to the first node such that a third software version running on the first node is the historical version.
The limitations, client and first node, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2. For the limitations, receiving,…, a rollback request message comprising the first identifier and a third identifier of a historical version running … during the scale-out; and rolling back the upgraded … to … such that a third software version running on… is the historical version are an additional insignificant extra solution activity under step 2A, Prong 2.
8. (Currently Amended) The method of claim 7, further comprising switching traffic on the upgraded first node to the first node.
The limitations, node, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2. For the limitations, switching traffic on the upgraded are an additional insignificant extra solution activity under step 2A, Prong 2.
9. (Currently Amended) The method of claim 4, further comprising obtaining, from a user, the preset indicator.
The limitations, from a user, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2. For the limitations, obtaining,…, the preset indicator are an additional insignificant extra solution activity under step 2A, Prong 2.
Claim 10, this claim is within at least one of the four categories of patent eligible subject matter as it is directing to a device claim under Step 1.
10. (Currently Amended) A version upgrade device comprising:
a memory configured to store instructions; and
at least one processor coupled to the memory and configured to execute the instructions to cause the version upgrade device to:
receive, from a client, an upgrade request message comprising a first identifier of a service cluster an and a second identifier of a target version;
obtain a version baseline of the service cluster based on the first identifier;
add a first node to the service cluster in a scale-out;
determine, based on the version baseline, a first software version running on the first node; and
upgrade, when the first software version is different from the target version, the first node to an upgraded first node such that a second software version running on the upgraded first node is the target version.
Regarding claim 10, the limitations “determining, based on the version baseline, a first software version running” as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. For example, a person is capable of finding based on the received request with the aid of pen and paper to look up in a table or map with the request to find the current version running. Therefore, these limitations encompass a human mind carrying out the function through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, the additional elements “version upgrade device comprising: a memory configured to store instructions; and at least one processor coupled to the memory and configured to execute the instructions to cause the version upgrade device to,” “a client,” “first node” and “upgrade, when the first software version is different from the target version, the first node to an upgraded first node such that a second software version running on the upgraded first node is the target version” is recited at a high-level of generality such that it amounts no more than mere instructions for executing/running software tool which merely using generic computing equipment to apply/execute/run the software tool to perform the abstract idea. See MPEP 2106.05(f). For the additional elements “receive,…, an upgrade request message comprising a first identifier of a service cluster an and a second identifier of a target version; obtain a version baseline of the service cluster based on the first identifier; add… to the service cluster in a scale-out” do nothing more than to add insignificant extra solution activity to the judicial exception of merely storing/gathering data for automation. See MPEP § 2106.05(h).
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “version upgrade device comprising: a memory configured to store instructions; and at least one processor coupled to the memory and configured to execute the instructions to cause the version upgrade device to,” “a client,” “first node” and “upgrade, when the first software version is different from the target version, the first node to an upgraded first node such that a second software version running on the upgraded first node is the target version” amount to no more than mere instructions, or generic computer and/or computer components to carry out the judicial exception, thus, cannot amount to an inventive concept. See MPEP 2105.06(f). For the additional elements “receive,… , an upgrade request message comprising a first identifier of a service cluster an and a second identifier of a target version; obtain a version baseline of the service cluster based on the first identifier; add… to the service cluster in a scale-out” the courts have recognized storing and retrieving information in memory as a well‐understood, routine, and conventional functions in a merely generic manner (e.g., at a high level of generality) or an insignificant extra-solution activity (Berkheimer v. HP, Inc., 881 F.3d 1360, 1368, 125 USPQ2d 1649, 1654 (Fed. Cir. 2018)), See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 USC 101.
11. (Currently Amended) The version upgrade device of claim 10, wherein to upgrade the first node, the at least one processor is further configured to execute the instructions to cause the version upgrade device to: create the upgraded first node; and switch traffic on the first node to the upgraded first node.
The limitations, wherein to upgrade the first node, the at least one processor is further configured to execute the instructions to cause the version upgrade device to, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2. For the limitations, create the upgraded [first node], for this claim further recite an additional mental process under Step 2A, Prong 1. For the limitations, switch traffic on the first node to the upgraded [first node], are an additional insignificant extra solution activity under step 2A, Prong 2.
12. (Currently Amended) The version upgrade device of claim 10, wherein after receiving the upgrade request message, the at least one processor is further configured to execute the instructions to cause the version upgrade device to upgrade a second node in the service cluster to an upgraded second node such that a third software version running on the upgraded second node is the target version, and wherein the second node is in the service cluster before the scale-out.
The limitations, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2.
13. (Currently Amended) The version upgrade device of claim 11, wherein when a node upgrade rate of the service cluster has reached a preset indicator, the at least one processor is further configured to execute the instructions to cause the version upgrade device to upgrade the version baseline to indicate that a third software version running on a second node added to the service cluster in the scale-out is the target version.
The limitations, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2.
14. (Currently Amended) The version upgrade device of claim 13, wherein the upgrade request message further comprises an upgrade manner, wherein the upgrade manner indicates to upgrade nodes in the service cluster in batches, and wherein the nodes comprise the first node and the second node.
The limitations, wherein the upgrade request message further comprises an upgrade manner, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2. For the limitations for this claim further recite an additional insignificant extra solution activity under step 2A, Prong 2.
15. (Currently Amended) The version upgrade device of claim 13, wherein before
The limitations, wherein after upgrading the first node, the at least one processor is further configured to execute the instructions to cause the version upgrade device to, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2. For the limitations, to complete gray verification of software on an upgraded [second node] in at least one batch, for this claim further recite an additional mental process under Step 2A, Prong 1.
16. (Currently Amended) The version upgrade device of claim 10, wherein after
The limitations, wherein after upgrading the first node, the at least one processor is further configured to execute the instructions to cause the version upgrade device to, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2. For the limitations, receive,…, a rollback request message comprising the first identifier and a third identifier of a historical version running on … during the scale-out; and rollback the upgraded …
17. (Currently Amended) The version upgrade device of claim 16, wherein the at least one processor is further configured to execute the instructions to cause the version upgrade device to switch traffic on the upgraded first node to the first node.
The limitations, wherein the at least one processor is further configured to execute the instructions to cause the version upgrade device, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2. For the limitations, to switch traffic on the upgraded are an additional insignificant extra solution activity under step 2A, Prong 2.
18. (Currently Amended) The version upgrade device of claim 13, wherein the at least one processor is further configured to execute the instructions to cause the version upgrade device to obtain, from a user, the preset indicator.
The limitations, wherein the at least one processor is further configured to execute the instructions to cause the version upgrade device, from a user, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2. For the limitations, obtain,…, the preset indicator are an additional insignificant extra solution activity under step 2A, Prong 2.
Claim 19, this claim is within at least one of the four categories of patent eligible subject matter as it is directing to a meduim claim under Step 1.
19. (New) A computer program product comprising computer-executable instructions that are stored on a computer-readable medium and that, when executed by at least one processor, cause a version upgrade device to:
receive, from a client, an upgrade request message comprising a first identifier of a service cluster and a second identifier of a target version;
obtain, based on the first identifier, a version baseline of the service cluster;
add a first node to the service cluster in a scale-out;
determine, based on the version baseline, a first software version running on the first node; and
upgrade, when the first software version is different from the target version, the first node to an upgraded first node such that a second software version running on the upgraded first node is the target version.
Regarding claim 19, the limitations “determining, based on the version baseline, a first software version running” as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. For example, a person is capable of finding based on the received request with the aid of pen and paper to look up in a table or map with the request to find the current version running. Therefore, these limitations encompass a human mind carrying out the function through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, the additional elements “version upgrade device comprising: a memory configured to store instructions; and at least one processor coupled to the memory and configured to execute the instructions to cause the version upgrade device to,” “a client,” “first node” and “upgrade, when the first software version is different from the target version, the first node to an upgraded first node such that a second software version running on the upgraded first node is the target version” is recited at a high-level of generality such that it amounts no more than mere instructions for executing/running
software tool which merely using generic computing equipment to apply/execute/run the software tool to perform the abstract idea. See MPEP 2106.05(f). For the additional elements “receive,…, an upgrade request message comprising a first identifier of a service cluster an and a second identifier of a target version; obtain a version baseline of the service cluster based on the first identifier; add… to the service cluster in a scale-out” do nothing more than to add insignificant extra solution activity to the judicial exception of merely storing/gathering data for automation. See MPEP § 2106.05(h).
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “version upgrade device comprising: a memory configured to store instructions; and at least one processor coupled to the memory and configured to execute the instructions to cause the version upgrade device to,” “a client,” “first node” and “upgrade, when the first software version is different from the target version, the first node to an upgraded first node such that a second software version running on the upgraded first node is the target version” amount to no more than mere instructions, or generic computer and/or computer components to carry out the judicial exception, thus, cannot amount to an inventive concept. See MPEP 2105.06(f). For the additional elements “receive,…, an upgrade request message comprising a first identifier of a service cluster and a second identifier of a target version; obtain, based on the first identifier, a version baseline of the service cluster; add… to the service cluster in a scale-out” the courts have recognized storing and retrieving information in memory as a well‐understood, routine, and conventional functions in a merely generic manner (e.g., at a high level of generality) or an insignificant extra-solution activity (Berkheimer v. HP, Inc., 881 F.3d 1360, 1368, 125 USPQ2d 1649, 1654 (Fed. Cir. 2018)), See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 USC 101.
20. (New) The computer program product of claim 19, wherein to upgrade the first node, when executed by the at least one processor, the computer-executable instructions further cause the version upgrade device to: create the upgraded first node; and switch traffic on the first node to the upgraded first node.
The limitations, wherein to upgrade the first node, when executed by the at least one processor, the computer-executable instructions further cause the version upgrade device to, amount to no more than mere instructions to apply the exception using generic computer and/or mere computer components to carry out the exception under Step 2A, Prong 2. For the limitations, create the upgraded [first node], for this claim further recite an additional mental process under Step 2A, Prong 1. For the limitations, switch traffic on the [first node] to the upgraded [first node], are an additional insignificant extra solution activity under step 2A, Prong 2.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-5, 9-14 and 18-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by USPN 20100313063 to Venkataraja et al.
Per claim 1:
Venkataraja discloses:
1. (Currently Amended) A method, comprising:
receiving, from a client, an upgrade request message comprising a first identifier of a service cluster and a second identifier of a target version (Paragraph [0040,0041] “receives an indication that a software/enterprise application installed in a cluster (130B) is to be upgraded… indication may specify the name/identifier of the enterprise application as well as the specific maintenance activity (upgrade) to be performed. For example, the indication may specify that an older/previous version (1.0) of the software application needs to be replaced by a newer/upgraded version (2.0)”);
obtaining a version baseline of the service cluster based on the first identifier (Paragraph [0042] “on receiving the indication, scheduler 150 may first identify the nodes that form the cluster (130B), that is the specific server systems, data stores, etc. that are being used for processing user/service requests”);
adding a first node to the service cluster in a scale-out (Paragraph [0043] “scheduler 150 scales-out the cluster (130B) to add a set of nodes installed with the upgraded software application… Scale-out refers to the process of adding nodes to a cluster”);
determining, based on the version baseline, a first software version running on the first node (Paragraph [0063] “row 351 indicates that the corresponding node uniquely identified by the value “1001” (column 321) is executing the softwares S1, S2 and S3 (column 322) which are available/ready for processing user requests (column 323)”); and
upgrading, when the first software version is different from the target version (Paragraph [0068] “response to receiving an indication that software application S2 is to be upgraded from version 1.0 to version 2.0 (step 210)”), the first node to an upgraded first node such that a second software version running on the upgraded first node is the target version (Paragraph [0055] “replaces them with new nodes executing the upgraded version of the software application… newly added nodes, are executing the same software set such that any two nodes are interchangeable”).
Per claim 2:
Venkataraja discloses:
2. (Currently Amended) The method of claim 1, wherein upgrading the first node comprises:
creating the upgraded first node (Paragraph [0044] “scheduler 150 by scaling-out cluster 130B adds a set of nodes (not shown in FIG. 1) having the upgraded software application”); and
switching traffic on the first node to the upgraded first node (Paragraph [0044] “scheduler 150 by scaling-out cluster 130B adds a set of nodes (not shown in FIG. 1) having the upgraded software application. Scheduler 150 may then forward user requests (for processing) to the newly added set of upgraded nodes”).
Per claim 3:
Venkataraja discloses:
3. (Currently Amended) The method of claim 1, wherein after receiving the upgrade request message the method further comprises:
upgrading a second node in the service cluster to an upgraded second node such that a third software version running on the upgraded second node is the target version, and wherein the second node is in the service cluster before the scale-out (Paragraph [0043] “scheduler 150 scales-out the cluster (130B) to add a set of nodes installed with the upgraded software application. Scale-out refers to the process of adding nodes to a cluster such that future user/service requests can be processed using the newly added nodes”).
Per claim 4:
Venkataraja discloses:
4. (Currently Amended) The method of claim 2, wherein when a node upgrade rate of the service cluster has reached a preset indicator, the method further comprises updating the version baseline to indicate that a third software version running on a second node added to the service cluster in the scale-out is the target version (see Fig. 3A, B and Paragraph [0066-0069]. Note here that value of t is preset indicator for versions S1, S2, S3 etc.).
Per claim 5:
Venkataraja discloses:
5. (Currently Amended) The method of claim 4 wherein the upgrade request message further comprises an upgrade manner, wherein the upgrade manner indicates to upgrade nodes in the service cluster in batches, and wherein the nodes comprise the first node and the second node (see Fig. 1 and related discussion).
Per claim 9:
Venkataraja discloses:
9. (Currently Amended) The method of claim 4, further comprising obtaining, from a user, the preset indicator (Paragraph [0067] ““X” if the corresponding node is executing (and processing user requests by)”).
Claims 10-15 and 18 is/are the apparatus/system claim corresponding to method claims 1-5 and 9 respectively, and rejected under the same rational set forth in connection with the rejection of claims 1-5 and 9 respectively, as noted above.
Claims 19-20 is/are the medium/product claim corresponding to method claims 1-2 respectively, and rejected under the same rational set forth in connection with the rejection of claims 1-2 respectively, as noted above.
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.
Claim(s) 7-8 and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over USPN 20100313063 to Venkataraja et al. in view of USPN 20080178168 to Sriram et al.
Per claim 7:
The rejection of claim 1 is incorporated and further, Venkataraja does not explicitly discloses receiving, from the client, a rollback request message comprising the first identifier and a third identifier of a historical version running on the first node during the scale-out; and rolling back the upgraded first node to the first node such that a third software version running on the first node is the historical version.
However, Sriram discloses in an analogous computer system receiving, from the client, a rollback request message comprising the first identifier and a third identifier of a historical version running on the first node during the scale-out (Paragraph [0131,0133] “patch tool 150 receives a request to rollback the new patch in the runtime system… reverting to a desired one of any prior versions of the preinstalled software”); and rolling back the upgraded first node to the first node such that a third software version running on the first node is the historical version (Paragraph [0132] “patch tool 150 rolls back the new patch in the runtime system thereby restoring the state of the runtime system to the state before deployment of the new patch”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to incorporate the method of receiving, from the client, a rollback request message comprising the first identifier and a third identifier of a historical version running on the first node during the scale-out; and rolling back the upgraded first node to the first node such that a third software version running on the first node is the historical version as taught by Sriram into the method of upgrading various nodes and scaling in/out as taught by Venkataraja. The modification would be obvious because of one of ordinary skill in the art would be motivated to add/incorporate the features of receiving, from the client, a rollback request message comprising the first identifier and a third identifier of a historical version running on the first node during the scale-out; and rolling back the upgraded first node to the first node such that a third software version running on the first node is the historical version to provide an efficient technique for simplifying rollback to prior versions of patches used to fix errors in pre-installed software as suggested by Sriram (paragraph [0004-0008]).
Per claim 8:
Venkataraja discloses:
8. (Currently Amended) The method of claim 7, further comprising switching traffic on the upgraded first node to the first node (Paragraph [0044] “scheduler 150 by scaling-out cluster 130B adds a set of nodes (not shown in FIG. 1) having the upgraded software application. Scheduler 150 may then forward user requests (for processing) to the newly added set of upgraded nodes”).
Claims 16-17 is/are the apparatus/system claim corresponding to method claims 7-8 respectively, and rejected under the same rational set forth in connection with the rejection of claims 7-8 respectively, as noted above.
Allowable Subject Matter
Claims 6 and 15 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Please note that if any of the claims are rejected under 101 above, applicants must overcome the rejections in order for these claims to be allowed.
The cited prior art taken alone or in combination fail to teach, in the context of the claim limitations and in combination with the other claimed limitations “wherein before updating the version baseline, the method further comprises completing gray verification of software on an upgraded second node in at least one batch” as recited in a manner in the claim 6 and 15.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Related cited arts:
Fox, Armando, et al. "Cluster-based scalable network services." Proceedings of the sixteenth ACM symposium on Operating systems principles. 1997. pp. 78-91.
Tang, Chunqiang, et al. "Twine: A unified cluster management system for shared infrastructure." 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). 2020. pp. 787-803.
Boutin, Eric, et al. "Apollo: Scalable and coordinated scheduling for {Cloud-Scale} computing." 11th USENIX symposium on operating systems design and implementation (OSDI 14). 2014. pp. 285-300.
US 20220326938 A1 - An upgrade method and an apparatus are provided, and relate to the field of internet of vehicles technologies. When a plurality of devices in an intelligent connected vehicle need to be upgraded, upgrade efficiency and a download speed can be improved, and a load and a storage requirement of a telematics box or a gateway can be reduced. The method includes: receiving upgrade information of a first apparatus from an over the air (OTA) node; establishing a first channel with a server based on the upgrade information of the first apparatus; receiving an upgrade package of the first apparatus from the server through the first channel; and performing upgrade based on the upgrade package of the first apparatus.
US 20220276856 A1 - Example software upgrading methods and apparatus are described. In one example, storage resource information of at least two components in a terminal is received. Storage resource feedback information is generated. The storage resource feedback information is sent to a network side device. Upgrade package block information generated by the network side device is received, where the upgrade package block information includes at least a one-to-one correspondence between a plurality of upgrade package blocks for terminal software upgrading and a plurality of components for storing the plurality of upgrade package blocks. At least one piece of indication information used to indicate the plurality of components to obtain the plurality of upgrade package blocks are generated. The at least one piece of indication information is sent to the plurality of components.
US 20200201624 A1 - Methods and systems for upgrading an intelligent server adapter (ISA) with reduced downtime that affects performance are provided. The method includes, from a main agent, initiating a backup agent that includes critical functions of the ISA and runs in a tight loop, isolated from other components. The main agent transfers critical duties to the backup agent and shuts down before performing the upgrade. After upgrading itself and other system components, the main agent retrieves the duties from the backup agent, and may terminate the backup agent.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Satish Rampuria whose telephone number is 571-272-3732. The examiner can normally be reached on Monday-Friday from 8:30 AM to 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do, can be reached at telephone number 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
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.
/Satish Rampuria/Primary Examiner, Art Unit 2193
*****
Prosecution Insights