DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 8/18/2025 has been entered.
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 .
Claim Rejections - 35 USC § 112
3. 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.
4. Claim 21 limitations “a communication means …,” ”a storage means …” and “a means for determining …” invoke 35 U.S.C. 112(f). However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b).
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f);
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 101
5. 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 – 21 are directed to an abstract idea without significantly more. Independent claim 1 recites a system comprising: a memory in a first node, the memory configured to store a critical state policy that includes executable code, to store values of constant node attributes at a second node, and to store current values of nonconstant node attributes of the second node; and a processor in the first node, the processor configured to perform an upgrade of the second node in response to determining that a criticality state value indicates that the second node can be taken offline without disrupting critical operations by: determining the criticality state value by running the executable code, the executable code configured to use the current values of the nonconstant node attributes of the second node and the values of the constant node attributes to determine the criticality state value; performing an upgrade of the second node in response to determining that the criticality state value indicates that the second node can be taken offline without disrupting critical operations; and wherein the executable code is configured to produce criticality state values that have one of only two distinct values with only one of the two distinct values indicating that a node can be taken offline without disrupting critical operations.
The limitations, as drafted, describe a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. The abstract idea limitations are “determining the criticality state value … ” and “determining that a critical state value indicates …” in Prong I step 2A. Other limitations including “store a critical state policy includes executable code …,” “perform an upgrade …” and “wherein the executable code is configured …” are considered pre/post-activity solutions for receiving policy and direction information and performing an action which is merely an applied application which insignificantly amounts to a judicial exception. Thus, these claims are directing to abstract idea under 35 USC 101.
Other than “a memory …” “a processor …” there is nothing in the claim elements preclude the steps from practically being performed in the mind. All of the non-abstract limitations are pre/post-activity solutions for getting/obtaining/manipulating/displaying data without significantly more. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the components in the determining step are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of receiving information, executing a function and making a decision) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Additionally, the steps of “store a critical state policy includes executable code …,” and “performing the upgrade …” and “wherein the executable code is configured …” are pre/post-activity solutions as gathering/manipulating data that are insignificant under Prong II step 2A and 2B. See Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015) (Storing and retrieving information in memory) as noted in MPEP 2106.05(d)(II)(iv).
Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
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 element of using a computer to perform the noted steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible. Independent claims 16 and 21 are rejected on the same basis as independent claim 1. Additionally, dependent claims 2 – 15 and 17 - 20 are similarly rejected as being directed to an abstract idea since these claims are either further detailing the abstract idea by analyzing/processing the data or the elements are insignificant. More specifically, the dependent claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception.
As per claim 2, “wherein constant node attributes of the second node include a node role indicator that indicates a role held by the second node within an infrastructure” is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claims 3 and 18, “wherein one of the current values for the nonconstant node attributes of the second node is received from the second node in response to sending node executable code to the second node” is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 4, “wherein the first node is configured to: store a critical state database; obtain a plurality of test run results by performing a plurality of test runs of the critical state policy at each of the plurality of times; and store the test run results in the critical state database as a plurality of time series entries” is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 5, “wherein: the first node communicates over a network with the second node” recites generic computer components for applying the abstract idea.
As per claims 6 and 17, “wherein the second node is configured to periodically provide one of the current values to the second node” is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 7, “wherein the second node produces one of the current values for the nonconstant node attributes of the second node by executing node executable code in response to receiving the node executable code from the first node” is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 8, “wherein a third node is a virtual machine (VM) running on the second node; a network interface card (NIC) installed in the second node, is configured to determine one of the current values for the nonconstant node attributes of the second node by running NIC executable code in response to receiving the NIC executable code from the first node” recites generic computer components for applying the abstract idea; and “the NIC is configured to determine a third current value that is one of the current values for the nonconstant node attributes of the third node by executing the executable code on the NIC” is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 9, “wherein a network interface card (NIC) is installed in the second node” and “a third node is a virtual machine (VM) running on the second node” recites generic computer components for applying the abstract idea, and “the NIC is configured to produce one of the current values for the nonconstant node attributes of the third node in response to receiving NIC executable code from the first node” is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claims 10 and 19, “wherein the second node is running a third node that is a virtual machine (VM)” recites generic computer components for applying the abstract idea; and “a current value for a nonconstant node attribute of the third node is used to determine the criticality state value of the second node” recites an additional mental process.
As per claims 11 and 20, “wherein a network interface card (NIC) is installed in the second node” recites generic computer components for applying the abstract idea; “the critical state policy includes a NIC executable code that the NIC executes to determine one of the current values” is an additional element of data gathering which is insignificant extra solution activity as explained above; and “the upgrade upgrades the NIC” recites generic computer components for applying the abstract idea.
As per claim 12, “wherein the current values for the nonconstant node attributes of the second node include a CPU usage statistic, a memory usage statistic, a non-volatile memory input/output statistic, a long-lived network session statistic, a short-lived network session statistic and a process identifier that identifies a process running on the second node” is an additional element of data gathering which is insignificant extra solution activity as explained above.
As per claim 13, “wherein the first node is configured to upgrade a plurality of nodes that are identified by a plurality of node identifiers” recites generic computer components for applying the abstract idea; “the first node stores a plurality of critical state policies corresponding to the nodes” is an additional element of data gathering which is insignificant extra solution activity as explained above; and “the nodes are upgraded only when the nodes can be taken offline without disrupting critical operations according to the critical state policies” recites generic computer components for applying the abstract idea.
As per claim 14, “wherein the first node is configured to: produce criticality state time series data that indicates the criticality state of each of the nodes as a function of time” is an additional element of data gathering which is insignificant extra solution activity as explained above; “determine upgrade windows for the nodes” is an additional element of data gathering which is insignificant extra solution activity as explained above; and “upgrade the nodes based on the upgrade windows” recites generic computer components for applying the abstract idea.
As per claim 15, “wherein: the first node is configured to store time series data that includes a plurality of time series entries that indicate a criticality state of the second node at a plurality of times” is an additional element of data gathering which is insignificant extra solution activity; “the first node is configured to obtain test run data produced by a test run of the critical state policy” s an additional element of data gathering which is insignificant extra solution activity; “the first node is configured to store the test run data as one of the time series entries” s an additional element of data gathering which is insignificant extra solution activity; “the critical state policy uses values of constant node attributes to determine the criticality state of the second node” ; the critical state policy includes a node executable code” recites generic computer components for applying the abstract idea; “executing the node executable code on the second node produces a first current value that is one of the current values for the nonconstant node attributes of the second node” s an additional element of data gathering which is insignificant extra solution activity (additional element under Prong II step 2A); “a network interface card (NIC) is installed in the second node” recites generic computer components for applying the abstract idea; “the NIC is configured to periodically determine a second current value that is one of the plurality of current values for the nonconstant node attributes of the second node” is an additional element of data gathering which is insignificant extra solution activity; “the critical state policy includes a NIC executable code” recites generic computer components for applying the abstract idea; “the second current value is produced by executing the NIC executable code on the NIC” is an additional element of data gathering which is insignificant extra solution activity; “a third node is a virtual machine (VM) running on the second node” recites generic computer components for applying the abstract idea; “the NIC is configured to periodically determine a third current value that is one of the current values for the nonconstant node attributes of the third node” is an additional element of data gathering which is insignificant extra solution activity (additional element under Prong II step 2A); “the third current value is produced by executing the NIC executable code on the NIC” is an additional element of data gathering which is insignificant extra solution activity; and “the current values include a CPU usage statistic, a memory usage statistic, a non- volatile memory input/output statistic, a long-lived network session statistic, a short-lived network session statistic, and a process identifier that identifies a process running on the second node” is an additional element of data gathering which is insignificant extra solution activity.
Claim Rejections - 35 USC § 103
6. 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.
7. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
8. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
9. Claims 1, 5, 16 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta et al. (U.S. Publication 2021/0036913) (Gupta hereinafter) in view of Chopra et al. (U.S. Patent 9,575,738) (Chopra hereinafter) and Pettersson (U.S. Publication 2022/0399724) (Pettersson hereinafter).
10. As per claim 1, Gupta teaches a system comprising:
a memory in a first node, the memory configured to store a critical state policy that includes executable code, to store values of constant node attributes of a second node, and to store current values of nonconstant node attributes of the second node; and a processor in the first node, the processor configured to determining the criticality state value by running the executable code, the executable code configured to use the current values of the nonconstant node attributes of the second node and the values of the constant node attributes to determine the criticality state value [“The configuration server 202 may also include a health calculator 212. As described in detail below, the health calculator 212 may calculate a health for each network device 204. For example, the health calculator 212 may calculate a health score 214 for each network device 204, and may store the health scores 214 in the configuration server 202.” ¶ 0033; health calculator mapped to critical state policy, health score mapped to criticality state; “Hardware processor 302 may execute instructions 306 to select a group of network devices to receive a configuration update. For example, referring to FIG. 2, one or more of the network devices 204 may be selected to receive one or more of the configurations 206 stored in the configuration server 202. The group of network devices 204 may be selected in any manner. For example, when configuration 206 is available for a particular make and model of network device 204, all of those devices may be selected. As another example, all of the network devices 204 on a particular floor of an office building may be selected. As another example, all of the network devices 204 associated with a particular organization, region, or branch may be selected. Embodiments of the disclosed technology are independent of the manner in which the group of network devices 204 selected,” ¶ 0037; the group of network devices to be upgraded and to receive a health score calculation is based on constant values (e.g., particular make and model of a network device); calculating a health score 214 for a network device 204 may include calculating a function of one or more values. In some embodiments, the function may be a weighted sum of the values, for example such as described below with reference to equation (2).” ¶ 0050; “wherein generating one of the health scores for one of the network devices comprises: calculating a function of one or more values, wherein the values may represent one or more of: an interface connectivity of the network device, a quality of service of the network device, a performance of a hardware component of the network device, a performance of a software component of the network device, and a security performance of the network device,” cl. 6; values mapped to nonconstant node attributes].
Gupta does not explicitly disclose but Chopra discloses perform an upgrade of the second node in response to determining that a criticality state value indicates that the second node can be taken offline without disrupting critical operations by: performing the upgrade of the second node in response to determining that the critical state value indicates that the second node can be taken offline without disrupting critical operations [“A rule, such as Rule 3, may determine an order in which nodes are upgraded based on their current operational status. For example, passive nodes may be upgraded first, and then active nodes may be taken offline and upgraded. As similarly discussed above, in a cluster that implements load balancing and failover capabilities, all nodes can't be taken offline and upgraded at the same time without disrupting functionality of software executing in the cluster. Therefore, by selectively upgrading identified passive nodes first and then upgrading active nodes, all nodes in a cluster may be upgraded, and functionality of software executing in the cluster is not disrupted,” col. 15, lines 39 – 51; identified passive nodes mapped to determined critical state value].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta and Chopra available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta to include the capability of constraint-based upgrade and deployment as taught by Chopra, thereby providing a mechanism to enhance system efficiency by facilitating system upgrades based on system health measures.
Gupta and Chopra do not explicitly disclose but Pettersson discloses wherein the executable code is configured to produce criticality state values that have one of only two distinct values with only one of the two distinct values indicating that a node can be taken offline without disrupting critical operations [“the module controller 6 classifies the critical security status as either an internal status or an external status. An internal security status is defined as being a security status that only affects the power producing module 4 that generated the security critical status, i.e. an internal error. An external security status is defined as being a security status that affects the whole power producing system 2 and not only the power producing module 4 that generated the security critical status.” ¶ 0050; security status mapped to criticality state values; “Thus, by using a safety processor 22 and determining the type of critical security status it is possible to connect and disconnect individual power producing modules 4 from the power producing system 2 without the need to interrupt the operation of the entire power producing system 2.” ¶ 0053].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra and Pettersson available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta and Chopra to include the capability of determining the potential impact of power down actions as taught by Pettersson, thereby providing a mechanism to enhance system efficiency by facilitating node upgrades while minimizing impact to system operations.
11. As per claim 5, Gupta, Chopra and Pettersson teach the system of claim 1. Chopra further teaches wherein: the first node communicates over a network with the second node [“system 400 may include inventory engine 402, which may retrieve and manage various information associated with one or more nodes in one or more clusters of resources. Inventory engine 402 may manage some or all information that is used to deploy an application in one or more clusters of a coherency group. Thus, inventory engine 402 may be configured to query nodes to retrieve information about nodes in a cluster in which an application is to be deployed. Inventory engine 402 may communicate with the nodes directly. Alternatively, inventory engine 402 may communicate with nodes in clusters via core engine 408. Thus, according to Some implementations, core engine 408 arbitrates communication between inventory engine 402 and nodes in clusters in which one or more applications are deployed,” col. 7, lines 19 - 33].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta and Chopra available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta to include the capability of constraint-based upgrade and deployment as taught by Chopra, thereby providing a mechanism to enhance system efficiency by facilitating system upgrades based on system health measures.
12. As per claim 16, it is a system claim having similar limitations as cited in claim 1. Thus, claim 16 is also rejected under the same rationale as cited in the rejection of claim 1 above.
13. As per claim 21, it is a system claim having similar limitations as cited in claim 1. Thus, claim 21 is also rejected under the same rationale as cited in the rejection of claim 1 above.
14. Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta, Chopra and Pettersson in further view of Atkins et al. (U.S. Publication 2017/0078207) (Atkins hereinafter).
15. As per claim 2, Gupta, Chopra and Pettersson teach the system of claim 1. Gupta, Chopra and Pettersson do not explicitly disclose but Atkins discloses wherein constant node attributes of the second node include a node role indicator that indicates a role held by the second node within an infrastructure [“a plurality of nodes communicating with a network switch, each node transmitting a packet with a packet header that includes a value of a node-level attribute selected from a node utilization level, a node role, and a dependency involving the node, and the network switch receiving the packet and prioritizing transmission of the packet based on the value of the node-level attribute identified in the packet header,” ¶ 0017].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson and Atkins available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta, Chopra and Pettersson to include the capability of determining network node attributes and deployment as taught by Chopra, thereby providing a mechanism to enhance system efficiency by facilitating system upgrades based on system status information.
16. Claims 3 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta, Chopra and Pettersson in further view of Doshi et al. (U.S. Publication 2019/0340089) (Doshi hereinafter).
17. As per claim 3, Gupta, Chopra and Pettersson teach the system of claim 1. Gupta, Chopra and Pettersson do not explicitly disclose but Doshi discloses wherein one of the current values for the nonconstant node attributes of the second node is received from the second node in response to sending node executable code to the second node [“The remote recovery firmware 220 in the NIC 202 includes the physical address(es) for the location of critical data that is stored in the persistent memory 222 in the NVDIMM 208. The stored critical data can include transaction logs, file system change journals, lists/arrays/bitmaps describing which pages or blocks in a memory range are allocated.” ¶ 0029; “At block 404, during normal operation, the node 101a executes applications. While executing applications, node 101a asynchronously updates replicated data (for example, a copy of data sent from peer node(s) stored in remote state 314) and local state 312 (“critical state”) stored in non-volatile memory 308 over the network in one or more other node (a remote peer) 101b-d,” ¶ 0050].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson and Doshi available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta, Chopra and Pettersson to include the capability of remote execution of data and state collection code as taught by Doshi, thereby providing a mechanism to enhance system efficiency by facilitating system upgrades using remote system resources.
18. As per claim 18, it is a system claim having similar limitations as cited in claim 3. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of claim 3 above.
19. Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta, Chopra, Pettersson and Doshi in further view of Farrell et al. (U.S. Publication 2020/0133689) (Farrell hereinafter).
20. As per claim 4, Gupta, Chopra, Pettersson and Doshi teach the system of claim 3. Gupta, Chopra, Pettersson and Doshi do not explicitly disclose but Ferrell discloses wherein the first node is configured to: store a critical state database; obtain a plurality of test run results by performing a plurality of test runs of the critical state policy at each of the plurality of times; and store the test run results in the critical state database as a plurality of time series entries [“The timeseries database 205 records timeseries data on one or more states of the node 200. For example, in one embodiment, the timeseries database 205 receives data on a configuration state, an operational state, and telemetry of the node 200. The timeseries database 205 provides recorded data to the timeseries database 140 of FIG. 1. Users may query the timeseries database 205 to determine a state of the node 200.” ¶ 0030; “The timeseries database 140A stores sequential time stamped data. The time stamped data may include, for example, measurements of a configuration and/or operational state of a node within the cluster 110 taken at 60 second intervals,” ¶ 0027].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson, Doshi and Farrell available before the effective filing date of the claimed invention, to modify the capability of managing virtual machine resource allocation as disclosed by Gupta, Chopra, Pettersson and Doshi to include the capability of collecting and storing time series node status data as taught by Farrell, thereby providing a mechanism to enhance system efficiency and maintainability by providing historical status information in support of system health determinations.
21. Claims 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta, Chopra and Pettersson in further view of Mair et al. (U.S. Publication 2019/0369980) (Mair hereinafter).
22. As per claim 6, Gupta, Chopra and Pettersson teach the system of claim 1. Gupta, Chopra and Pettersson do not explicitly disclose but Mair discloses wherein the second node is configured to periodically provide one of the current values to the second node [“logs reflecting the operational characteristics of a cloud deployment may be captured . As also noted above, logs may be generated by a metrics collector that controls and/or manages a deployment. A deployment manager may be configured to generate logs that comply with one or more specifications such that the logs may be standardized, making them more efficient to process and/or analyze. Logs can be continuously or periodically pushed to an upgrade agent. In this way, relevant data can be kept live and as up-to-date as possible, although in other embodiments, an upgrade agent may continuously or periodically pull or request logs from the deployment manager. For example, the upgrade agent may pull or request logs based on a determined time period or other schedule. In some embodiments, the upgrade agent may pull or request logs when certain events occur, such as when an error or some threshold number of errors occurs, etc.” ¶ 0056].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson and Mair available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta, Chopra and Pettersson to include the capability of constraint-based upgrade and deployment as taught by Mair, thereby providing a mechanism to enhance system efficiency by facilitating system upgrades based on system health measures.
23. As per claim 17, it is a system claim having similar limitations as cited in claim 6. Thus, claim 17 is also rejected under the same rationale as cited in the rejection of claim 6 above.
24. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta, Chopra and Pettersson in further view of Kakarla et al. (U.S. Publication 2008/0222642) (Kakarla hereinafter).
25. As per claim 7, Gupta, Chopra and Pettersson teach the system of claim 1. Gupta, Chopra and Pettersson do not explicitly disclose but Kakarla discloses wherein the second node produces one of the current values for the nonconstant node attributes of the second node by executing node executable code in response to receiving the node executable code from the first node [“clusterware computer program comprising: a first programmatic interface to a resource type-specific clusterware agent, for receiving first resource type-specific code for discovering a new value of a particular attribute of a particular resource,” cl. 24; “Computer system 400 can send messages and receive data, including program code, through the network(s), network link 420 and communication interface 418. In the Internet example, a server 430 might transmit a requested code for an application program through Internet 428, ISP 426, local network 422 and communication interface 418,” ¶ 0056; “The received code may be executed by processor 404 as it is received, and/or stored in storage device 410, or other non-volatile storage for later execution.” ¶ 0057].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson and Kakarla available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta, Chopra and Pettersson to include the capability of remote execution of data and state collection code as taught by Kakarla, thereby providing a mechanism to enhance system efficiency by facilitating system upgrades using remote system resources.
26. Claims 8, 9, 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta, Chopra and Pettersson in further view of Cherian et al. (U.S. Patent 11,736,566) (Cherian hereinafter).
27. As per claim 8, Gupta, Chopra and Pettersson teach the system of claim 1. Gupta, Chopra and Pettersson do not explicitly disclose but Cherian discloses wherein a third node is a virtual machine (VM) running on the second node; a network interface card (NIC) installed in the second node, is configured to determine one of the current values for the nonconstant node attributes of the second node by running NIC executable code in response to receiving the NIC executable code from the first node [“FIG. 7 illustrates a VM 710 that executes on a smart NIC OS 700 to implement third party interface 725 (e.g., third party storage protocol) that is needed to access a third party external storage 712 and that is not natively provided by the smart NIC OS or the host OS. In this example, the third party storage interface 725 is part of an interface 520 for a HOU 715 of the smartNIC,” col. 9, lines 7 – 15; “The smart NIC in some embodiments is a system on chip (SoC) with a CPU, FPGA, memory, IO controller, a physical NIC, and other hardware components. The smart NIC has an operating system (OS) 120 that includes an NVMe driver 122 and a series of storage processing layers 124-127. The discussion below collectively refers to the software executing on the smart NIC as the smart NIC OS 120,” col. 5, lines 32 – 38]; and the NIC is configured to determine a third current value that is one of the current values for the nonconstant node attributes of the third node by executing the executable code on the NIC [“In addition to providing an emulation layer that creates and presents an emulated local storage to the set of programs on the host, the method of some embodiments has the NIC execute a DSAN service for the local storage to improve its operation and provide additional features for this storage. One example of a DSAN service is the vSAN service offered by VMware, Inc. The features of the DSAN service in some embodiments include (1) data efficiency processes, such as deduplication operations, compression operations, and thin provisioning, (2) security processes, such as end-to-end encryption, and access control operations, (3) data and life cycle management, such as storage vMotion, snapshot operations, snapshot schedules, cloning, disaster recovery, backup, long term storage, (4) performance optimizing operations, such as QoS policies (e.g., max and/or min I/O regulating policies), and (5) analytic operations, such as collecting performance metrics and usage data for virtual disk (IO, latency, etc.),” col. 7, lines 1 – 12].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson and Cherian available before the effective filing date of the claimed invention, to modify the capability of managing virtual machine resource allocation as disclosed by Gupta, Chopra and Pettersson to include the capability of collecting and storing status data via NIC code execution as taught by Cherian, thereby providing a mechanism to enhance system efficiency and maintainability by providing status information using existing infrastructure.
28. As per claim 9, Gupta and Chopra teach the system of claim 1. Gupta and Chopra do not explicitly disclose but Cherian discloses wherein a network interface card (NIC) is installed in the second node [“The smart NIC in some embodiments is a system on chip (SoC) with a CPU, FPGA, memory, IO controller, a physical NIC, and other hardware components. The smart NIC has an operating system (OS) 120 that includes an NVMe driver 122 and a series of storage processing layers 124-127. The discussion below collectively refers to the software executing on the smart NIC as the smart NIC OS 120,” col. 5, lines 32 – 38], a third node is a virtual machine (VM) running on the second node [“FIG. 7 illustrates a VM 710 that executes on a smart NIC OS 700 to implement third party interface 725 (e.g., third party storage protocol) that is needed to access a third party external storage 712 and that is not natively provided by the smart NIC OS or the host OS. In this example, the third party storage interface 725 is part of an interface 520 for a HOU 715 of the smartNIC,” col. 9, lines 7 - 15], and the NIC is configured to produce one of the current values for the nonconstant node attributes of the third node in response to receiving NIC executable code from the first node [“In addition to providing an emulation layer that creates and presents an emulated local storage to the set of programs on the host, the method of some embodiments has the NIC execute a DSAN service for the local storage to improve its operation and provide additional features for this storage. One example of a DSAN service is the vSAN service offered by VMware, Inc. The features of the DSAN service in some embodiments include (1) data efficiency processes, such as deduplication operations, compression operations, and thin provisioning, (2) security processes, such as end-to-end encryption, and access control operations, (3) data and life cycle management, such as storage vMotion, snapshot operations, snapshot schedules, cloning, disaster recovery, backup, long term storage, (4) performance optimizing operations, such as QoS policies (e.g., max and/or min I/O regulating policies), and (5) analytic operations, such as collecting performance metrics and usage data for virtual disk (IO, latency, etc.),” col. 7, lines 1 – 12].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson and Cherian available before the effective filing date of the claimed invention, to modify the capability of managing virtual machine resource allocation as disclosed by Gupta, Chopra and Pettersson to include the capability of collecting and storing status data via NIC code execution as taught by Cherian, thereby providing a mechanism to enhance system efficiency and maintainability by providing status information using existing infrastructure.
29. As per claim 11, Gupta and Chopra teach the system of claim 1. Gupta, Chopra and Pettersson do not explicitly disclose but Cherian discloses a network interface card (NIC) is installed in the second node; the critical state policy includes a NIC executable code that the NIC executes to determine one of the current values [“The smart NIC in some embodiments is a system on chip (SoC) with a CPU, FPGA, memory, IO controller, a physical NIC, and other hardware components. The smart NIC has an operating system (OS) 120 that includes an NVMe driver 122 and a series of storage processing layers 124-127. The discussion below collectively refers to the software executing on the smart NIC as the smart NIC OS 120,” col. 5, lines 32 – 38]; and the upgrade upgrades the NIC [“the host-computer hypervisor program and the smart NIC operating system received by the host computer are update programs for previously installed versions of the host-computer hypervisor program and the smart NIC operating system. After a host-computer hypervisor program and the smart NIC operating system are received, the host computer, in some embodiments, receives an additional program for updating the smart NIC operating system and provides the received program to the smart NIC for the smart NIC to update the smart NIC operating system,” col. 16, lines 16 – 26].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson and Cherian available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta, Chopra and Pettersson to include the capability of collecting and storing status data via NIC code execution as taught by Cherian, thereby providing a mechanism to enhance system efficiency and maintainability by providing status information using existing infrastructure.
30. As per claim 20, it is a system claim having similar limitations as cited in claim 11. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of claim 11 above.
31. Claims 10, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta, Chopra, Pettersson and Bektas et al. (U.S. Publication 2017/0153906) (Bektas hereinafter).
32. As per claim 10, Gupta, Chopra and Pettersson teach the system of claim 1. Gupta further teaches a current value for a nonconstant node attribute of the third node is used to determine the criticality state value of the second node [“The configuration server 202 may also include a health calculator 212. As described in detail below, the health calculator 212 may calculate a health for each network device 204. For example, the health calculator 212 may calculate a health score 214 for each network device 204, and may store the health scores 214 in the configuration server 202.” ¶ 0033; health calculator mapped to critical state policy, health score mapped to criticality state].
Gupta, Chopra and Pettersson do not explicitly disclose but Bektas discloses wherein the second node is running a third node that is a virtual machine (VM) [“The VM feedback clients 148 and 158 may also enable a user to determine a resource state for the virtual machines 140 and 150. The VM feedback clients 148 and 158 may include a resource state policy for the virtual machines 140 and 150. The resource state policies may establish a set of parameters defining one or more resource states for the virtual machines 140 and 150 based on a system resource utilization level for the virtual machines. For example, the resource state policy for the first virtual machine 140 may indicate that the virtual machine is in a critical resource state if the utilization level of any system resource (e.g., CPU, memory, or storage) exceeds 95% of the allocated amount of that system resource for a period of more than 5 minutes,” ¶ 0029; VM mapped to third node].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson and Bektas available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta, Chopra and Pettersson to include the capability of managing virtual machine resource allocation as disclosed by Bektas, thereby providing a mechanism to enhance system efficiency by facilitating system upgrades based on remote identifiers.
33. As per claim 13, Gupta, Chopra and Pettersson teach the system of claim 1. Chopra further teaches the nodes are upgraded only when the nodes can be taken offline without disrupting critical operations according to the critical state policies [“A rule, such as Rule 3, may determine an order in which nodes are upgraded based on their current operational status. For example, passive nodes may be upgraded first, and then active nodes may be taken offline and upgraded. As similarly discussed above, in a cluster that implements load balancing and failover capabilities, all nodes can't be taken offline and upgraded at the same time without disrupting functionality of software executing in the cluster. Therefore, by selectively upgrading identified passive nodes first and then upgrading active nodes, all nodes in a cluster may be upgraded, and functionality of software executing in the cluster is not disrupted,” col. 15, lines 39 – 51; identified passive nodes mapped to determined critical state value].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta and Chopra available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta to include the capability of constraint-based upgrade and deployment as taught by Chopra, thereby providing a mechanism to enhance system efficiency by facilitating system upgrades based on system health measures.
Gupta, Chopra and Pettersson do not explicitly disclose but Bektas discloses wherein the first node is configured to upgrade a plurality of nodes that are identified by a plurality of node identifiers [“The VMID may be a unique identifier assigned to the virtual machines that sent the message. The VMID may be an IP address (particularly if static IP addresses are used), a media access control (MAC) address, or any other identifier used to determine which virtual machine sent the message. The requested system resource type may indicate the system resource (or resource entitlement) for which the message requests an adjustment,” ¶ 0085]; and
the first node stores a plurality of critical state policies corresponding to the nodes [“The VM feedback clients 148 and 158 may also enable a user to determine a resource state for the virtual machines 140 and 150. The VM feedback clients 148 and 158 may include a resource state policy for the virtual machines 140 and 150. The resource state policies may establish a set of parameters defining one or more resource states for the virtual machines 140 and 150 based on a system resource utilization level for the virtual machines. For example, the resource state policy for the first virtual machine 140 may indicate that the virtual machine is in a critical resource state if the utilization level of any system resource (e.g., CPU, memory, or storage) exceeds 95% of the allocated amount of that system resource for a period of more than 5 minutes,” ¶ 0029; VM mapped to node].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson and Bektas available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta, Chopra and Pettersson to include the capability of managing virtual machine resource allocation as disclosed by Bektas, thereby providing a mechanism to enhance system efficiency by facilitating system upgrades based on remote identifiers.
34. As per claim 19, it is a system claim having similar limitations as cited in claim 10. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of claim 10 above.
35. Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta, Chopra and Pettersson in further view of Peng et al. (U.S. Publication 2014/0040895) (Peng hereinafter) and Dao et al. (U.S. Publication 2018/0262924) (Dao hereinafter).
36. As per claim 12, Gupta, Chopra and Pettersson teach the system of claim 1. Gupta, Chopra and Pettersson do not explicitly disclose but Peng discloses wherein the current values for the nonconstant node attributes of the second node include a CPU usage statistic, a memory usage statistic, a non-volatile memory input/output statistic and a process identifier that identifies a process running on the second node [“The control server 2 stores the usage rates of the specified resources of the virtual machines into different data tables in the database servers 3 according to a name of each virtual machine. For example, the usage rates of the specified resources of VM 41 are stored in a first data sheet "41", and the usage rates of the specified resources of VM 42 are stored in a second data sheet "42." The data sheet includes a plurality of columns, such as a name of the virtual machine, an identifier (ID) of the virtual machine, a CPU usage rate, a memory usage rate, and a hard disk usage rate of the virtual machine, and a storing time of the usage rates of the specified resources.” ¶ 0015].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson and Peng available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta, Chopra and Pettersson to include the capability of allocating resources for VMs as taught by Peng, thereby providing a mechanism to enhance system efficiency and maintainability by providing specific status information in support of resource allocation.
Gupta, Chopra, Pettersson and Peng do not explicitly disclose but Dao discloses wherein the current values include a long-lived network session statistic and a short-lived network session statistic [“To determine whether a traffic flow is short-lived or long-lived, the NWDA 237 may rely on a known popularity of a content streaming service such as a video streaming service or an operator video service. Another feature that may be used to determine whether a traffic flow is short-lived or long-lived, includes using a measured threshold, obtained from the measured session time statistics, to classify video sessions as either long-lived or short-lived. For example, the threshold (measured in seconds) may take into account a portion of a number of video flows, which consume the radio resources and network resources,” ¶ 0081].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson, Peng and Dao available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta, Chopra, Pettersson and Peng to include the capability of network policy optimization as taught by Dao, thereby providing a mechanism to enhance system efficiency and maintainability by providing specific status information in support of network resource allocation.
37. Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Gupta, Chopra, Pettersson and Bektas in further view of Farrell and Gross et al. (U.S. Publication 2017/0075677) (Gross hereinafter).
38. As per claim 14, Gupta, Chopra, Pettersson and Bektas teach the system of claim 13. Gupta, Chopra, Pettersson and Bektas do not explicitly disclose but Ferrell discloses wherein: the first node is configured to: produce criticality state time series data that indicates the criticality state of each of the nodes as a function of time [“The timeseries database 205 records timeseries data on one or more states of the node 200. For example, in one embodiment, the timeseries database 205 receives data on a configuration state, an operational state, and telemetry of the node 200. The timeseries database 205 provides recorded data to the timeseries database 140 of FIG. 1. Users may query the timeseries database 205 to determine a state of the node 200.” ¶ 0030; “The timeseries database 140A stores sequential time stamped data. The time stamped data may include, for example, measurements of a configuration and/or operational state of a node within the cluster 110 taken at 60 second intervals,” ¶ 0027].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson, Bektas and Farrell available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta, Chopra, Pettersson and Bektas to include the capability of collecting and storing time series node status data as taught by Farrell, thereby providing a mechanism to enhance system efficiency and maintainability by providing historical status information in support of system health determinations.
Gupta, Chopra, Pettersson, Bektas and Farrell do not explicitly disclose but Gross discloses determine upgrade windows for the nodes; and upgrade the nodes based on the upgrade windows [“If a number of network devices 1806 at the parent nodes (e.g., satisfying a threshold) have a more up-to-date version of the software update 1960 then the current network device can request the software update (e.g., from one of the polled network devices at the parent nodes) and can trigger an update during the next maintenance window.” ¶ 0191].
It would have been obvious to one of ordinary skill in the art, having the teachings of Gupta, Chopra, Pettersson, Bektas, Farrell and Gross available before the effective filing date of the claimed invention, to modify the capability of determining network node health status as disclosed by Gupta, Chopra, Pettersson, Bektas and Farrell to include the capability of distributing software updates as taught by Gross, thereby providing a mechanism to enhance system efficiency and maintainability by coordinating system software updates within specified time windows.
Allowable Subject Matter
39. Claim 15 is 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, and to overcome the 101 subject matter eligibility rejection recited above
Response to Arguments
Claim Rejections - 35 USC § 103
40. Applicant's arguments have been fully considered but they are not persuasive.
41. Regarding applicant’s arguments on pages 12 and 13 as to Gupta in light of the noted amended claim language, the arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
42. Regarding applicant’s arguments on pages 13 and 14, the reference to operations performed by the ranking calculator is not understood.
Claim Rejections - 35 USC § 112
43. Applicant's arguments have been fully considered but they are not persuasive.
44. Applicant’s mapping of the noted claim terms is not contained or disclosed in the specification nor can the terms be reasonably said to be implicitly or inherently set forth in the written description of the specification.
Claim Rejections - 35 USC § 101
45. Applicant's arguments have been fully considered but they are not persuasive.
46. As is recited above, the noted executable code limitation is an algorithm step performed by a generic computing system and is identified as extra-solution activity, not an abstract idea. Additionally, executable code can be created, compiled and executed as a mental process. As recited above, the judicial exception is not integrated into a practical application for the reasons stated.
Conclusion
47. Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM C WOOD whose telephone number is (571)272-5285. The examiner can normally be reached Monday - Friday, 8:00 am - 4:30 pm.
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, Chat C Do can be reached at 571-272-3721. 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.
/WILLIAM C WOOD/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193