DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are presented for examination.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation that the batch information “comprises an upgrade sequence of each group,” in line 3. There is insufficient antecedent basis for “each group” because the claim never previously introduces a “group” or “groups,” which leads to ambiguity of what a “group” is, how many groups exist, and/or whether groups are batches, subsets of nodes, or something else. In addition, it is unclear as to whether the recited “upgrade sequence” sequentially orders groups or sequentially orders nodes within a group. Because the claim does not clearly identify what is being sequenced or which sequence is involved in the determination of the to-be-upgraded group node, the scope of the claim cannot be ascertained.
As to claim 11, it is rejected for the same reasons as stated in the rejection of claim 1.
As to claims 2-8 and 12-20, they are dependent on rejected claims 1 and 11 and also failing to cure their deficiencies.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over (CN109525410A – see English Translation) in view of Pianigiani et al. (hereinafter PIANIGIANI) (US 10,742,501 B1).
As to claim 1, CN109525410A teaches a method for upgrading nodes in batches (“distributed storage system upgrade management” with an “upgrade scheme” that “includes dividing multiple nodes into at least one batch, and the nodes in each batch satisfy each constraint”) (Abstract, pg. 1), comprising:
obtaining batch information for upgrading (“the scheduling node determines a first upgrading scheme” which involves “dividing the plurality of nodes into at least one batch” - Abstract), wherein the batch information for upgrading comprises an upgrade sequence (“as an example, if the first upgrade scheme is obtained in 3 batches, the 1st batch is the node1, the node4 and the node6, the 2nd batch is the node2, the node5 and the node7, and the 3rd batch is the node3 and the node8” - paragraph 11 of page 6; Fig. 6; “the upgrading scheme is also different due to the fact that the upgrading sequence of each batch is different” – 2nd paragraph of page 8);
determining a to-be-upgraded group node based on the upgrade sequence (“Step 301, selecting one node which is not upgraded from the plurality of nodes” – paragraph 12 of page 7; “Step 306, taking all the selected nodes which are not upgraded as a batch” – paragraph 19 of pg. 7); upgrade sequence from batch ordering of 1st/2nd/3rd batch and/or node sorting/selection order used to form batches - paragraph 11 of page 6 and paragraphs 12-19 of pg. 7);
migrating a service (“service is handed over” and/or “take over the service”) on the to-be-upgraded group node to another non-upgraded node (“other nodes in the distributed storage system are needed to take over the service executed on the node” – pg. 2, 2nd paragraph after “Background” section; “in the process of upgrading a node, a service being executed on the node needs to be executed instead by another node, and in general, an unexecuted service is handed over to a node with the same function to be completed, so that smooth execution of the service is ensured, and thus, a load of the node with the same function as the node in the process of upgrading is inevitably increased” – pg. 5, 2nd paragraph after “Detailed Description”); and
upgrading the to-be-upgraded group node (“upgrade all the nodes needing to be upgraded in batches according to the first upgrading scheme” – 1st paragraph of page 3; “the dispatch node sends an upgrade instruction to each node in batches after determining the upgrade scheme, so as to instruct all nodes in the same batch to perform upgrade at the same time” – 3rd paragraph of pg. 7).
CN109525410A does not explicitly teach that its batch information includes an upgrade sequence for each group.
However, PIANIGIANI explicitly teaches partitioning devices into groups of network devices/batches (“individual groups of network devices in sequence and/or in parallel”), in addition to having batch information such as maintenance mode strategy, topology/role/state information, and/or defined order/sequence used to execute upgrades (“The network controller is configured to selectively initiate these operations in an ordered, strategic manner based on various factors and/or input, such as topology information” – col. 4, lines 57-60; “maintenance mode controller 115 may determine, based on a topology of network 100, a defined order in which to place network devices into the maintenance mode (e.g., individual groups of network devices in sequence and/or in parallel)” – col. 9, lines 52-56; col. 15, lines 24-60; Fig. 3).
CN109525410A and PIANIGIANI are analogous art with the claimed invention because they are all in the same field of endeavor of batch upgrading. In addition, PIANIGIANI suggests that maintenance/upgrade operations should be performed in an “ordered, strategic manner” using topology-based strategy, and explicitly contemplates groups of devices upgraded in sequence and/or parallel (col. 4, lines 46-67; col. 9, lines 52-56). Thus, it would have been obvious to one of ordinary skill in the art before the effective date of the application to modify CN109525410A’s batch update framework such that it would include PIANIGIANI’s batch information that includes an upgrade sequence for each group. The motivation for doing so would have been to provide the predicted result of avoiding disruption and packet/service loss during upgrades of multiple nodes through the use of ordering and planning upgrades in a strategic way (PIANIGIANI: col. 26, line 66 through col. 27, line 15; col. 4, lines 57-60).
As to claim 2. CN109525410A and PIANIGIANI teaches the method according to claim 1, wherein after the to-be-upgraded group node is upgraded (CN109525410A: “the number of nodes to be upgraded is reduced after the upgrade process of the nodes of a partial batch is completed” – last paragraph of pg. 3; PIANIGIANI: post-maintenance/post-upgrade state – Abstract; col. 20, lines 32-35), the method further comprises: migrating a service on the another non-upgraded node to a group node that is upgraded (CN109525410A – “take over the service executed on the node” - pg. 2, 2nd paragraph after “Background” section; PIANIGIAN – “enable diversion of network traffic from network device 470 to another device in the network” - col. 24, lines 15-16).
As to claim 3, CN109525410A teaches the method according to claim 2, wherein after the migrating a service on the another non-upgraded node to a group node that is upgraded, the method further comprises: determining a next to-be-upgraded group node based on the upgrade sequence (selecting one node which is not upgraded and repeating the processes until the batch division is completed; nodes may be sorted; upgrading sequence of each batch is different) (page 8, 2nd paragraph; pg. 7, last paragraph); migrating a service on the next to-be-upgraded group node to another non-upgraded node (CN109525410A – “take over the service executed on the node” - pg. 2, 2nd paragraph after “Background” section); and upgrading the next to-be-upgraded group node (Abstract).
As to claim 4, CN109525410A teaches the method according to claim 1, wherein each group comprises a node type of each group (“nodes belonging to the same group have the same function or the same physical area” – pg. 9, 8th paragraph), an identifier corresponding to a group sequence of each group (ordered selection and sequencing of groups/nodes for upgrade) (pg. 8, 2nd paragraph), a node identifier corresponding to a node in each group (NODE1, …., NODE7 – pg. 8, 9th paragraph; nodes are also inherently identified before they are sorted- pg. 7, 13th paragraph), and a host identifier corresponding to the node in each group (under BRI, node ID can equal host ID); and a node type of the to-be-upgraded group node is the same (service is transferred to node with the same function) as that of the another non-upgraded node (pg. 9, 8th paragraph).
As to claim 5, CN109525410A teaches the method according to claim 1, wherein before the obtaining batch information for upgrading, the method further comprises: obtaining a node set, wherein each node in the node set corresponds to one node type (NODE set formed by NODEs 1 to 7”, for example – pg. 8, 9th paragraph; “nodes belonging to the same group have the same function or the same physical area” – pg. 9, 8th paragraph); obtaining a node batch rule set , wherein the node batch rule set comprises a node batch rule corresponding to each node type (constraint conditions and “nodes belonging to the same group have the same function or the same physical area” – pg. 9, 7th-8th paragraph); and performing batching on the node set based on the node batch rule set, to obtain the batch information for upgrading (Abstract).
As to claim 6, CN109525410A teaches the method according to claim 5, wherein the method further comprises: determining a service running on a node, wherein the service corresponds to a service type; determining a batch rule corresponding to the service type; and determining, according to the batch rule corresponding to the service type, a node batch rule corresponding to the node type (constraint conditions and “nodes belonging to the same group have the same function or the same physical area” – Abstract; pg. 9, 7th-8th paragraph).
As to claim 7, CN109525410A teaches the method according to claim 1, wherein before the migrating a service on the to-be-upgraded group node to another non-upgraded node, the method further comprises: obtaining a first message (upgrading instructions), wherein the first message indicates the to-be-upgraded group node to be upgraded (“the scheduling node may obtain the constraint condition of each group by sending a constraint condition request message to all nodes that need to be upgraded, respectively” – pg. 8, 3rd paragraph; “sends upgrading instruction” - Abstract).
As to claim 8, CN109525410A teaches the method according to claim 1, wherein before the upgrading the to-be-upgraded group node, the method further comprises: obtaining a second message, wherein the second message (upgrading instructions) indicates that all services on the to-be-upgraded group node are migrated (“take over the service executed on the node” - pg. 2, 2nd paragraph after “Background” section) to the another non-upgraded node (the node in each bath is all satisfied each constraint condition - Abstract).
As to claim 9, CN109525410A teaches the method according to claim 2, wherein before the migrating a service (“take over the service executed on the node” - pg. 2, 2nd paragraph after “Background” section) on the another non-upgraded node to a group node that is upgraded, the method further comprises: obtaining a third message, wherein the third message (upgrading instructions) indicates that the to-be-upgraded group node is upgraded (the node in each bath is all satisfied each constraint condition – Abstract; “after the upgrade process of the nodes of a partial batch is completed” – pg. 3, last paragraph).
As to claim 10, CN109525410A teaches the method according to claim 3, wherein before the determining a next to-be-upgraded group node based on the upgrade sequence, the method further comprises: obtaining a fourth message (upgrading instructions), wherein the fourth message indicates that the service on the another non-upgraded node is migrated to the group node that is upgraded (“service is handed over” and/or “take over the service”) on the to-be-upgraded group node to another non-upgraded node (“other nodes in the distributed storage system are needed to take over the service executed on the node” – pg. 2, 2nd paragraph after “Background” section; “in the process of upgrading a node, a service being executed on the node needs to be executed instead by another node, and in general, an unexecuted service is handed over to a node with the same function to be completed, so that smooth execution of the service is ensured, and thus, a load of the node with the same function as the node in the process of upgrading is inevitably increased” – pg. 5, 2nd paragraph after “Detailed Description”).
As to claim 11, it is rejected for the same reasons as stated in the rejection of claim 1.
As to claim 12, it is rejected for the same reasons as stated in the rejection of claim 2.
As to claim 13, it is rejected for the same reasons as stated in the rejection of claim 3.
As to claim 14, it is rejected for the same reasons as stated in the rejection of claim 4.
As to claim 15, it is rejected for the same reasons as stated in the rejection of claim 5.
As to claim 16, it is rejected for the same reasons as stated in the rejection of claim 6.
As to claim 17, it is rejected for the same reasons as stated in the rejection of claim 7.
As to claim 18, it is rejected for the same reasons as stated in the rejection of claim 8.
As to claim 19, it is rejected for the same reasons as stated in the rejection of claim 9.
As to claim 20, it is rejected for the same reasons as stated in the rejection of claim 10.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH TANG whose telephone number is (571)272-3772. The examiner can normally be reached Monday-Friday 7AM-3PM.
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, Bradley Teets can be reached at 571-272-3338. 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.
/KENNETH TANG/Primary Examiner, Art Unit 2197