DETAILED ACTION
This Action is responsive to the RCE filed on 01/13/2026.
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 .
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 01/13/2026 has been entered.
Claim Status
Claims 1-20 are amended. Claims 1-20 are pending and have been examined.
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.
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.
Claims 1-2, 6-9, 13-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Thakare et al. (US 20240160354 A1)(cited by examiner in previous action)(hereafter referred to as Thakare) further in view of a 2023 online public disclosure authored by Uchenna (published 11/06/2023)(titled “Kubernetes Readiness Probe: A Simple Guide with Examples”)(accessed by examiner via Wayback Machine)(hereafter referred to as Uchenna).
Regarding Claim 1,
Thakare discloses the following limitations:
A method comprising:
receiving (Fig. 4, steps 402 + 404) an update (“a node image upgrade” [0036]) for a first node (“a node 120 with an old node image” [0036]) of a cluster of compute nodes (Target Environment 110, Fig. 1 // “At step 402, an image upgrade controller 150 waits for a trigger event that indicates that a node image upgrade should be performed for nodes 120 … At step 404, image upgrade controller 150 selects a node 120 with an old node image” [0036]);
generating (Fig. 4, steps 405 + 406), by a processing device (Image Upgrade Controller 150, Fig. 1), a second node (“a new node 120” [0036]) comprising the update for the first node, wherein the second node is generated based on an image (“the new node image 165” [0037]) comprising the update for the first node (“image upgrade controller 150 then proceeds to step 405 in which it communicates with a deployment system to create/deploy a new node 120 … at step 406, image upgrade controller 150 determines whether a new node 120 running the new node image 165 has been spun up.” [0036-37]);
copying (Fig. 4, step 410) data from the first node to the second node (“At step 410, image upgrade controller 150 begins copying data from the old node 120 to the new node 120” [0037]); and
in response to completion of copying the data (Fig. 4, step 412 ‘Yes’), replacing (Fig. 4, step 414) the first node in the cluster with the second node (“At step 414, image upgrade controller 150 evicts the set of pods 130 from the old node 120 and then scales the node down” [0038])
Although Thakare Fig. 3C // ¶0034 discloses that applications running on the old node are deployed onto the new node, and further that the new node is transitioned from “a read-only mode” to “a write mode” after deploying applications onto the new node, Thakare is silent regarding the following limitations:
exposing a readiness endpoint of the second node to indicate connection of the second node to the cluster, wherein the readiness endpoint of the second node provides a message to at least one node of the cluster that indicates availability of the second node to receive traffic, wherein a readiness endpoint of the first node is updated as no longer operational and to be removed from the cluster.
However, Uchenna discloses within the context of monitoring node health in a distributed storage cluster environment that a “Readiness Probe” running on each given pod of a cluster indicates whether or not the given pod is ready to receive traffic.
Uchenna discloses the following limitations:
exposing a readiness endpoint (“Readiness Probe” [pg. 3]) of the second node to indicate connection of the second node to the cluster (“probes are performed on an application running in a container within a Pod … Services in Kubernetes rely on Pods which are commonly part of a deployment, to be used as their backends … A Kubernetes readiness probe can be performed using any of these 4 ways … You can define a readiness command to be executed … in the target container.” [pg. 3]) – As taught in Uchenna, a “Kubernetes cluster” comprises plural Pods executing containerized applications [pgs. 2-3], which examiner considers analogous to the Target Environment 110 of Thakare Fig. 1 where plural storage nodes each include pods executing applications. As taught in Uchenna, a cluster designer can define/instantiate “readiness probes” on each pod of a cluster during pod deployment. In this context, examiner considers a cluster designer installing a readiness probe on each pod in the cluster during deployment as “exposing a readiness endpoint” for each pod included in the cluster--,
wherein the readiness endpoint of the second node provides a message to at least one node of the cluster that indicates availability of the second node to receive traffic (“A readiness command, once executed, returns one of these three outputs: Success: If the readiness probe you define is successful, it returns 0, which means your application is ready to start receiving requests” [pg. 3] // “You can define an HTTP GET request for a readiness probe. The kubelet sends an HTTP GET request to a server’s specified path and a specified port that the server listens on. Any response code greater than or equal to 200 and less than 400 … indicates Success.” [pg. 11]) – As taught on pg. 3, when a readiness probe executing on a pod returns a particular values (e.g., 0), the pod is “ready to start receiving requests” (i.e., “indicates availability” of the pod “to receive traffic”). As clarified on pg. 11, readiness probes can be realized using HTTP requests and responses (i.e., a pod provides “a message” to a kubelet to indicate the status of the probed readiness endpoint--, wherein a readiness endpoint of the first node is updated as no longer operational and to be removed from the cluster. (“Failure: if the readiness command probe fails, it returns a non-zero value, which means the application is not yet ready” [pg. 4] // “If a Pod with containers fails its readiness probe, it does not receive traffic from a service in Kubernetes. The Pod’s IP will be removed from the list of endpoints for all services that match the Pod until it is ready to start accepting traffic” [pg. 3]) – As clarified on pgs. 3-4, when a readiness probe executing on a pod returns a particular value (e.g., non-zero), the pod is not yet ready to start accepting traffic and has its IP removed from a list of service endpoints associated with the pod (i.e., “is updated as no longer operational and to be removed from” servicing requests of the cluster).
Thakare and Uchenna are considered analogous to the claimed invention because they all relate to the same field of monitoring node health in a distributed storage cluster comprising plural storage nodes. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Thakare with the teachings of Uchenna and realize a method of exposing readiness endpoints on storage nodes of the cluster to indicate whether nodes are or are not ready to receive traffic. Doing so would improves user experience by ensuring smooth and consistent application updates, minimizing downtime as disclosed in Uchenna pg. 14: “Readiness probes ensure smooth and consistent application updates, which provide a better user experience by minimizing downtime. Incoming requests won’t be routed to unhealthy Pods because their IP addresses are removed from service endpoints by the endpoint controller.”
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Thakare and Uchenna disclose the following limitations:
The method of claim 1, wherein replacing the first node with the second node comprises: updating service labels (Thakare, Node Mapping 200, Fig. 2) of the cluster to include the second node in place of the first node (Thakare, “Node mapping 200, in various embodiments, is information that is maintained by image upgrade controller 150 to track progress of an upgrade being performed for a given node 120 … Once an old node 120 has been deallocated, in various embodiments, image upgrade controller 150 removes its entry from node mapping 200 … Once the upgrade process for a node 120 has completed, image upgrade controller 150 may update the associated state 220 in node mapping 200 to “complete.”’ [0023-24]) – Examiner considers a “node mapping”, such as Node Mapping 200 depicted in Thakare Fig. 2, as reading on the claimed concept of “service labels”, under the Broadest Reasonable Interpretation (BRI) of the claimed language. As taught in Thakare ¶0023-34 and shown in Fig. 2, node mapping 200 is updated throughout the upgrade process to indicate when a first node has been deallocated, and further to indicate when the upgrade to the second node is complete (i.e., “to include the second node in place of the first node”).
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Thakare and Uchenna disclose the following limitations:
The method of claim 1, further comprising: deleting (Thakare, Fig. 4, step 414) the first node in response to replacing the first node with the second node in the cluster (Thakare, “At step 414, image upgrade controller 150 evicts the set of pods 130 from the old node 120 and then scales the node down” [0038])
Regarding Claim 7,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 7. The combined teachings of Thakare and Uchenna disclose the following limitations:
The method of claim 1, wherein copying data from the first node to the second node comprises:
establishing (Thakare, ¶0031) a connection (Thakare, “a secure tunnel” [0031] // Fig. 3B) between the first node and the second node (Thakare, Fig. 3B // “security certificates on the old node 120 and the new node 120 may be used to establish a secure tunnel between the nodes” [0031]);
identifying (Thakare, Fig. 4, step 408) in-memory data (Applications 135, Fig. 3B) of the first node (Thakare, “At step 408, image upgrade controller 150 … sets applications 135 to read-only mode” [0037]) – As detailed in Thakare ¶0037, data associated with applications 135 are set into read-only mode, which examiner considers at least as “identifying in-memory data”--; and
copying (Thakare, Fig. 4, 410) the in-memory data from the first node to the second node via the connection (Thakare, “At step 410, … image upgrade controller 150 causes data to be transferred from the storage 140 of old node 120A to the storage 140 of the new node 120D via a secure tunnel as illustrated in FIG. 3B” [0037])
Regarding Claim 8,
Thakare discloses the following limitations:
A system comprising:
a memory (Memory 720, Fig. 7); and a processing device (Processor Subsystem 780, Fig. 7), operatively coupled to the memory, to (¶0050):
receive (Fig. 4, steps 402 + 404) an update (“a node image upgrade” [0036]) for a first node (“a node 120 with an old node image” [0036]) of a cluster of compute nodes (Target Environment 110, Fig. 1 // “At step 402, an image upgrade controller 150 waits for a trigger event that indicates that a node image upgrade should be performed for nodes 120 … At step 404, image upgrade controller 150 selects a node 120 with an old node image” [0036]); generate (Fig. 4, steps 405 + 406) a second node (“a new node 120” [0036]) comprising the update for the first node, wherein the second node is generated based on an image (“the new node image 165” [0037]) comprising the update for the first node (“image upgrade controller 150 then proceeds to step 405 in which it communicates with a deployment system to create/deploy a new node 120 … at step 406, image upgrade controller 150 determines whether a new node 120 running the new node image 165 has been spun up.” [0036-37]);
copy (Fig. 4, step 410) data from the first node to the second node (“At step 410, image upgrade controller 150 begins copying data from the old node 120 to the new node 120” [0037]); and
in response to completion of copying the data (Fig. 4, step 412 ‘Yes’), replace (Fig. 4, step 414) the first node in the cluster with the second node (“At step 414, image upgrade controller 150 evicts the set of pods 130 from the old node 120 and then scales the node down” [0038])
Although Thakare Fig. 3C // ¶0034 discloses that applications running on the old node are deployed onto the new node, and further that the new node is transitioned from “a read-only mode” to “a write mode” after deploying applications onto the new node, Thakare is silent regarding the following limitations:
expose a readiness endpoint of the second node to indicate connection of the second node to the cluster, wherein the readiness endpoint of the second node provides a message to at least one node of the cluster that indicates availability of the second node to receive traffic, wherein a readiness endpoint of the first node is updated as no longer operational and to be removed from the cluster.
However, Uchenna discloses within the context of monitoring node health in a distributed storage cluster environment that a “Readiness Probe” running on each given pod of a cluster indicates whether or not the given pod is ready to receive traffic.
Uchenna discloses the following limitations:
expose a readiness endpoint (“Readiness Probe” [pg. 3]) of the second node to indicate connection of the second node to the cluster (“probes are performed on an application running in a container within a Pod … Services in Kubernetes rely on Pods which are commonly part of a deployment, to be used as their backends … A Kubernetes readiness probe can be performed using any of these 4 ways … You can define a readiness command to be executed … in the target container.” [pg. 3]) – As taught in Uchenna, a “Kubernetes cluster” comprises plural Pods executing containerized applications [pgs. 2-3], which examiner considers analogous to the Target Environment 110 of Thakare Fig. 1 where plural storage nodes each include pods executing applications. As taught in Uchenna, a cluster designer can define/instantiate “readiness probes” on each pod of a cluster during pod deployment. In this context, examiner considers a cluster designer installing a readiness probe on each pod in the cluster during deployment as “exposing a readiness endpoint” for each pod included in the cluster--,
wherein the readiness endpoint of the second node provides a message to at least one node of the cluster that indicates availability of the second node to receive traffic (“A readiness command, once executed, returns one of these three outputs: Success: If the readiness probe you define is successful, it returns 0, which means your application is ready to start receiving requests” [pg. 3] // “You can define an HTTP GET request for a readiness probe. The kubelet sends an HTTP GET request to a server’s specified path and a specified port that the server listens on. Any response code greater than or equal to 200 and less than 400 … indicates Success.” [pg. 11]) – As taught on pg. 3, when a readiness probe executing on a pod returns a particular values (e.g., 0), the pod is “ready to start receiving requests” (i.e., “indicates availability” of the pod “to receive traffic”). As clarified on pg. 11, readiness probes can be realized using HTTP requests and responses (i.e., a pod provides “a message” to a kubelet to indicate the status of the probed readiness endpoint--, wherein a readiness endpoint of the first node is updated as no longer operational and to be removed from the cluster. (“Failure: if the readiness command probe fails, it returns a non-zero value, which means the application is not yet ready” [pg. 4] // “If a Pod with containers fails its readiness probe, it does not receive traffic from a service in Kubernetes. The Pod’s IP will be removed from the list of endpoints for all services that match the Pod until it is ready to start accepting traffic” [pg. 3]) – As clarified on pgs. 3-4, when a readiness probe executing on a pod returns a particular value (e.g., non-zero), the pod is not yet ready to start accepting traffic and has its IP removed from a list of service endpoints associated with the pod (i.e., “is updated as no longer operational and to be removed from” servicing requests of the cluster).
Thakare and Uchenna are considered analogous to the claimed invention because they all relate to the same field of monitoring node health in a distributed storage cluster comprising plural storage nodes. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Thakare with the teachings of Uchenna and realize a method of exposing readiness endpoints on storage nodes of the cluster to indicate whether nodes are or are not ready to receive traffic. Doing so would improves user experience by ensuring smooth and consistent application updates, minimizing downtime as disclosed in Uchenna pg. 14: “Readiness probes ensure smooth and consistent application updates, which provide a better user experience by minimizing downtime. Incoming requests won’t be routed to unhealthy Pods because their IP addresses are removed from service endpoints by the endpoint controller.”
Regarding Claim 9,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 9. The combined teachings of Thakare and Uchenna disclose the following limitations:
The system of claim 8, wherein to replace the first node with the second node, the processing device is to: update service labels (Thakare, Node Mapping 200, Fig. 2) of the cluster to include the second node in place of the first node (Thakare, “Node mapping 200, in various embodiments, is information that is maintained by image upgrade controller 150 to track progress of an upgrade being performed for a given node 120 … Once an old node 120 has been deallocated, in various embodiments, image upgrade controller 150 removes its entry from node mapping 200 … Once the upgrade process for a node 120 has completed, image upgrade controller 150 may update the associated state 220 in node mapping 200 to “complete.”’ [0023-24]) – Examiner considers a “node mapping”, such as Node Mapping 200 depicted in Thakare Fig. 2, as reading on the claimed concept of “service labels”, under the Broadest Reasonable Interpretation (BRI) of the claimed language. As taught in Thakare ¶0023-34 and shown in Fig. 2, node mapping 200 is updated throughout the upgrade process to indicate when a first node has been deallocated, and further to indicate when the upgrade to the second node is complete (i.e., “to include the second node in place of the first node”)
Regarding Claim 13,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 13. The combined teachings of Thakare and Uchenna disclose the following limitations:
The system of claim 8, wherein the processing device is further to: delete (Thakare, Fig. 4, step 414) the first node in response to replacing the first node with the second node in the cluster (Thakare, “At step 414, image upgrade controller 150 evicts the set of pods 130 from the old node 120 and then scales the node down” [0038])
Regarding Claim 14,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 7. The combined teachings of Thakare and Uchenna disclose the following limitations:
The system of claim 8, wherein to copy data from the first node to the second node, the processing device is to:
establish (Thakare, ¶0031) a connection (Thakare, “a secure tunnel” [0031] // Fig. 3B) between the first node and the second node (Thakare, Fig. 3B // “security certificates on the old node 120 and the new node 120 may be used to establish a secure tunnel between the nodes” [0031]);
identify (Thakare, Fig. 4, step 408) in-memory data (Applications 135, Fig. 3B) of the first node (Thakare, “At step 408, image upgrade controller 150 … sets applications 135 to read-only mode” [0037]) – As detailed in Thakare ¶0037, data associated with applications 135 are set into read-only mode, which examiner considers at least as “identify[ing] in-memory data”--; and
copy (Thakare, Fig. 4, 410) the in-memory data from the first node to the second node via the connection (Thakare, “At step 410, … image upgrade controller 150 causes data to be transferred from the storage 140 of old node 120A to the storage 140 of the new node 120D via a secure tunnel as illustrated in FIG. 3B” [0037])
Regarding Claim 15,
Thakare discloses the following limitations:
A non-transitory computer-readable storage medium including instructions that, when executed by a processing device, cause the processing device to (¶0043):
receive (Fig. 4, steps 402 + 404) an update (“a node image upgrade” [0036]) for a first node (“a node 120 with an old node image” [0036]) of a cluster of compute nodes (Target Environment 110, Fig. 1 // “At step 402, an image upgrade controller 150 waits for a trigger event that indicates that a node image upgrade should be performed for nodes 120 … At step 404, image upgrade controller 150 selects a node 120 with an old node image” [0036]); generate (Fig. 4, steps 405 + 406), by the processing device, a second node (“a new node 120” [0036]) comprising the update for the first node, wherein the second node is generated based on an image (“the new node image 165” [0037]) comprising the update for the first node (“image upgrade controller 150 then proceeds to step 405 in which it communicates with a deployment system to create/deploy a new node 120 … at step 406, image upgrade controller 150 determines whether a new node 120 running the new node image 165 has been spun up.” [0036-37]);
copy (Fig. 4, step 410) data from the first node to the second node (“At step 410, image upgrade controller 150 begins copying data from the old node 120 to the new node 120” [0037]); and
in response to completion of copying the data (Fig. 4, step 412 ‘Yes’), replace (Fig. 4, step 414) the first node in the cluster with the second node (“At step 414, image upgrade controller 150 evicts the set of pods 130 from the old node 120 and then scales the node down” [0038])
Although Thakare Fig. 3C // ¶0034 discloses that applications running on the old node are deployed onto the new node, and further that the new node is transitioned from “a read-only mode” to “a write mode” after deploying applications onto the new node, Thakare is silent regarding the following limitations:
expose a readiness endpoint of the second node to indicate connection of the second node to the cluster, wherein the readiness endpoint of the second node provides a message to at least one node of the cluster that indicates availability of the second node to receive traffic, wherein a readiness endpoint of the first node is updated as no longer operational and to be removed from the cluster.
However, Uchenna discloses within the context of monitoring node health in a distributed storage cluster environment that a “Readiness Probe” running on each given pod of a cluster indicates whether or not the given pod is ready to receive traffic.
Uchenna discloses the following limitations:
expose a readiness endpoint (“Readiness Probe” [pg. 3]) of the second node to indicate connection of the second node to the cluster (“probes are performed on an application running in a container within a Pod … Services in Kubernetes rely on Pods which are commonly part of a deployment, to be used as their backends … A Kubernetes readiness probe can be performed using any of these 4 ways … You can define a readiness command to be executed … in the target container.” [pg. 3]) – As taught in Uchenna, a “Kubernetes cluster” comprises plural Pods executing containerized applications [pgs. 2-3], which examiner considers analogous to the Target Environment 110 of Thakare Fig. 1 where plural storage nodes each include pods executing applications. As taught in Uchenna, a cluster designer can define/instantiate “readiness probes” on each pod of a cluster during pod deployment. In this context, examiner considers a cluster designer installing a readiness probe on each pod in the cluster during deployment as “exposing a readiness endpoint” for each pod included in the cluster--,
wherein the readiness endpoint of the second node provides a message to at least one node of the cluster that indicates availability of the second node to receive traffic (“A readiness command, once executed, returns one of these three outputs: Success: If the readiness probe you define is successful, it returns 0, which means your application is ready to start receiving requests” [pg. 3] // “You can define an HTTP GET request for a readiness probe. The kubelet sends an HTTP GET request to a server’s specified path and a specified port that the server listens on. Any response code greater than or equal to 200 and less than 400 … indicates Success.” [pg. 11]) – As taught on pg. 3, when a readiness probe executing on a pod returns a particular values (e.g., 0), the pod is “ready to start receiving requests” (i.e., “indicates availability” of the pod “to receive traffic”). As clarified on pg. 11, readiness probes can be realized using HTTP requests and responses (i.e., a pod provides “a message” to a kubelet to indicate the status of the probed readiness endpoint--, wherein a readiness endpoint of the first node is updated as no longer operational and to be removed from the cluster. (“Failure: if the readiness command probe fails, it returns a non-zero value, which means the application is not yet ready” [pg. 4] // “If a Pod with containers fails its readiness probe, it does not receive traffic from a service in Kubernetes. The Pod’s IP will be removed from the list of endpoints for all services that match the Pod until it is ready to start accepting traffic” [pg. 3]) – As clarified on pgs. 3-4, when a readiness probe executing on a pod returns a particular value (e.g., non-zero), the pod is not yet ready to start accepting traffic and has its IP removed from a list of service endpoints associated with the pod (i.e., “is updated as no longer operational and to be removed from” servicing requests of the cluster).
Thakare and Uchenna are considered analogous to the claimed invention because they all relate to the same field of monitoring node health in a distributed storage cluster comprising plural storage nodes. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Thakare with the teachings of Uchenna and realize a method of exposing readiness endpoints on storage nodes of the cluster to indicate whether nodes are or are not ready to receive traffic. Doing so would improves user experience by ensuring smooth and consistent application updates, minimizing downtime as disclosed in Uchenna pg. 14: “Readiness probes ensure smooth and consistent application updates, which provide a better user experience by minimizing downtime. Incoming requests won’t be routed to unhealthy Pods because their IP addresses are removed from service endpoints by the endpoint controller.”
Regarding Claim 16,
The same motivation to combine provided in Claim 15 is equally applicable to Claim 16. The combined teachings of Thakare and Uchenna disclose the following limitations:
The non-transitory computer-readable storage medium of claim 15, wherein to replace the first node with the second node, the processing device is to: update service labels (Thakare, Node Mapping 200, Fig. 2) of the cluster to include the second node in place of the first node (Thakare, “Node mapping 200, in various embodiments, is information that is maintained by image upgrade controller 150 to track progress of an upgrade being performed for a given node 120 … Once an old node 120 has been deallocated, in various embodiments, image upgrade controller 150 removes its entry from node mapping 200 … Once the upgrade process for a node 120 has completed, image upgrade controller 150 may update the associated state 220 in node mapping 200 to “complete.”’ [0023-24]) – Examiner considers a “node mapping”, such as Node Mapping 200 depicted in Thakare Fig. 2, as reading on the claimed concept of “service labels”, under the Broadest Reasonable Interpretation (BRI) of the claimed language. As taught in Thakare ¶0023-34 and shown in Fig. 2, node mapping 200 is updated throughout the upgrade process to indicate when a first node has been deallocated, and further to indicate when the upgrade to the second node is complete (i.e., “to include the second node in place of the first node”)
Regarding Claim 20,
The same motivation to combine provided in Claim 15 is equally applicable to Claim 20. The combined teachings of Thakare and Uchenna disclose the following limitations:
The non-transitory computer-readable storage medium of claim 15, wherein the processing device is further to: delete (Thakare, Fig. 4, step 414) the first node in response to replacing the first node with the second node in the cluster (Thakare, “At step 414, image upgrade controller 150 evicts the set of pods 130 from the old node 120 and then scales the node down” [0038])
Claims 3-4, 10-11, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Thakare further in view of Uchenna and an online publication authored by Troisi (author Hannah Troisi, article titled ‘Safer Kubernetes Node Pool Upgrades’; published March 28, 2022 on Pixie Team Blogs; May 25, 2022 version accessed by examiner via Wayback Machine)(see also Notice of References cited)(cited by examiner in previous action)(hereafter referred to as Troisi).
Regarding Claim 3,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 3. The combined teachings of Thakare and Uchenna disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), wherein replacing the first node with the second node comprises:
updating (Thakare, ¶0034) a first indicator of the second node (Uchenna, “readiness probe” [pg. 3]) to indicate that the second node has received all the data from the first node (Thakare, “after the data transfer from the old node 120 (e.g., node 120A) to the new node 120 (e.g., node 120D) has finished … image upgrade controller 150 may transition the pod 130 from the read-only mode to a write mode” [0034]) – As previously discussed (see Claim 1 limitation mappings above) and as disclosed in Uchenna, a readiness probe (i.e., “a first indicator of the second node”) is deployed to indicate whether or not a node is ready. As disclosed in Thakare ¶0034, after data is successfully copied to the new node 120, the new node 120 is transitioned from a “read-only mode” to a “write mode”. One of ordinary skill in the art would understand that a readiness probe, as taught in Uchenna, which is deployed on a node would at least be “updat[ed]” (i.e., to indicate that a node is ready) when the node is transitioned from a read-only mode into a write mode--; and
… updating (Thakare, ¶0037) a second indicator of the first node (Uchenna, “readiness probe” [pg. 3]) to indicate that the first node is no longer available to the cluster (Thakare, “At step 408, image upgrade controller 150 sets the old node 120 to the read-only mode” [0037]) – As previously discussed (see Claim 1 limitation mappings above) and as taught in Uchenna, “readiness probes” can be started on a node when the node is deployed. One of ordinary skill in the art would accordingly understand that old node 120 additionally includes a readiness probe (i.e., “a second indicator of the first node”). As taught in Thakare ¶0037, before copying data from old node 120 to new node 120, old node 120 is transitioned into a read-only mode. One of ordinary skill in the art would accordingly understand that a readiness probe, as taught in Uchenna, which is deployed on a node would at least be “updat[ed]” (i.e., to indicate that a node is no longer ready) when the node is transitioned into a read-only mode--.
As taught in Thakare Fig. 4, old node 120 is transitioned into a read-only mode before new node 120 is transitioned into a write mode. Thakare is silent regarding transitioning the new node 120 into a write mode before transitioning old node 120 into a read-only mode. Specifically, the combined teachings of Thakare and Uchenna do not explicitly disclose the following limitations:
in response to updating the first indicator of the second node, updating a second indicator of the first node
However, Troisi discloses within the context of performing node image upgrades on computing nodes running readiness probes that an “out-of-place upgrade” strategy only deletes nodes running old images after new nodes are already running.
Troisi discloses the following limitations:
in response to updating the first indicator of the second node, updating a second indicator of the first node (“There are two strategies for upgrading the Kubernetes version on worker nodes: … For an out-of-place upgrade, a fresh node pool is created with the new Kubernetes version. Once the new nodes are all running, you can cordon the old pool, drain the old nodes one by one, and then delete the old node pool.” [pgs. 2-3, ‘Upgrading Worker Nodes’] // “To eliminate downtime, ensure that you have configured the following: … 4. For quorum-based applications, make sure you’ve configured a Readiness probe.” [pg. 6, ‘StatefulSets’]) – As taught in Troisi pgs. 2-3, performing out-of-place type upgrades on node images ensures that new nodes are running before old nodes are deleted. As suggested on Troisi pg. 6, nodes should have Readiness probes configured. One of ordinary skill in the art would accordingly understand that out-of-place type of upgrades on nodes with configured readiness probes, as taught by Troisi, would result in an old node being deleted (i.e., “updating a second indicator of the first node”) in response to a new node coming up and running (i.e., “updating the first indicator of the second node”).
Thakare, Uchenna, and Troisi are all considered analogous to the claimed invention because they all relate to the same field of performing node image upgrades in distributed worker node environments. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Thakare and Uchenna with the teachings of Troisi and realize a node upgrade a new node is indicated as having received all data before an old node is indicated as being unavailable to a cluster. Doing so would achieve benefit of a shorter upgrade window, as disclosed in Troisi pg. 4: “An out-of-place upgrade requires a temporary doubling of compute resources in exchange for a shorter upgrade window. The decrease in upgrade duration results from the parallelization of the startup time of the new upgraded nodes, as well as the minimization of the movement of the pods.” [Troisi, pg. 4, ‘Upgrading Worker Nodes’]
Regarding Claim 4,
The same motivation to combine provided in Claim 3 is equally applicable to Claim 4. The combined teachings of Thakare, Uchenna, and Troisi disclose the following limitations:
The method of claim 3, wherein the first indicator is the readiness endpoint (Uchenna, pg. 3) of the second node and the second indicator is a readiness endpoint of the first node (Uchenna, pg. 3) – As previously discussed (see Claims 1 and 3 limitation mappings above) and as taught in Uchenna, a readiness probe is deployed when a node is created. One of ordinary skill in the art would accordingly understand that first and second nodes would at least include respective readiness probes.
Regarding Claim 10,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 10. The combined teachings of Thakare and Uchenna disclose the following limitations:
The system of claim 8, (see Claim 8 limitation mappings above), wherein to replace the first node with the second node, the processing device is to:
update (Thakare, ¶0034) a first indicator of the second node (Uchenna, “readiness probe” [pg. 3]) to indicate that the second node has received all the data from the first node (Thakare, “after the data transfer from the old node 120 (e.g., node 120A) to the new node 120 (e.g., node 120D) has finished … image upgrade controller 150 may transition the pod 130 from the read-only mode to a write mode” [0034]) – As previously discussed (see Claim 8 limitation mappings above) and as disclosed in Uchenna, a readiness probe (i.e., “a first indicator of the second node”) is deployed to indicate whether or not a node is ready. As disclosed in Thakare ¶0034, after data is successfully copied to the new node 120, the new node 120 is transitioned from a “read-only mode” to a “write mode”. One of ordinary skill in the art would understand that a readiness probe, as taught in Uchenna, which is deployed on a node would at least be “updat[ed]” (i.e., to indicate that a node is ready) when the node is transitioned from a read-only mode into a write mode--; and
… update (Thakare, ¶0037) a second indicator of the first node (Uchenna, “readiness probe” [pg. 3]) to indicate that the first node is no longer available to the cluster (Thakare, “At step 408, image upgrade controller 150 sets the old node 120 to the read-only mode” [0037]) – As previously discussed (see Claim 8 limitation mappings above) and as taught in Uchenna, “readiness probes” can be started on a node when the node is deployed. One of ordinary skill in the art would accordingly understand that old node 120 additionally includes a readiness probe (i.e., “a second indicator of the first node”). As taught in Thakare ¶0037, before copying data from old node 120 to new node 120, old node 120 is transitioned into a read-only mode. One of ordinary skill in the art would accordingly understand that a readiness probe, as taught in Uchenna, which is deployed on a node would at least be “updat[ed]” (i.e., to indicate that a node is no longer ready) when the node is transitioned into a read-only mode--.
As taught in Thakare Fig. 4, old node 120 is transitioned into a read-only mode before new node 120 is transitioned into a write mode. Thakare is silent regarding transitioning the new node 120 into a write mode before transitioning old node 120 into a read-only mode. Specifically, the combined teachings of Thakare and Uchenna do not explicitly disclose the following limitations:
in response to updating the first indicator of the second node, update a second indicator of the first node
However, Troisi discloses within the context of performing node image upgrades on computing nodes running readiness probes that an “out-of-place upgrade” strategy only deletes nodes running old images after new nodes are already running.
Troisi discloses the following limitations:
in response to updating the first indicator of the second node, update a second indicator of the first node (“There are two strategies for upgrading the Kubernetes version on worker nodes: … For an out-of-place upgrade, a fresh node pool is created with the new Kubernetes version. Once the new nodes are all running, you can cordon the old pool, drain the old nodes one by one, and then delete the old node pool.” [pgs. 2-3, ‘Upgrading Worker Nodes’] // “To eliminate downtime, ensure that you have configured the following: … 4. For quorum-based applications, make sure you’ve configured a Readiness probe.” [pg. 6, ‘StatefulSets’]) – As taught in Troisi pgs. 2-3, performing out-of-place type upgrades on node images ensures that new nodes are running before old nodes are deleted. As suggested on Troisi pg. 6, nodes should have Readiness probes configured. One of ordinary skill in the art would accordingly understand that out-of-place type of upgrades on nodes with configured readiness probes, as taught by Troisi, would result in an old node being deleted (i.e., “update a second indicator of the first node”) in response to a new node coming up and running (i.e., “update the first indicator of the second node”).
Thakare, Uchenna, and Troisi are all considered analogous to the claimed invention because they all relate to the same field of performing node image upgrades in distributed worker node environments. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Thakare and Uchenna with the teachings of Troisi and realize a node upgrade a new node is indicated as having received all data before an old node is indicated as being unavailable to a cluster. Doing so would achieve benefit of a shorter upgrade window, as disclosed in Troisi pg. 4: “An out-of-place upgrade requires a temporary doubling of compute resources in exchange for a shorter upgrade window. The decrease in upgrade duration results from the parallelization of the startup time of the new upgraded nodes, as well as the minimization of the movement of the pods.” [Troisi, pg. 4, ‘Upgrading Worker Nodes’]
Regarding Claim 11,
The same motivation to combine provided in Claim 10 is equally applicable to Claim 11. The combined teachings of Thakare, Uchenna, and Troisi disclose the following limitations:
The system of claim 10, wherein the first indicator is the readiness endpoint (Uchenna, pg. 3) of the second node and the second indicator is a readiness endpoint of the first node (Uchenna, pg. 3) – As previously discussed (see Claims 8 and 10 limitation mappings above) and as taught in Uchenna, a readiness probe is deployed when a node is created. One of ordinary skill in the art would accordingly understand that first and second nodes would at least include respective readiness probes.
Regarding Claim 17,
The same motivation to combine provided in Claim 15 is equally applicable to Claim 17. The combined teachings of Thakare and Uchenna disclose the following limitations:
The non-transitory computer-readable storage medium of claim 15, (see Claim 15 limitation mappings above), wherein to replace the first node with the second node, the processing device is to:
update (Thakare, ¶0034) a first indicator of the second node (Uchenna, “readiness probe” [pg. 3]) to indicate that the second node has received all the data from the first node (Thakare, “after the data transfer from the old node 120 (e.g., node 120A) to the new node 120 (e.g., node 120D) has finished … image upgrade controller 150 may transition the pod 130 from the read-only mode to a write mode” [0034]) – As previously discussed (see Claim 8 limitation mappings above) and as disclosed in Uchenna, a readiness probe (i.e., “a first indicator of the second node”) is deployed to indicate whether or not a node is ready. As disclosed in Thakare ¶0034, after data is successfully copied to the new node 120, the new node 120 is transitioned from a “read-only mode” to a “write mode”. One of ordinary skill in the art would understand that a readiness probe, as taught in Uchenna, which is deployed on a node would at least be “updat[ed]” (i.e., to indicate that a node is ready) when the node is transitioned from a read-only mode into a write mode--; and
… update (Thakare, ¶0037) a second indicator of the first node (Uchenna, “readiness probe” [pg. 3]) to indicate that the first node is no longer available to the cluster (Thakare, “At step 408, image upgrade controller 150 sets the old node 120 to the read-only mode” [0037]) – As previously discussed (see Claim 15 limitation mappings above) and as taught in Uchenna, “readiness probes” can be started on a node when the node is deployed. One of ordinary skill in the art would accordingly understand that old node 120 additionally includes a readiness probe (i.e., “a second indicator of the first node”). As taught in Thakare ¶0037, before copying data from old node 120 to new node 120, old node 120 is transitioned into a read-only mode. One of ordinary skill in the art would accordingly understand that a readiness probe, as taught in Uchenna, which is deployed on a node would at least be “updat[ed]” (i.e., to indicate that a node is no longer ready) when the node is transitioned into a read-only mode--.
As taught in Thakare Fig. 4, old node 120 is transitioned into a read-only mode before new node 120 is transitioned into a write mode. Thakare is silent regarding transitioning the new node 120 into a write mode before transitioning old node 120 into a read-only mode. Specifically, the combined teachings of Thakare and Uchenna do not explicitly disclose the following limitations:
in response to updating the first indicator of the second node, update a second indicator of the first node
However, Troisi discloses within the context of performing node image upgrades on computing nodes running readiness probes that an “out-of-place upgrade” strategy only deletes nodes running old images after new nodes are already running.
Troisi discloses the following limitations:
in response to updating the first indicator of the second node, update a second indicator of the first node (“There are two strategies for upgrading the Kubernetes version on worker nodes: … For an out-of-place upgrade, a fresh node pool is created with the new Kubernetes version. Once the new nodes are all running, you can cordon the old pool, drain the old nodes one by one, and then delete the old node pool.” [pgs. 2-3, ‘Upgrading Worker Nodes’] // “To eliminate downtime, ensure that you have configured the following: … 4. For quorum-based applications, make sure you’ve configured a Readiness probe.” [pg. 6, ‘StatefulSets’]) – As taught in Troisi pgs. 2-3, performing out-of-place type upgrades on node images ensures that new nodes are running before old nodes are deleted. As suggested on Troisi pg. 6, nodes should have Readiness probes configured. One of ordinary skill in the art would accordingly understand that out-of-place type of upgrades on nodes with configured readiness probes, as taught by Troisi, would result in an old node being deleted (i.e., “update a second indicator of the first node”) in response to a new node coming up and running (i.e., “update the first indicator of the second node”).
Thakare, Uchenna, and Troisi are all considered analogous to the claimed invention because they all relate to the same field of performing node image upgrades in distributed worker node environments. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Thakare and Uchenna with the teachings of Troisi and realize a node upgrade a new node is indicated as having received all data before an old node is indicated as being unavailable to a cluster. Doing so would achieve benefit of a shorter upgrade window, as disclosed in Troisi pg. 4: “An out-of-place upgrade requires a temporary doubling of compute resources in exchange for a shorter upgrade window. The decrease in upgrade duration results from the parallelization of the startup time of the new upgraded nodes, as well as the minimization of the movement of the pods.” [Troisi, pg. 4, ‘Upgrading Worker Nodes’]
Regarding Claim 18,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 18. The combined teachings of Thakare, Uchenna, and Troisi disclose the following limitations:
The non-transitory computer-readable storage medium of claim 17, wherein the first indicator is the readiness endpoint (Uchenna, pg. 3) of the second node and the second indicator is a readiness endpoint of the first node (Uchenna, pg. 3) – As previously discussed (see Claims 15 and 17 limitation mappings above) and as taught in Uchenna, a readiness probe is deployed when a node is created. One of ordinary skill in the art would accordingly understand that first and second nodes would at least include respective readiness probes.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Thakare further in view of Uchenna and Markus (US 20130151889 A1)(cited by examiner in previous action)(hereafter referred to as Markus).
Regarding Claim 5,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 5. The combined teachings of Thakare and Uchenna disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above),
Thakare and Uchenna are silent regarding the following limitations:
wherein the cluster comprises an in-memory data grid in which data is distributed across nodes of the cluster in view of a consistent hash operation
However, Markus discloses within the context of distributing data across nodes of a cluster (Data Grid Nodes 125A-125C, Fig. 1) that a consistent hash algorithm can be used to determine where in the cluster data should be stored.
Markus discloses the following limitations:
wherein the cluster comprises an in-memory data grid (In-Memory Data Grid 150, Fig. 1 // ¶0022) in which data is distributed across nodes of the cluster in view of a consistent hash operation (“a consistent hashing algorithm” [0022])(“The in-memory data grid 150 is a data store that spans multiple machines … that are joined in a distributed cluster … In one embodiment, distribution makes use of a consistent hashing algorithm to determine where in the cluster entries should be stored” [0022])
Thakare, Uchenna, and Markus are all considered analogous to the claimed invention because they all relate to the same field of storing data across a plurality of nodes within a cluster. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Thakare and Uchenna with the teachings of Markus and realize a cluster comprising an in-memory data grid in which data is distributed across nodes of the cluster in view of a consistent hash operation. Doing so would enable a configurable number of copies of data to be stored in the cluster while still using a deterministic algorithm to locate entries without maintaining expensive metadata, which would provide faster storage due to fewer executed CPU instructions, as disclosed in Markus ¶0022: “The hashing algorithm may be configured to maintain a specified number of copies of each entry in the in-memory data grid 150. In one embodiment, the hashing algorithm is deterministic in locating entries without resorting to multicasting requests or maintaining expensive metadata … In-memory data grids 150 are faster than disk-optimized data grids since they execute fewer CPU instructions” [0022].
Regarding Claim 12,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 12. The combined teachings of Thakare and Uchenna disclose the following limitations:
The system of claim 8, (see Claim 8 limitation mappings above)
Thakare and Uchenna are silent regarding the following limitations:
wherein the cluster comprises an in-memory data grid in which data is distributed across nodes of the cluster in view of a consistent hash operation.
However, Markus discloses within the context of distributing data across nodes of a cluster (Data Grid Nodes 125A-125C, Fig. 1) that a consistent hash algorithm can be used to determine where in the cluster data should be stored.
Markus discloses the following limitations:
wherein the cluster comprises an in-memory data grid (In-Memory Data Grid 150, Fig. 1 // ¶0022) in which data is distributed across nodes of the cluster in view of a consistent hash operation (“a consistent hashing algorithm” [0022])(“The in-memory data grid 150 is a data store that spans multiple machines … that are joined in a distributed cluster … In one embodiment, distribution makes use of a consistent hashing algorithm to determine where in the cluster entries should be stored” [0022])
Thakare, Uchenna, and Markus are all considered to be analogous to the claimed invention because they all relate to the same field of storing data across a plurality of nodes within a cluster. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Thakare and Uchenna with the teachings of Markus and realize a cluster comprising an in-memory data grid in which data is distributed across nodes of the cluster in view of a consistent hash operation. Doing so would enable a configurable number of copies of data to be stored in the cluster while still using a deterministic algorithm to locate entries without maintaining expensive metadata, which would provide faster storage due to fewer executed CPU instructions, as disclosed in Markus ¶0022: “The hashing algorithm may be configured to maintain a specified number of copies of each entry in the in-memory data grid 150. In one embodiment, the hashing algorithm is deterministic in locating entries without resorting to multicasting requests or maintaining expensive metadata … In-memory data grids 150 are faster than disk-optimized data grids since they execute fewer CPU instructions” [0022].
Regarding Claim 19,
The same motivation to combined provided in Claim 15 is equally applicable to Claim 19. Thakare and Uchenna disclose the following limitations:
The non-transitory computer-readable storage medium of claim 15, (see Claim 15 limitation mappings above)
Thakare and Uchenna are silent regarding the following limitations:
wherein the cluster comprises an in-memory data grid in which data is distributed across nodes of the cluster in view of a consistent hash operation
However, Markus discloses within the context of distributing data across nodes of a cluster (Data Grid Nodes 125A-125C, Fig. 1) that a consistent hash algorithm can be used to determine where in the cluster data should be stored.
Markus discloses the following limitations:
wherein the cluster comprises an in-memory data grid (In-Memory Data Grid 150, Fig. 1 // ¶0022) in which data is distributed across nodes of the cluster in view of a consistent hash operation (“a consistent hashing algorithm” [0022])(“The in-memory data grid 150 is a data store that spans multiple machines … that are joined in a distributed cluster … In one embodiment, distribution makes use of a consistent hashing algorithm to determine where in the cluster entries should be stored” [0022])
Thakare, Uchenna, and Markus are both considered to be analogous to the claimed invention because they all relate to the same field of storing data across a plurality of nodes within a cluster. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined teachings of Thakare and Uchenna with the teachings of Markus and realize a cluster comprising an in-memory data grid in which data is distributed across nodes of the cluster in view of a consistent hash operation. Doing so would enable a configurable number of copies of data to be stored in the cluster while still using a deterministic algorithm to locate entries without maintaining expensive metadata, which would provide faster storage due to fewer executed CPU instructions, as disclosed in Markus ¶0022: “The hashing algorithm may be configured to maintain a specified number of copies of each entry in the in-memory data grid 150. In one embodiment, the hashing algorithm is deterministic in locating entries without resorting to multicasting requests or maintaining expensive metadata … In-memory data grids 150 are faster than disk-optimized data grids since they execute fewer CPU instructions” [0022].
Response to Arguments
Applicant’s arguments filed 01/13/2026 with respect to Claims 1-20 have been considered but are moot in light of the newly-identified Uchenna references 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm EST.
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, Rocío del Mar Pérez-Vélez can be reached at 571-270-5935. 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.
/J.S.M./Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133
Prosecution Insights