DETAILED ACTION
This action is responsive to communications filed 22 January 2026.
Claims 1-24 are subject to examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
The objections to the claims have been withdrawn in view of amendments.
Applicant’s 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.
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.
Claim(s) 1, 6, 11-13, 20 and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US-12242350-B2) hereinafter Chen in view of Gleichauf (US-11245671-B2).
Regarding claim 1, Chen discloses:
A programmable networking device for upgrading network objects in a network ([14:1-16] electronic device, which may perform at least some of the operations in the update techniques) comprising:
processing circuitry ([14:1-16] processing subsystem) configured to:
receive, via a network interface ([14:1-16] networking subsystem), an upgrade request to upgrade a target node in the network ([10:15-30] provide a set of operations (SOO; i.e. upgrade request) associated with an update to controller software of a controller of a network to a controller node (such as node 310-1) … provide the set of operations to nodes … 310-2 and node 310-3 (i.e. target nodes), see [FIG. 3]);
identify building blocks of a package installed on the target node to be upgraded ([7:22-31] perform the set of operations associated with the update of the controller software (i.e. determined that the controller software is to be updated; i.e. building block) [8:41-54] restoring the multiple nodes to a state prior to the update or to a known state (such as a state associated with a previous version of the controller software; i.e. state backup that is stored to be used in restoring requires that the controller software is identified as the building blocks to be updated/restored)m see also [13:43-48] new image of the controller software);
store a state backup of the building blocks ([8:16-54] previous version of the software (such as a backup image; i.e. stored state backup of the building blocks, e.g. controller software as above) … restoring the multiple nodes to a state prior to the update or to a known state (such as a state associated with a previous version of the controller software; i.e. state backup that is stored to be used in restoring));
transmit, via the network interface ([14:1-16] networking subsystem), an upgrade command and an upgrade payload to the target node ([10:15-30] instruct interface circuit to provide the set of operations (i.e. upgrade command) to nodes … 310-2 and node 310-3 (i.e. target nodes), see [FIG. 3], see also [13:43-48] new image of the controller software (i.e. upgrade payload, a software update is a new image));
query the target node to obtain a status of the target node ([13:57-67] user interface may be used to update a user regarding an update status (e.g. of nodes 310-2 and 310-3 as above would require i.e. to query them for their statuses));
determine an upgrade action based on the status ([13:49-56] after a successful update, the post-update operation may include eliminating or deactivating the agents in the nodes, see also [13:5-17] update may fail … handle the automatic recovery of nodes (i.e. actions determined on success or fail)); and
cause the upgrade action to be executed on the target node ([13:49-56] eliminating or deactivating the agents in the nodes, see also [13:5-17] handle the automatic recovery of nodes (i.e. in view of failed update)).
Chen does not explicitly disclose:
wherein the programmable networking device and the target edge node are members of a security island comprising a collection of edge nodes having a trust relationship established through mutual authentication;
upgrade a target edge node in the edge network.
However, Gleichauf discloses:
wherein the programmable networking device and the target edge node are members of a security island comprising a collection of edge nodes having a trust relationship established through mutual authentication ([2:32-48] proxy node being any device, within communication range of the edge node that has the required functions to perform the more complex functions on behalf of the edge node (i.e. programmable networking device [8:24-9:4] edge node and the proxy node are paired using known mutual authorization techniques and a security association is established … mutual trust, see [21:51-56] proxy node comprises a plurality of isolated areas, each isolated area associated with one or more of said at least one edge nodes of the same type … provide application, security and update functions for multiple different types of edge nodes, see [FIG. 1] [FIG. 10] e.g. proxy nodes and paired edge nodes, i.e. security islands of mutually authenticated edge nodes with the proxy node);
upgrade a target edge node in the edge network ([4:13-29] updates for many different types of edge nodes/different edge nodes … isolated area for each different type of edge node, so that an update which is run for a first type of edge node, is run in isolation, it does not update the other types of edge nodes (i.e. target edge node)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen in view of Gleichauf to have the programmable networking device and the target edge node are members of a security island comprising a collection of edge nodes having a trust relationship established through mutual authentication and update a target edge node in the edge network. One of ordinary skill in the art would have been motivated to do so to protect at least one edge node in a network of nodes and to provide more complex functions delegated to a proxy node to minimize costs (Gleichauf, [1:9-67] [3:54-65]).
Regarding claim 6, Chen-Gleichauf disclose:
The programmable networking device of claim 1, further comprising processing circuitry, set forth above, configured to:
Chen discloses:
determine that the upgrade command has timed out ([7:44-59] completion message is not received within a predefined time interval (i.e. upgrade command has timed out because it is not completed)); and
perform a rollback of a building block using the state backup ([7:44-59] automatically recover the multiple nodes [8:16-40] recover the nodes back to the previous version of the software (such as a backup image)), wherein the status includes a failure indicator for the building block ([13:57-67] update status … include information specifying update failures and recovery information).
Regarding claim 11, Chen-Gleichauf disclose:
The programmable networking device of claim 1, set forth above,
Chen discloses:
wherein the state backup of the building blocks includes rollback data to restore a current building block in event of a failed upgrade attempt ([7:44-59] automatically recover the multiple nodes [8:16-40] recover the nodes back to the previous version of the software (such as a backup image; i.e. rollback data to restore the building block)).
Regarding claim 12, Chen-Gleichauf disclose:
The programmable networking device of claim 1, set forth above,
Chen discloses:
wherein the upgrade action executes the upgrade command ([13:49-56] eliminating or deactivating the agents in the nodes (i.e. in view of successful update)), performs a rollback of previously installed building blocks using the state backup ([13:5-17] update may fail … handle the automatic recovery of nodes [8:16-40] recover the nodes back to the previous version of the software (such as a backup image; i.e. rollback data to restore the building block)), set a failover flag, or delete a stored failover request.
Regarding claims 13 and 20, they do not further define nor teach over the limitations of claim 1, therefore, claims 13 and 20 are rejected for at least the same reasons set forth above as in claim 1.
Regarding claim 22, it does not further define nor teach over the limitations of claim 6, therefore, claim 22 is rejected for at least the same reasons set forth above as in claim 6.
Claim(s) 2-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US-12242350-B2) hereinafter Chen in view of Gleichauf (US-11245671-B2) further in view of Shelke et al. (US-11645158-B2) hereinafter Shelke.
Regarding claim 2, Chen-Gleichauf disclose:
The programmable networking device of claim 1, set forth above,
Chen-Gleichauf do not explicitly disclose:
wherein the upgrade request includes an upgrade identifier.
However, Shelke discloses:
wherein the upgrade request includes an upgrade identifier ([9:49-10:16] user instructs the upgrade coordinator to initiate an upgrade … using the edge NUB, see [8:44-63] upgrade bundle … may be a signed image … edge node upgrade bundle (NUB) may include a virtual machine disk (VMDK) file that has OS and kernel images … upgrade script to perform a local upgrade … migration script used for the migration of existing configuration … (i.e. edge NUB is the upgrade identifier, e.g. which image to upgrade to)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen-Gleichauf in view of Shelke to have the upgrade request include an upgrade identifier. One of ordinary skill in the art would have been motivated to do so to use an upgrade bundle which may be a signed image and may include a VMDK file that has OS and kernel images as well as scripts for the upgrade, migration, and rollback (Shelke, [8:44-63] [9:49-10:16]).
Regarding claim 3, Chen-Gleichauf disclose:
The programmable networking device of claim 1, set forth above,
Chen discloses:
further comprising processing circuitry configured to obtain upgrade metadata that includes the upgrade command, and the upgrade payload ([10:15-30] instruct interface circuit to provide the set of operations (i.e. upgrade command) to nodes 310 (i.e. identifying nodes to be provided) … 310-2 and node 310-3 (i.e. target nodes), see [FIG. 3], see also [13:43-48] new image of the controller software (i.e. upgrade payload, a software update is a new image)).
Chen does not explicitly disclose:
obtain upgrade metadata that includes an identifier of the target edge node.
However, Shelke discloses:
obtain upgrade metadata that includes an identifier of the target edge node ([2:38-3:13] perform a rollback in a logical overlay network … may include … edge(s) (i.e. edge network) … types of nodes: … edges (i.e. edge node) … upgrade is performed in a logical overlay network … from a source version to a target version [14:16-29] node ID (i.e. edge node ID)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen in view of Shelke to have identified an edge node. One of ordinary skill in the art would have been motivated to do so to perform upgrades in a logical overlay network having edges and more effectively and efficiently perform a rollback in a logical overlay network with components of an edge where elements reside on three types of nodes including edge nodes (Shelke, [2:38-3:13]).
Regarding claim 4, Chen-Gleichauf disclose:
The programmable networking device of claim 1, set forth above,
Chen-Gleichauf do not explicitly disclose:
wherein the building blocks are identified from the upgrade command.
However, Shelke discloses:
wherein the building blocks are identified from the upgrade command ([9:49-10:16] user instructs the upgrade coordinator to initiate an upgrade … using the edge NUB, see [8:44-63] upgrade bundle … may be a signed image … edge node upgrade bundle (NUB) may include a virtual machine disk (VMDK) file that has OS and kernel images … upgrade script to perform a local upgrade … migration script used for the migration of existing configuration … (i.e. edge NUB is the upgrade identifier, e.g. which image to upgrade to that identifies the building blocks; images)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen-Gleichauf in view of Shelke to have building blocks identified from the upgrade command. One of ordinary skill in the art would have been motivated to do so to use an upgrade bundle which may be a signed image and may include a VMDK file that has OS and kernel images as well as scripts for the upgrade, migration, and rollback (Shelke, [8:44-63] [9:49-10:16]).
Claim(s) 5, 14, 16-19 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US-12242350-B2) hereinafter Chen in view of Gleichauf (US-11245671-B2) further in view of Guim Bernat et al. (US-20210021533-A1) hereinafter Bernat.
Regarding claim 5, Chen-Gleichauf disclose:
The programmable networking device of claim 1, further comprising processing circuitry, set forth above, configured to:
Chen discloses:
transmit a request to upgrade to the target node ([10:15-30] provide a set of operations (SOO; i.e. upgrade request) associated with an update to controller software of a controller of a network to a controller node (such as node 310-1) … provide the set of operations to nodes … 310-2 and node 310-3 (i.e. target nodes), see [FIG. 3]),
Chen does not explicitly disclose:
authenticate the target edge node; and
wherein the building blocks are identified upon receipt of a positive response to the request to upgrade.
However, Bernat discloses:
authenticate the target edge node ([0130] validate the identity and authenticity of the edge device 1105); and
wherein the building blocks are identified upon receipt of a positive response to the request to upgrade ([0130] mutual attestation may be employed so that the parties to a transaction may ensure mutual trust … sending the data is authentic, see [0063] offer, transmit, and/or force updates … patches, updates, etc. are distributed and applied … libraries, plug-ins, components, and other types of compute modules (i.e. building blocks)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen in view of Bernat to have authenticated the target edge node and identify building blocks upon a receipt of a positive response to the request to upgrade the target edge node. One of ordinary skill in the art would have been motivated to do so to ensure mutual trust such that the sending of the data is authentic (Bernat, [0130]).
Regarding claims 14 and 21, they do not further define nor teach over the limitations of claim 5, therefore, claims 14 and 21 are rejected for at least the same reasons set forth above as in claim 5.
Regarding claim 16, Chen-Gleichauf disclose:
The at least one non-transitory machine-readable medium of claim 13, set forth above,
Chen-Gleichauf do not explicitly disclose:
wherein the target edge node and an upgrade edge node that causes the upgrade action to be executed on the target edge node are part of a collection of edge nodes that have a trust relationship.
However, Bernat discloses:
wherein the target edge node and an upgrade edge node that causes the upgrade action to be executed on the target edge node are part of a collection of edge nodes that have a trust relationship ([0130] mutual attestation … may ensure mutual trust … ‘web-of-trust’ relationships … facing decisions about whether or not a device is allowed to forward content (i.e. trusted devices in mutual attestation ensure mutual trust to be allowed to forward content)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen-Gleichauf in view of Bernat to have the target edge node and an upgrade edge node be part of a collection of edge nodes that have a trust relationship. One of ordinary skill in the art would have been motivated to do so to ensure mutual trust when facing decisions about whether or not a device is allowed to forward content (Bernat, [0130]).
Regarding claim 17, Chen-Gleichauf-Bernat disclose:
The at least one non-transitory machine-readable medium of claim 16, set forth above,
Chen-Gleichauf do not explicitly disclose:
wherein the trust relationship is established with a temporary upgrade trust domain.
However, Bernat discloses:
wherein the trust relationship is established with a temporary upgrade trust domain ([0106] one security domain to another … new security credential is proactively established (i.e. temporary as new credentials are established based on crossing security domains) … transferred ahead of time to any data forwarding services in the current EP so that the current EP can forward any data that is properly encrypted or otherwise protected against tampering by that new security credential).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen-Gleichauf in view of Bernat to have the trust relationship established with a temporary upgrade trust domain. One of ordinary skill in the art would have been motivated to do so to proactively establish security credentials (Bernat, [0106]).
Regarding claim 18, Chen-Gleichauf-Bernat disclose:
The at least one non-transitory machine-readable medium of claim 16, set forth above,
Chen-Gleichauf do not explicitly disclose:
wherein the trust relationship is established with an upgrade trust domain, and wherein the target edge node is a member of a service delivery trust domain.
However, Bernat discloses:
wherein the trust relationship is established with an upgrade trust domain ([0106] one security domain to another … new security credential is proactively established (i.e. temporary as new credentials are established based on crossing security domains) … transferred ahead of time to any data forwarding services in the current EP so that the current EP can forward any data that is properly encrypted or otherwise protected against tampering by that new security credential), and wherein the target edge node is a member of a service delivery trust domain ([0130] mutual attestation … may ensure mutual trust … ‘web-of-trust’ relationships … facing decisions about whether or not a device is allowed to forward content (i.e. trusted devices in mutual attestation ensure mutual trust to be allowed to forward content)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen-Gleichauf in view of Bernat to have the trust relationship established with an upgrade trust domain and wherein the target edge node is a member of a service delivery trust domain. One of ordinary skill in the art would have been motivated to do so to ensure mutual trust when facing decisions about whether or not a device is allowed to forward content (Bernat, [0130]).
Regarding claim 19, Chen-Gleichauf-Bernat disclose:
The at least one non-transitory machine-readable medium of claim 16, set forth above,
Chen-Gleichauf do not explicitly disclose:
wherein the trust relationship is formed on trust domain extensions (TDX), software guard extensions (SGX), or hardware security extensions.
However, Bernat discloses:
wherein the trust relationship is formed on trust domain extensions (TDX), software guard extensions (SGX) ([0094] SGX), or hardware security extensions ([0094] hardware security extensions).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen-Gleichauf in view of Bernat to have the trust relationship formed on SGX or hardware security extensions. One of ordinary skill in the art would have been motivated to do so to implement security hardening, hardware roots-of-trust and trusted or protected operations (Bernat, [0094]).
Claim(s) 7, 15 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US-12242350-B2) hereinafter Chen in view of Gleichauf (US-11245671-B2) further in view of Aranha et al. (US-8868504-B2) hereinafter Aranha.
Regarding claim 7, Chen-Gleichauf disclose:
The programmable networking device of claim 1, further comprising processing circuitry, set forth above, configured to:
Chen-Gleichauf do not explicitly disclose:
transmit a failover request to a failover node of the edge network, wherein the failover request includes an upgrade identifier and an identifier of the target edge node;
set a failover flag for the upgrade of the target edge node;
determine that the upgrade has completed; and
reset the failover flag.
However, Aranha discloses:
transmit a failover request to a failover node of the edge network ([32:8-30] changing the replication state of the “standby” node to active (“SET REP STATE TO ACTIVE”)), wherein the failover request includes an upgrade identifier and an identifier of the target edge node ([32:31-48] “standby” node is table to take over various activities of the “active” node (“TAKE OVER CLIENT UPDATES” … etc.) … updates 175 … redirected to the “standby” node [9:46-67] by using the particular MUL locator, the master node (or, in some embodiments, another node acting for the master node (i.e. failover node)) is able to identify all updates (i.e. upgrade identifier) in the MUL subsequent to the update associated with the particular MUL locator, and to send those updates to the particular node to synchronize the particular node (i.e. to send to a particular node requires to identify the particular node to be sent updates));
set a failover flag for the upgrade of the target edge node ([26:50-67] some state transitions are illustrated for a respective replication state of the active node and the standby node … (“SET REP STATE TO ACTIVE”; i.e. flag for failover of active node to standby node having the standby node as active for the update));
determine that the upgrade has completed ([28:15-26] transitions from replication states of active or standby to idle occur … when the standby node becomes the active node after failure, see [30:1-22] standby node is now able to take over the certain tasks from the active node … write-through to the replica nodes … and other tasks … the standby node then assumes the standby role, and is operational as a standby for the active node, see also [15:59-16:7] commit records, are no longer necessary when written-through updates corresponding to the commit records have been acknowledged by all of the ones of the nodes that are configured to receive the written-through updates (i.e. written-through from the standby)); and
reset the failover flag ([29:63-67] (“SET REP STATE TO STANDBY”)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen-Gleichauf in view of Aranha to have transmitted a failover request to a failover node of the edge network, including an upgrade identifier and identifier of the target edge node to set a failover flag for the upgrade of the target edge node, determine completion of the upgrade and reset the flag. One of ordinary skill in the art would have been motivated to do so to provide an active node and a standby node that increases availability in that either one of the active node or the standby node can fail and the surviving node is able to continue operating (Aranha, [4:17-47]).
Regarding claims 15 and 23, they do not further define nor teach over the limitations of claim 7, therefore, claims 15 and 23 are rejected for at least the same reasons set forth above as in claim 7.
Claim(s) 8-9 and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US-12242350-B2) hereinafter Chen in view of Gleichauf (US-11245671-B2) further in view of Aranha et al. (US-8868504-B2) hereinafter Aranha further in view of Guim Bernat et al. (US-20210021533-A1) hereinafter Bernat.
Regarding claim 8, Chen-Gleichauf disclose:
The programmable networking device of claim 1, set forth above
Chen-Gleichauf do not explicitly disclose:
wherein the upgrade request is a failover request transmitted by an upgrade edge node of the edge network and further comprising processing circuitry configured to:
authenticate the upgrade edge node;
store the failover request; and
monitor an attempt by the upgrade edge node to perform the upgrade, wherein identification of the building blocks of the package installed on the target edge node to be upgraded is executed upon determination that the attempt by the upgrade edge node to perform the upgrade has failed.
However, Aranha discloses:
wherein the upgrade request is a failover request transmitted by an upgrade edge node of the edge network ([32:8-30] changing the replication state of the “standby” node to active (“SET REP STATE TO ACTIVE”) [32:31-48] “standby” node is table to take over various activities of the “active” node (“TAKE OVER CLIENT UPDATES” … etc.) … updates 175 … redirected to the “standby” node [9:46-67] by using the particular MUL locator, the master node (or, in some embodiments, another node acting for the master node (i.e. failover node)) is able to identify all updates (i.e. upgrade identifier) in the MUL subsequent to the update associated with the particular MUL locator, and to send those updates to the particular node to synchronize the particular node (i.e. to send to a particular node requires to identify the particular node to be sent updates)) and further comprising processing circuitry configured to:
store the failover request ([26:50-67] some state transitions are illustrated for a respective replication state of the active node and the standby node … (“SET REP STATE TO ACTIVE”; i.e. flag for failover of active node to standby node having the standby node as active for the update is to store the request, e.g. failover state saved)); and
monitor an attempt by the upgrade edge node to perform the upgrade ([6:10-21] when either the active node or the standby node fails (i.e. failover node is monitored to be successful or fail) … system is able to determine how far behind a failed node is compared to the surviving node (i.e. to determine a failed node is to monitor the node for failure)), wherein identification of the building blocks of the package installed on the target edge node to be upgraded is executed upon determination that the attempt by the upgrade edge node to perform the upgrade has failed ([6:10-21] storing the commit ticket numbers (with other update-related information) in a transaction log … the failed node is synchronizable with the surviving node without having to copy the entire state of the surviving node (i.e. failed node and surviving node have the commit numbers and update-related information stored to be identified from the logs)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen-Gleichauf in view of Aranha to have the upgrade request be a failover request, store the failover request, and monitor an attempt by the upgrade edge node to perform the upgrade wherein identifying the building blocks upon determination that the upgrade has failed. One of ordinary skill in the art would have been motivated to do so to provide an active node and a standby node that increases availability in that either one of the active node or the standby node can fail and the surviving node is able to continue operating (Aranha, [4:17-47]).
Chen-Gleichauf-Aranha do not explicitly disclose:
authenticate the upgrade edge node;
However, Bernat discloses:
authenticate the upgrade edge node ([0130] validate the identity and authenticity of the edge device 1105); and
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen-Gleichauf-Aranha in view of Bernat to have authenticated the upgrade edge node. One of ordinary skill in the art would have been motivated to do so to ensure mutual trust such that the sending of the data is authentic (Bernat, [0130]).
Regarding claim 9, Chen-Gleichauf-Aranha-Bernat disclose:
The programmable networking device of claim 8, set forth above,
Chen discloses:
further comprising processing circuitry configured to determine that a timeout period has elapsed for receipt of a status update from the upgrade node ([7:44-59] completion message is not received within a predefined time interval (i.e. upgrade command has timed out because it is not completed)); and
Chen does not explicitly disclose:
wherein the processing circuitry configured to determine that the attempt by the upgrade edge node to perform the upgrade has failed.
However, Aranha discloses:
wherein the processing circuitry configured to determine that the attempt by the upgrade edge node to perform the upgrade has failed ([6:10-21] when either the active node or the standby node fails (i.e. failover node is monitored to be successful or fail) … system is able to determine how far behind a failed node is compared to the surviving node (i.e. to determine a failed node is to monitor the node for failure)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen in view of Aranha to have a determination that the upgrade has failed. One of ordinary skill in the art would have been motivated to do so to provide an active node and a standby node that increases availability in that either one of the active node or the standby node can fail and the surviving node is able to continue operating (Aranha, [4:17-47]).
Regarding claim 24, it does not further define nor teach over the limitations of claim 8, therefore, claim 24 is rejected for at least the same reasons set forth above as in claim 8.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US-12242350-B2) hereinafter Chen in view of Gleichauf (US-11245671-B2) further in view of Horowitz et al. (US-10489357-B2) hereinafter Horowitz further in view of Lebsack et al. (US-11496596-B2) hereinafter Lebsack.
Regarding claim 10, Chen-Gleichauf disclose:
The programmable networking device of claim 1, further comprising processing circuitry, set forth above, configured to:
Chen-Gleichauf do not explicitly disclose:
identify the building blocks upon a determination that there a no critical workloads executing on the target edge node; and
prevent the target edge node from accepting critical workloads until the status indicates the upgrade has completed.
However, Horowitz discloses:
identify the building blocks upon a determination that there a no critical workloads executing on the target edge node ([17:37-18:45] checks known states that cannot be upgraded, etc. and returns a pass fail parameter … if pass continue, start operation on single node, post to board active upgrade … upgrade authentication model for node … download new database binaries … wait for each database server process to exit on completion … update each database server process, one at a time … shut down the database manager … replace the database manager … with the new version … restart (i.e. identifying binaries when it is compatible state that can be upgraded, to disable balancers and processes to update to new binaries)); and
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen-Gleichauf in view of Horowitz to have identified building blocks upon a determination that there are no critical workloads executing on the target edge node. One of ordinary sill in the art would have been motivated to do so to check known states that cannot be upgraded (Horowitz, [17:37-18:45]).
Chen-Gleichauf-Horowitz do not explicitly disclose:
prevent the target edge node from accepting critical workloads until the status indicates the upgrade has completed.
However, Lebsack discloses:
prevent the target edge node from accepting critical workloads until the status indicates the upgrade has completed ([2:54-63] during an update operation on a target data node, impose a write lock on the target data node, the write lock preventing any other process from reading from or modifying the target data node during the update operation).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Chen-Gleichauf-Horowitz in view of Lebsack to have prevented the target node from accepting critical workloads until the status indicates the upgrade has completed. One of ordinary skill in the art would have been motivated to do so to prevent processes from reading/modifying target data node during update operations (Lebsack, [2:54-63]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Quilty (US-20090119655-A1) UPGRADING SOFTWARE IN RADIO BASE STATION NODES;
Gupta et al. (US-10642507-B2) PULSED LEADER CONSENSUS MANAGEMENT;
Dharap et al. (US-20090037899-A1) RADIO FREQUENCY IDENTIFICATION (RFID) NETWORK UPGRADE SYSTEM AND METHOD;
Guo (US-20250119345-A1) EDGE NODE CONTROL METHOD BASED ON CLOUD COMPUTING TECHNOLOGY AND CLOUD MANAGEMENT PLATFORM.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Alex Tran whose telephone number is (571)272-8173. The examiner can normally be reached Monday-Friday 10AM-6PM ET.
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, Kamal Divecha can be reached at (571)272-5863. 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.
/Alex Tran/Primary Examiner, Art Unit 2453
Prosecution Insights