6/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 .
Claims 1-20 are presented for examination.
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.
Claim(s) 1, 4, 5, 7, 10, 11, 14, 15, 17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mehta (US 2023/0337018 A1) in view of Ying (US 2025/0028628 A1) further in view of Zhang (US 11,307,967 B2) and Lieblich (US 11,163,479 B2).
Regarding Claim 1, Mehta (US 2023/0337018 A1) teaches
A computer-implemented method, in a data processing system, for recovering a first worker node that is in a not ready state, the computer-implemented method comprising: (Paragraph 0003, “5G utilizes an intelligent architecture, with Radio Access Networks (RANs) not constrained by base station proximity or complex infrastructure. 5G enables a disaggregated, flexible and virtualized RAN with interfaces creating additional data access points”) Examiner Comments: Mehta teaches a data processing system using Kubernetes-based container orchestration for managing worker nodes and recovering from failure states.
configuring, with a first debug utility, the first worker node of a plurality of worker nodes of a cluster (Paragraph 0036, “Kubernetes configurations may be used to detect and relocate impacted pods in the event of failure to another EC2 within the node group”) Examiner Comments: Mehta teaches configuring worker nodes (EC2 instances in EKS Kubernetes cluster) with monitoring utilities including control plane components that detect and handle failures, mapping to configuring a first worker node with a debug utility;
monitoring the operating state of the first worker node to detect whether or not the first worker node enters the not ready state; and (Paragraph 0036, “A control plane of the cluster 206 may detect such failures and control automatically switching over to the spare cloud compute instances”) Examiner Comments: Mehta teaches monitoring node states via the control plane to detect failures equivalent to not ready states in Kubernetes;
based on detecting... that [the first worker node enters the not ready state]: issuing... a request to... a second worker node... that is in a ready state, to create a debug worker node for the first worker node; (Paragraph 0039, “in response to the control plane of cluster 1 206 detecting a failure of a CU-UP pod or a CU-CP pod running on a cloud compute instance within node group Node Group 208, the control plane of cluster 1 206 automatically switches from CNF instance CU-CP-1 212 for which failure was detected to a standby pod running on spare cloud compute instance 218”) Examiner Comments: Mehta teaches that in response to detecting failure on a first instance, the system directs recovery operations to a second, healthy cloud compute instance, teaching the cross-node recovery mechanism;
obtaining, from a master node of the cluster, a custom resource definition (CRD) based on the issuing of the request; (Paragraph 0034, “the CNF corresponds to and is implemented by one or more software containers of one or more respective pods for scheduling and execution on one or more respective nodes in a software container orchestration platform that automates deployment, management, and scaling of containerized software applications”) Examiner Comments: Mehta teaches obtaining configurations (CNF definitions, analogous to CRDs in Kubernetes) from the control plane/master node for defining and creating resource instances within the cluster;
creating the debug worker node in the cluster based on the CRD, wherein the debug worker node corresponds to the first worker node; (Paragraph 0038, “standby pods running on the other cloud compute instance are generated with anti-affinity between the primary CNF instance and the standby pod, such that one or more of the CU-CP CNF instances running on cloud compute instance 1 can switch to standby pods of another cloud compute instance, such as spare cloud compute instance 218”) Examiner Comments: Mehta teaches creating recovery nodes/pods based on cluster configurations that correspond to the failed first worker node.
Mehta did not specifically teach
wherein the first debug utility comprises a debug node agent that monitors an operating state of the first worker node;
based on detecting, by the debug node agent, that the first worker node enters the not ready state;
issuing, by the debug node agent, a request to a debug proxy of a second debug utility associated with a second worker node of the plurality of worker nodes, wherein the second worker node is in a ready state, and the request is issued to create a debug worker node for the first worker node;
the debug worker node comprises a minimum configuration for handling debug commands; and
processing the debug commands from a user via the debug worker node to return the first worker node to a ready state.
However, Ying (US 2025/0028628 A1) teaches
wherein the first debug utility comprises a debug node agent that monitors an operating state of the first worker node (Paragraph 0029, “The kubelet is a Kubernetes component that executes on each node of a cluster and acts as an agent for the control plane”; Paragraph 0017, “To monitor a first service that executes within a first Pod on a node of a Kubernetes cluster, a second service (a monitoring service) monitors a node storage to detect when a core dump file pertaining to that first service is written to the storage (which is indicative of the first service or the Pod on which it executes crashing)”) Examiner Comments: Ying teaches configuring nodes with agents (kubelet, monitoring service) that monitor service/pod operating states for crashes and failures, mapping to a debug utility comprising a debug node agent that monitors operating state;
issuing, by the debug node agent, a request to a debug proxy... to create a debug worker node for the first worker node (Paragraph 0044, “The monitoring service automatically instantiates a Pod (e.g., via the Kubernetes API server) or a simple container (e.g., a Docker container) outside of any of the Pods on that node”) Examiner Comments: Ying teaches the monitoring agent issuing a request via the Kubernetes API server (which acts as a proxy for resource creation) to create a debug container/pod. In Kubernetes, the API server on the master node serves as the central proxy that routes pod creation requests to appropriate nodes. The combination with Mehta’s cross-node architecture renders obvious directing this request to a second, ready worker node, since a not-ready node cannot host new pods;
the debug worker node comprises a minimum configuration for handling debug commands (Paragraph 0002, “Upon detection of the core dump file being written to the storage, the monitoring service automatically generates an image of the first service (based in part on data in the core dump file) and instantiates a new container separate from the Pods on the node to analyze the generated image and generate debugging information”) Examiner Comments: Ying teaches creating a debug container with minimal image (based on core dump data) specifically for handling debug analysis, mapping to minimum configuration for handling debug commands;
processing the debug commands from a user via the debug worker node to return the first worker node to a ready state (Paragraph 0046, “The analysis scripts 545 perform debugging analysis (e.g., GNU debugger (gdb) analysis). The scripts generate a set of analysis results 555 that can be packed into support bundles for offline analysis”) Examiner Comments: Ying teaches processing debug commands (gdb analysis scripts) via the debug container to generate debugging information that enables recovery of the failed service/node.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Mehta’s teaching into Ying’s in order to enable automated debugging of crashes during Kubernetes failover, improving diagnostics and reducing downtime, as a person of ordinary skill would recognize that when a worker node enters a not ready state, it cannot host new pods, making it necessary to create debug resources on a different, healthy node—a design choice directly motivated by Mehta’s cross-node architecture, and as Kubernetes is the de-facto orchestration platform allowing managing micro-service-based cloud-native applications at massive scale (Ying [Background/Summary]).
Mehta and Ying did not specifically teach
based on detecting, by the debug node agent, that the first worker node enters the not ready state
the debug worker node comprises a minimum configuration for handling debug commands;
processing debug commands from a user via the debug worker node.
However, Zhang (US 11,307,967 B2) teaches
the debug worker node comprises a minimum configuration for handling debug commands (Col 9: ln 30-40, “container pod 300 includes a debugging container 322. The debugging container 322 is a support container configured to perform one or more debugging operations on the test code 312. Specifically, the debugging container 322 may share a process identifier (PID) namespace with the test container 302 and access the PID namespace to perform one or more debugging operations”) Examiner Comments: Zhang teaches creating a debugging container with minimum support configuration (shared PID namespace) for handling debug operations;
processing debug commands from a user via the debug worker node to return the first worker node to a ready state (Col 8: ln 30-40, “The debugging container 322 may supply a user interface (e.g., a web console) configured to receive user input that directs debugging operations”) Examiner Comments: Zhang teaches processing user-directed debug commands via an interactive UI in the debugging container.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Mehta and Ying’s teaching into Zhang’s in order to provide user-interactive debugging capabilities in container environments, enhancing failure analysis by enabling direct user interaction with debug containers through shared namespaces and web consoles, and allocating test requests across multiple test orchestration agents to provide load balancing and improve resource utilization (Zhang [Summary]).
Mehta, Ying and Zhang did not specifically teach
based on detecting, by the debug node agent, that the first worker node enters the not ready state.
However, Lieblich (US 11,163,479 B2) teaches
based on detecting, by the debug node agent, that the first worker node enters the not ready state (Claim 1, “assessing, by the first standby node, a state of at least one additional standby node of the replicated state cluster within a time period after the designation... wherein the assessing comprises comparing a first repository of the at least one additional standby node of the replicated state cluster to a second repository of the second cluster leader”) Examiner Comments: Lieblich teaches assessing the state (ready/not ready) of standby nodes during recovery transitions and directing recovery to nodes that are in the appropriate state, mapping to verifying that the second worker node is in a ready state before issuing recovery requests.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Mehta, Ying and Zhang’s teaching into Lieblich’s in order to provide robust state management during transitions, ensuring that recovery operations are directed to nodes verified to be in a ready state, preventing issues like unsynced standbys in clusters by implementing monitoring communications from a first cluster leader and obtaining a designation as a second cluster leader and thus ensures simple and efficient processing of the change in leadership (Lieblich [Summary]).
Regarding Claim 4, Mehta, Ying, Zhang and Lieblich teach
The computer-implemented method of claim 1.
Mehta did not specifically teach
wherein the creating of the debug worker node is without relying on a container image from an external container image registry.
However, Ying teaches
wherein the creating of the debug worker node is without relying on a container image from an external container image registry. (Paragraph 0017, "automatically generates an image of the first service (based in part on data in the core dump file)") Examiner Comments: Ying teaches generating image locally from core dump, without external registry; this maps directly as it's internal generation.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mehta’s Kubernetes recovery with Ying's debug agent and creation of minimal debug containers because both address failure handling in K8s clusters, and combining allows automated debugging of crashes during failover, improving diagnostics and reducing downtime, as Kubernetes is the de-facto orchestration platform allowing managing micro-service-based cloud-native applications at massive scale (Ying [Background/Summary]).
Regarding Claim 5, Mehta, Ying, Zhang and Lieblich teach
The computer-implemented method of claim 1, wherein the CRD specifies a worker name of the first worker node and bootstrap kube configuration parameters required to bootstrap the debug worker node. (Mehta, Paragraph 0034, " FIG. 2A, shown is a cluster 206 of cloud-native network function (CNF) node groups, such as node group 208, node group 226 and node group 238, hosted within a local zone 204 of a cloud computing service provider cloud. In an example embodiment, the CNF corresponds to and is implemented by one or more software containers of one or more respective pods for scheduling and execution on one or more respective nodes in a software container orchestration platform that automates deployment, management, and scaling of containerized software applications") Examiner Comments: Mehta teaches CNFs (CRD-like) specifying node names and configs for bootstrap; incomplete sentence in claim, but maps as CNFs include bootstrap params. Debug operator via control plane.
Regarding Claim 7, Mehta, Ying, Zhang and Lieblich teach
The computer-implemented method of claim 1, wherein the debug node agent has a taint that prevents all workloads from being deployed other than a debug pod. (Mehta [Paragraph 0038: "The standby pods running on the other cloud compute instance are generated with anti-affinity between the primary CNF instance (e.g., CNF instance CU-CP-1 212) and the standby pod, such that one or more of the CU-CP CNF instances (e.g., CNF instance CU-CP-1 212) running on cloud compute instance 1 can switch to standby pods of another cloud compute instance, such as spare cloud compute instance 218"]) Examiner Comments: Mehta teaches anti-affinity (taint equivalent in K8s) to prevent non-standby workloads; maps to taint preventing others except debug pod.
Regarding Claim 10, Mehta, Ying, Zhang and Lieblich teach
The computer-implemented method of Claim 1, wherein each worker node in the plurality of worker nodes of the cluster has a corresponding instance of a plurality of debug utilities, and the plurality of debug utilities includes the first debug utility and the second debug utility. (Mehta, Paragraph 0034, “Each node group is overprovisioned with one or more spare cloud compute instances within the node group in case any of the CNF instances or eight cloud compute instances of the node group fails”; Ying, Paragraph 0029, “The kubelet is a Kubernetes component that executes on each node of a cluster and acts as an agent for the control plane”) Examiner Comments: The combination teaches that each worker node has its own monitoring/debug utility instance (kubelet/monitoring service), collectively including the first debug utility and the second debug utility.
Regarding Claim 11, is a computer program product claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1.
Regarding Claim 14, is a computer program product claim corresponding to the method claim above (Claim 4) and, therefore, is rejected for the same reasons set forth in the rejection of claim 4.
Regarding Claim 15, is a computer program product claim corresponding to the method claim above (Claim 5) and, therefore, is rejected for the same reasons set forth in the rejection of claim 5.
Regarding Claim 17, is a computer program product claim corresponding to the method claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of claim 7.
Regarding Claim 20, is a system claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1.
Claim(s) 2-3, and 12-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mehta (US 2023/0337018 A1) in view of Ying (US 2025/0028628 A1), Zhang (US 11,307,967 B2) and Lieblich (US 11,163,479 B2) further in view of Nori (US 9336060).
Regarding Claim 2, Mehta, Ying, Zhang and Lieblich teach
The computer-implemented method of claim 1.
Mehta, Ying, Zhang and Lieblich did not specifically teach
wherein the creating of the debug worker node comprises invoking the debug node agent of the debug utility to create the debug worker node, and the minimum configuration comprises at least a portion of binaries copied from the first worker node.
However, Nori (US 9336060) teaches
wherein the creating of the debug worker node comprises invoking the debug node agent of the debug utility to create the debug worker node, (Column 7, Lines 54-67: "The Container Service enables the development, deployment, and management of elastically scalable and available applications. A managed runtime provides a managed process host, managed programming model for stateless and stateful services, logical service endpoints and references for composing services, multi-tenancy, sandboxing support, metering, and resource control.") Examiner Comments: Nori teaches invoking the Container Service (debug node agent equivalent) to deploy and manage services, creating new instances on healthy nodes for recovery; this maps to invoking a debug node agent to create the debug worker node as the Container Service handles deployment of scalable applications in a cluster.
and the minimum configuration comprises at least a portion of binaries copied from the first worker node. (Column 9, Lines 38-50: "Service Manifest captures service metadata such as service type, health properties, pertinent load balancing metrics, and the service binaries and configuration files.") Examiner Comments: Nori teaches the service manifest including binaries and configuration files that are deployed to target nodes; this maps to the minimum configuration comprising binaries copied as the binaries are part of the manifest redistributed to new nodes during recovery.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Mehta, Ying, Zhang and Lieblich’s teaching into Nori’s in order to enable reliable deployment of binaries and configurations in a middleware framework for containerized services, ensuring high availability and seamless recovery in distributed environments and enabling using cloud platforms so as to allow elastic resource utilization and to avoid overcapacity by providing on-demand provisioning of resources (Nori [Backgroud/Summary]).
Regarding Claim 3, Mehta, Ying, Zhang, Lieblich and Nori teach
The computer-implemented method of claim 2.
Mehta, and Ying did not specifically teach
wherein the debug node agent provides a root file system bundle, the debug node agent deploys a privileged debug pod that provides a communication channel through which the user accesses the first worker node and the communication channel is used to issue the debug commands to return the first worker node to the ready state.
However, Zhang teaches
wherein the debug node agent provides a root file system bundle, the debug node agent deploys a privileged debug pod that provides a communication channel through which the user accesses the first worker node and the communication channel is used to issue the debug commands to return the first worker node to the ready state. (Col 9: 30-40, "The debugging container 322 may share a process identifier (PID) namespace with the test container 302 and access the PID namespace to perform one or more debugging operations. The debugging container 322 may supply a user interface (e.g., a web console) configured to receive user input that directs debugging operations.") Examiner Comments: Zhang teaches providing shared namespace (root bundle equivalent) and deploying privileged debug container with channel/UI for commands; this maps to privileged pod and channel for access.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Mehta and Ying’s teaching into Zhang’s in order to provide user-interactive debugging in container environments, enhancing failure analysis and allocating test request across multiple test orchestration agents to provide load balancing and improve resource utilization by executing test execution plans performed in a first test container including a first instance of the container image that encapsulates the test environment generated.
Regarding Claim 12, is a computer program product claim corresponding to the method claim above (Claim 2) and, therefore, is rejected for the same reasons set forth in the rejection of claim 2.
Regarding Claim 13, is a computer program product claim corresponding to the method claim above (Claim 3) and, therefore, is rejected for the same reasons set forth in the rejection of claim 3.
Claim(s) 6 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mehta (US 2023/0337018 A1) in view of Ying (US 2025/0028628 A1), Zhang (US 11,307,967 B2) and Lieblich (US 11,163,479 B2) further in view of Takahashi (US11119846B2).
Regarding Claim 6, Mehta, Ying, Zhang and Lieblich teach
The computer-implemented method of claim 1.
Mehta, Ying, Zhang and Lieblich did not specifically teach
wherein the creating of the debug worker node in the cluster based on the CRD comprises deploying a debug pod to a running container of the debug worker node, and the debug pod provides an interface through which an authorized user is able to issue commands to the debug worker node to debug the first worker node.
However, Takahashi (US11119846B2) teaches
wherein the creating of the debug worker node in the cluster based on the CRD comprises deploying a debug pod to a running container of the debug worker node, (Column 10, Lines 3-33: " CFP program 101 generates a replica test pod. The replica test pod is a temporary replica pod added to the set of replica pods and built from the same pod template as the set of replica pods. Thus, any application containers within the environment of the replica test pod are also identical to the application containers in the set of replica pods, such as replica pods 130, 140, and 160. In alternative embodiments, CFP program 101 generates a replica test application container. In embodiments of the invention, CFP program 101 blocks or drops URI requests generated by the application in the replica test pod that were determined in step S204 to be the root cause of the anomaly. In these embodiments, CFP program 101 may drop requests directed to a host, path, query string parameter, variable and/or range of variables paired with a query string parameter.") Examiner Comments: Takahashi teaches generating and deploying a replica test pod (debug pod) on a new server (debug worker node) to test and debug anomalies in the original replica pods; this maps to deploying a debug pod to a running container of the debug worker node as the test pod is added for verification and runs on a new host server.
and the debug pod provides an interface through which an authorized user is able to issue commands to the debug worker node to debug the first worker node. (Column 6, Lines 55-67: "Client device 180 includes user interface 185. User interface 185 provides an interface between client device 180, host servers 110, and management server 170. In some embodiments, user interface 185 may be a graphical user interface (GUI) or a web user interface (WUI) and can display text, documents, web browser windows, user options, application interfaces, and instructions for operation, and includes the information (such a graphic, text, and sound) that a program presents to a user and the control sequences the user employs to control the program") Examiner Comments: Takahashi teaches a GUI or WUI that provides user options and application interfaces for interaction with the pods and servers; this maps to the debug pod providing an interface for authorized user to issue commands to debug as the UI enables user interaction with the test pod setup to analyze and fix anomalies in the first set of pods.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Mehta, Ying, Zhang and Lieblich’s teaching into Takahashi’s in order to enable isolated testing of anomalies in replica pods by deploying test pods on new nodes, improving debugging accuracy and preventing disruption to production environments by identifying a set of anomalies during a runtime of a first set of replica application containers and a root cause of the set of anomalies is determined based on comparing uniform resource identifier (URI requests generated by each replica application container in the set of replica application containers (Takahashi [Bacground/Summary]).
Regarding Claim 16, is a computer program product claim corresponding to the method claim above (Claim 6) and, therefore, is rejected for the same reasons set forth in the rejection of claim 6.
Claim(s) 8 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mehta (US 2023/0337018 A1) in view of Ying (US 2025/0028628 A1), Zhang (US 11,307,967 B2) and Lieblich (US 11,163,479 B2) further in view of Kumandur (US20200177373A1).
Regarding Claim 8, Mehta, Ying, Zhang and Lieblich teach
The computer-implemented method of claim 1.
Mehta, Ying, Zhang and Lieblich did not specifically teach
wherein the request is a request for a bootstrap kube configuration, and, based on the debug proxy returning a response to the debug node agent: creating a certificate signing request (CSR) with an expiration time; awaiting a user approval of the CSR; receiving he user approval of the CSR; and extracting based on the receiving the user approval of the CSR a key and certificate from the CSR to register with a kube api-server on the master node.
However, Kumandur (US20200177373A1) teaches
wherein the request is a request for a bootstrap kube configuration, and, based on the debug proxy returning a response to the debug node agent: (Paragraph 0143: "The certificate creation for nodes (endorser, orderer, Fabric CA L2) are used to be performed to bootstrap the network.") Examiner Comments: Kumandur teaches requesting certificate provisioning (analogous to bootstrap config) for node bootstrap in a containerized environment; this maps to the request for bootstrap kube configuration as certificates are required to bootstrap secure node communication.
creating a certificate signing request (CSR) with an expiration time; (Paragraph 0172: "After the CSRs creation there are ..."; from detailed description: "openssl req -new -key FinancialInstitution-BIGAP-ORG-NY-PROD.key -out FinancialInstitution-BIGAP-ORG-NY-PROD.csr") Examiner Comments: Kumandur teaches creating CSR using OpenSSL for node certificates during bootstrap; this maps to creating CSR as the command generates the CSR file for submission. (Paragraph 0144,: "Ongoing maintenance of these certificates (revocation, expiry, renewal etc.) can be performed for all of these types of certificates.") Examiner Comments: Kumandur teaches certificates with expiry times for maintenance; this maps to CSR with expiration time as the generated certificates from CSR include expiry attributes.
awaiting a user approval of the CSR; and (Paragraph 0144: " The certificates for the node application is also required to enable the application to persist IG objects onto the Blockchain ledger. However, in some embodiments user certificates are not created ahead of time, they are provisioned on demand (using respective organization's L2 Fabric CA) when the user logs into the application. Ongoing maintenance of these certificates (revocation, expiry, renewal etc.) can be performed for all of these types of certificates.” ) Examiner Comments: Kumandur teaches submission of CSR to Fabric CA for signing, which involves an approval-like process by the CA; this maps to awaiting user approval as in secure systems, CA signing serves as approval step.
receiving he user approval of the CSR; and extracting based on the receiving the user approval of the CSR a key and certificate from the CSR to register with a kube api-server on the master node. (Paragraph 0137-0141, " Fabric CA is a Certificate Authority for the Hyperledger Fabric blockchain network. It provides features such as … Issuance of Enrollment Certificates (ECerts) for users, nodes (peers, orderers etc.) "; Paragraph 0150, " Endorsers' certificates and keys can be stored in a keystore located in /bchainlbigap-certificates/crypto/peerOrganization ") Examiner Comments: Kumandur teaches extracting keys and certificates after CA signing for node registration in the network; this maps to extracting key/cert to register with api-server as enrollment registers the node with the ordering service/master equivalent.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Mehta, Ying, Zhang and Lieblich’s teaching into Kumandur’s in order to incorporate secure CSR-based bootstrapping in containerized clusters, enhancing authentication and preventing unauthorized node access during recovery by receiving an input set of data fields representing parameters of an agreement between multiple parties and the agreement object is inserted onto the blockchain data structure on a distributed ledger data structure of a first node of computing nodes (Kumandur [Background/Summary]).
Regarding Claim 18, is a computer program product claim corresponding to the method claim above (Claim 8) and, therefore, is rejected for the same reasons set forth in the rejection of claim 8.
Claim(s) 9 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mehta (US 2023/0337018 A1) in view of Ying (US 2025/0028628 A1), Zhang (US 11,307,967 B2) and Lieblich (US 11,163,479 B2) further in view of Cully (US 20240202122).
Regarding Claim 9, Mehta, Ying, Zhang and Lieblich teach
The computer-implemented method of claim 1.
Mehta, Ying, Zhang and Lieblich did not specifically teach wherein the debug commands comprise a kubectl exec command and a command to open a bash terminal to run commands to bring the first worker node to the ready state.
However, Cully (US 20240202122) teaches
wherein the debug commands comprise a kubectl exec command and a command to open a bash terminal to run commands to bring the first worker node to the ready state. (Paragraph 0024: "An application commonly known as kubectl runs on user computers 10, and an application administrator or developer (hereinafter referred to as the “user”), employs kubectl, and a configuration file (which contains the credentials to authenticate with the Kubernetes server) can issue commands to the Kubernetes server. For example, through kubectl, the user submits desired states of the Kubernetes system, e.g., as YAML documents, to Kubernetes server 104. In response, Kubernetes server 104 schedules pods onto (i.e., assigns them to) different hosts 120 (which are also nodes of a Kubernetes cluster in the embodiments).")
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Mehta, Ying, Zhang and Lieblich’s teaching into Cully’s in order to enable allowing the first node to perform write operation on the page residing in a second node when the page is in the shared state in connection with performing read operation on the second page, maintaining memory coherence of the initiator node and acceptor nodes in an effective manner without using remote procedure calls in a reliable manner and performing virtual management migration between hosts (Cully [Background/Summary]).
Regarding Claim 19, is a computer program product claim corresponding to the method claim above (Claim 9) and, therefore, is rejected for the same reasons set forth in the rejection of claim 9.
Response to Arguments
Applicant argues “Mehta describes generating a standby pod before detection of a failure. Mehta further describes detecting the failure of the pod running on a first cloud compute instance. Furthermore, Mehta describes switching from the pod, for which the failure is detected, to the standby pod already running on a second cloud compute instance. Thus, Mehta describes generation of the standby pods before the detection of the failure.”
Examiner respectfully disagrees. While Applicant correctly notes that Mehta pre-generates standby pods before failure detection, Mehta is not relied upon alone to teach all the claimed limitations. Mehta is relied upon for teaching the overall framework of a Kubernetes-based cluster environment where failure of pods/nodes on a first cloud compute instance triggers a recovery action involving a different cloud compute instance that is in a ready/healthy state. Specifically, Mehta teaches that in response to detecting a failure on a first cloud compute instance, the system utilizes resources on a second, healthy cloud compute instance (Paragraph 0044). This cross-node recovery mechanism directing recovery operations to a second worker node that is in a ready state provides the foundational teaching. The fact that Mehta pre-creates the standby pods is addressed by the combination with Ying, which teaches creating debug containers/pods in response to detecting failure.
Applicant further argues “Ying merely describes detecting the crashing of the first Pod 310 of the node 305 and instantiating the new pod on the same node 305.”
Examiner respectfully disagrees. Ying is relied upon primarily for teaching the concept of reactively creating a debug container/pod in response to detecting a failure condition (core dump, crash). The location of the created debug resource (same node vs. different node) is addressed by the combination with Mehta’s cross-node architecture. When a worker node enters a not ready state in Kubernetes, the failing node cannot host new pods (Kubernetes will not schedule pods on NotReady nodes). Therefore, combining Mehta’s cross-node recovery with Ying’s reactive debug container creation would logically result in creating the debug container on a different, healthy worker node, since the failing node cannot host new workloads. This follows directly from how Kubernetes operates and is not a mere conclusory assertion.
Applicant further argues Zhang “merely describes that a container pod 300 includes a debugging container 322” on the same test container.
Examiner respectfully disagrees. Zhang is relied upon for teaching the specific architecture of a debugging container with minimum configuration (shared PID namespaces) and a user interface for directing debugging operations (Col 9: ln 30-40). Zhang is not relied upon for the cross-node recovery aspects. The combination addresses different aspects: Mehta provides the cross-node failover framework, Ying provides reactive creation of debug resources upon failure detection, Zhang provides the debugging container architecture, and Lieblich provides state assessment of standby nodes.
Applicant further argues Lieblich does not remedy the deficiencies of Mehta, Ying, and Zhang.
Examiner respectfully disagrees. Lieblich teaches assessing the state (ready/not ready) of additional standby nodes during recovery transitions (Claim 1), which maps to verifying that the second worker node is in a ready state before issuing recovery requests. The combination of all four references renders the amended claims obvious as discussed above.
Conclusion
THIS ACTION IS MADE FINAL. 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 AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm 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, Wei Mui can be reached at (571) 272-3708. 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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights