DETAILED ACTION
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 .
This Office Action is in response to the amendment filed on 4/6/2026. This action is made FINAL.
Claims 1-20 are pending and they are presented for examinations.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 10 and 20 contains the trademark/trade name Kubernetes. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe “Computer software for accessing, browsing, sharing, defining, maintaining, virtualizing and communicating information over computer networks, servers and secure private networks” and, accordingly, the identification/description is indefinite.
Response to Arguments
Applicant's arguments filed regarding claim 10 and 20 (page 8-9), “Instead, Applicant’s claim uses Kubernetes as an adjective modifying clear generic descriptors: “the containerized software environment includes a Kubernetes cluster”. Kubernetes, as would be understood by a person having ordinary skill in the art, is “an open source system for automating deployment, scaling, and management of containerized applications”.
The argument is not persuasive. The term “Kubernetes” is used to identify the product (Kubernetes) which is included in the containerized software environment. Furthermore, the owner of the trademark, at any point in time can modify the description of what Kubernetes is presently to another definition.
Applicant's arguments filed regarding claim 1 (page 12), “Sharma and Vaidya fails to disclose or suggest creation of a Vnic on a worker-node and job-based injection of the Vnic.”… “Sharma does not teach or suggest executing a job to inject a Vnic. The Examiner asserts that Sharma teaches “execute a job …. to inject the Vnic into the application pod” but none of the cited provisions actually teach execution of any job to inject a Vnic into an application pod.
The examiner would like to point out to the instant application which provides a description of a job-based injection per applicants’ argument. As shown below, the job-based injection moves the Vnic from a namespace to another namespace.
[Instant PGPub paragraph 7], “In some examples, the VnicSet operator system may generate a Vnic resource file as part of creating the Vnic, inject the Vnic including moving the Vnic from a namespace of the worker node to a namespace of the application pod, and update an association in the Vnic resource file to identify the application pod.”
Similarly, Sharma in view of Vaidya discloses the above limitation. As previously rejected, Sharma discloses CNI creating a virtual network interfaces (i.e. Vnic(s)) to provide connectivity (to enable communication). In addition to creating virtual network interfaces, it also inserts a virtual network interface for a virtual network into the network interface namespace for containers in pod.
Furthermore, a job is merely an instructing a computing system to execute an instruction/process to perform a task. Therefore, the examiners interpretation of executing a job vs. the description of job-based injection via a job is consistent. Vaidya further supports executing instruction(s) (i.e. job(s)) to namespace of pods for virtual network interface(s) as previous rejected.
[Sharma paragraph 65], “For example, the CNI 17A creates virtual network interfaces to connect pods to virtual router 21A and enable containers of such pods to communicate, via the virtual network interfaces, to other virtual network endpoints over the virtual networks. CNI 17A may, for example, insert a virtual network interface for a virtual network into the network namespace for containers in pod 22A and configure (or request to configure) the virtual network interface…”
Therefore, based on the disclosure of the instant application, the argument is not persuasive.
Applicant's arguments filed regarding claim 1 (page 13), “Vaidya does not disclose: Creating a Vnic on a worker node independent of pod lifecycle; or Executing a job on that worker node to inject the Vnic into the pod”.
The examiner would like to point out to the instant application which discloses control plane extended into worker nodes. Control plane which extends into worker nodes would in fact make the worker nodes a control plane.
[Instant paragraph 53], “In some embodiments, operators (e.g., VnicSet operator 414 and CnApp operator 418) may run in the worker nodes 422-426. Because operators may implement controllers in the worker nodes 422-426, but controllers may run in the control plane 402, operators may effectively extend the control plane 402 into the worker nodes 422-426”.
As previously stated (prior rejection) Vaidya discloses the concept of master/worker nodes (minion nodes) in a cluster environment which virtual execution element(s) is/are created wherein virtual execution environments are created via namespace (i.e. job-based execution).
[Vaidya paragraph 153], “select the computing device 200 as the host minion node for the pod 202A. API server 320 may annotate the pod 202A with a list of multiple virtual networks and a uuid for the pod (pod_uuid). Other forms of identifiers for the pod may be used. The annotations may be labels for the pod configuration that indicate the virtual networks, such as “virtual network A” and “virtual network B”.”
[Vaidya paragraph 158], “To create each of the virtual network interfaces 212A, 212B indicated in interface configuration data 25 (416), network module 206A may insert the virtual network interface into the pod 202A network namespace (e.g., one end of a veth pair that is the virtual network interface)”
Sharma in view of Vaidya both discloses utilizing namespace (i.e. job-based execution) to create/inject Vnic(s) within a Kubernetes cluster environment as similarly disclosed by the instant application on multiple occasions (for example: instant paragraph 7, 67).
Therefore, argument is not persuasive.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-5, 11-15, 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (Pub 20240422107) (hereafter Sharma) in view of Vaidya et al. (Pub 20200076685) (hereafter Vaidya).
As per claim 1, Sharma teaches:
A custom operator (VnicSet operator) system, comprising:
one or more processors; ([Paragraph 4], Virtualization within a data center can provide several advantages. One advantage is that virtualization can provide significant improvements to efficiency. As the underlying physical computing devices (i.e., servers) have become increasingly powerful with the advent of multicore microprocessor architectures with a large number of cores per physical CPU, virtualization becomes easier and more efficient. [Paragraph 35], In general, a virtual machine provides a virtualized/guest operating system for executing applications in an isolated virtual environment. Because a virtual machine is virtualized from physical hardware of the host server, executing applications are isolated from both the hardware of the host and other virtual machines. Each virtual machine may be configured with one or more virtual network interfaces for communicating on corresponding virtual networks.)
a memory having stored thereon instructions that, upon execution by the one or more processors, cause the one or more processors to implement a process to manage a virtual network interface controller (Vnic) on an application pod of a containerized software environment, the Vnic being directly reachable from a network external to the containerized software environment, the process including: ([Paragraph 65], Container platform 19A includes a container network interface (CNI) 17A that configures virtual network interfaces for virtual network endpoints. [Paragraph 84], In the context of FIG. 1, both DPDK-enabled virtual router 21A and DPDK-enabled pod 22A may communicate with respective virtual functions 27A, 27B of NIC 13A. DPDK Pod 22A has a separate data interface 28 with virtual router 21A but can communicate directly with virtual function 27A using DPDK. [Paragraph 131], Virtual router 220 receives the inner packet and layer 2 header and determines a virtual network for the inner packet. Virtual router 220 may determine the virtual network using any of the above-described virtual network interface implementation techniques (e.g., macvlan, veth, etc.). Virtual router 220 uses the VRF 222A corresponding to the virtual network for the inner packet to generate an outer header for the inner packet, the outer header including an outer IP header for the overlay tunnel and a tunnel encapsulation header identifying the virtual network. Virtual router 220 encapsulates the inner packet with the outer header. Virtual router 220 may encapsulate the tunnel packet with a new layer 2 header having a destination layer 2 (L2) address associated with a device external to the computing device 200, e.g., a TOR switch 16 or one of servers 12. If external to computing device 200, virtual router 220 outputs the tunnel packet with the new layer 2 header to NIC 230 using physical function 221. NIC 230 outputs the packet on an outbound interface. If the destination is another virtual network endpoint executing on computing device 200, virtual router 220 routes the packet to the appropriate one of virtual network interfaces 212, 213. )
identify the application pod to which to add the Vnic;
determine a worker node in the containerized software environment on which the application pod is running;
create the Vnic on the worker node; and
execute a job on the worker node to inject the Vnic into the application pod. ([Paragraph 65], For example, the CNI 17A creates virtual network interfaces to connect pods to virtual router 21A and enable containers of such pods to communicate, via the virtual network interfaces, to other virtual network endpoints over the virtual networks. CNI 17A may, for example, insert a virtual network interface for a virtual network into the network namespace for containers in pod 22A and configure (or request to configure) the virtual network interface for the virtual network in virtual router 21A such that the virtual router 21A is configured to send packets received from the virtual network via the virtual network interface to containers of pod 22A and to send packets received via the virtual network interface from containers of pod 22A on the virtual network. CNI 17A may assign a network address (e.g., a virtual IP address for the virtual network) and may set up routes for the virtual network interface. [Paragraph 12], In some aspects, the techniques include an application package for deployment and a control flow for configuring and deploying a virtual router using a computing device-based orchestrator and a custom resource. The custom resource for virtual router configuration may include configuration elements conventionally exposed by a physical or virtual router, but the configuration elements may be consolidated along with Kubernetes native/built-in resources to support a unified intent model that is realized by Kubernetes controllers and by custom resource controller(s) that work to reconcile the actual state of the virtual router with the intended state. The application package for the virtual router and provided to the orchestrator, executing on the computing device, includes a deployer pod to create the virtual router custom resource definition (CRD) with the orchestrator, which then (1) monitors and reconciles the virtual router custom resource instance on configuration changes, and (2) deploys (including redeploying/restarting) the virtual router pod that includes those containers used to implement the virtual router with the requested configurations. As a result, the techniques provide a technical improvement in that the administrator for the network or a distributed application, when performing virtual router deployment and configuration, is able to rely on a cloud-native framework that leverages an orchestrator interface to simplify configuring or reconfiguring a virtual router, even for configurations that must occur at virtual router initialization. [Paragraph 45], For example, a virtual network endpoint may be a virtual machine, a set of one or more containers (e.g., a pod), or another other virtual computing instance(s), such as a layer 3 endpoint for a virtual network. The term “virtual computing instance” encompasses virtual machines, containers, and other virtualized computing resources that provide an at least partially independent execution environment for applications. The term “virtual computing instance” encompasses a pod of one or more containers. As shown in FIG. 1, server 12A hosts one virtual network endpoint in the form of pod 22A having one or more containers. However, a server 12 may execute as many virtual computing instances as is practical given hardware resource limitations of the server 12. Each of the virtual network endpoints may use one or more virtual network interfaces to perform packet I/O or otherwise process a packet. For example, a virtual network endpoint may use one virtual hardware component (e.g., an SR-IOV virtual function) enabled by NIC 13A to perform packet I/O and receive/send packets on one or more communication links with TOR switch 16A. Other examples of virtual network interfaces are described below. [Paragraph 46], As another example, one or more servers 12 may implement Open vSwitch to perform distributed virtual multilayer switching between one or more virtual NICs (vNICs) for hosted virtual machines, where such vNICs may also represent a type of virtual hardware component that provide virtual network interfaces to virtual network endpoints. [Paragraph 147], Scheduler 322 monitors for newly created or requested virtual computing instances (e.g., pods of containers) and selects a minion node on which the virtual computing instances are to run. Scheduler 322 may select a minion node based on resource requirements, hardware constraints, software constraints, policy constraints, locality, etc. Scheduler 322 may represent a Kubernetes scheduler.)
Although Sharma discloses monitoring for newly created or request virtual computing instances (e.g. pods) and selects a worker (e.g. compute/minion) node on which a virtual computing instances are to run.
Sharma does not explicitly disclose determine a worker node in the containerized software environment on which the application pod is running.
Vaidya teaches determine a worker node in the containerized software environment on which the application pod is running.
Vaidya also teaches create the Vnic on the worker node; and
execute a job on the worker node to inject the Vnic into the application pod. ([Paragraph 49], Each of orchestrator 23 and network controller 24 may be a distributed application that executes on one or more computing devices. Orchestrator 23 and network controller 24 may implement respective master nodes for one or more clusters each having one or more minion nodes implemented by respective servers 12. In general, network controller 24 controls the network configuration of the data center 10 fabric to, e.g., establish one or more virtual networks for packetized communications among virtual network endpoints. [Paragraph 140], In general, API server 320 may invoke the scheduler 322 to schedule a virtual execution element, which may select a minion node and returns an identifier for the selected minion node to API server 320, which may write the identifier to the configuration store 328 in association with the virtual execution element. API server 320 may invoke the orchestration agent 209 for the selected minion node, which may cause the container engine 208 for the selected minion node to obtain the virtual execution element from a storage server and create the virtual execution element on the minion node. The orchestration agent 209 for the selected minion node may update the status for the virtual execution element to the API server 320, which persists this new state to the configuration store 328. In this way, computing device 300 instantiates new virtual execution elements in the computing infrastructure 8.)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Sharma wherein a virtual network interface controller (VNIC) is implemented on an application pod of a containerized software environment, the application pod is identified to add the VNIC, and VNIC is created, into teachings of Vaidya wherein application pod is a distributed application that executes on one or more worker nodes (e.g. worker/computer/minion) to be determined/identified, because this would enhance the teachings of Sharma wherein by identifying all worker node(s) of the distributed application pod, it allows an orchestration agent for the selected worker node to create the virtual execution element (i.e. vnic) to be created/injected and configured, thus enabling communication with other pods of the cluster on a corresponding networks, or externally to virtual networks and pods of the cluster. [Vaidya paragraph 140, 160]
As per claim 2, rejection of claim 1 is incorporated:
Sharma teaches further comprising instructions that, upon execution, cause the one or more processors to:
receive a resource definition data to define attributes of the Vnic; and
identify the application pod to which to add the Vnic based on the resource definition data. ([Paragraph 12], The custom resource for virtual router configuration may include configuration elements conventionally exposed by a physical or virtual router, but the configuration elements may be consolidated along with Kubernetes native/built-in resources to support a unified intent model that is realized by Kubernetes controllers and by custom resource controller(s) that work to reconcile the actual state of the virtual router with the intended state. The application package for the virtual router and provided to the orchestrator, executing on the computing device, includes a deployer pod to create the virtual router custom resource definition (CRD) with the orchestrator, which then (1) monitors and reconciles the virtual router custom resource instance on configuration changes, and (2) deploys (including redeploying/restarting) the virtual router pod that includes those containers used to implement the virtual router with the requested configurations. [Paragraph 65], Container platform 19A includes a container network interface (CNI) 17A that configures virtual network interfaces for virtual network endpoints. Orchestrator 23A and container platform 19A uses CNI 17A to manage networking for pods, including pod 22A. For example, the CNI 17A creates virtual network interfaces to connect pods to virtual router 21A and enable containers of such pods to communicate, via the virtual network interfaces, to other virtual network endpoints over the virtual networks. CNI 17A may, for example, insert a virtual network interface for a virtual network into the network namespace for containers in pod 22A and configure (or request to configure) the virtual network interface for the virtual network in virtual router 21A such that the virtual router 21A is configured to send packets received from the virtual network via the virtual network interface to containers of pod 22A and to send packets received via the virtual network interface from containers of pod 22A on the virtual network.)
Vaidya also teaches ([Paragraph 69], The above example specifies the four virtual networks using Kubernetes network (CustomResourceDefinition) Objects to conform the virtual network specifications to the Kubernetes Custom Resource Definition De-facto Standard, which specifies requirements and procedures for attaching Kubernetes pods to one or more virtual or physical networks, including requirements for plugins using the Container Network Interface (CNI) to attach pod networks. [Paragraph 79], JSON keys may be defined for network attachment maps. For example, “name,” “namespace,” and “ips” represent JSON keys. The “name” key is the name of a NetworkAttachmentDefinition object, either in the Pod's namespace (if the “namespace” key is missing or empty) or another namespace specified by the “namespace” key. In some examples, the “namespace” key defines a value type string and gives the namespace of the NetworkAttachmentDefinition object named by the “name” key. The “ips” key is a value of type string-array.)
As per claim 3, rejection of claim 2 is incorporated:
Vaidya teaches further comprising: the resource definition data includes a pod identifier for the application pod; and
the instructions, upon execution, further cause the one or more processors to determine the worker node based on the pod identifier. ([Paragraph 9], In general, techniques are described for specifying a list of virtual networks of a network infrastructure for virtual execution elements and creating multiple virtual network interfaces usable by the virtual execution elements for communicating via the virtual networks. For example, a namespace specification data for a virtualized computing infrastructure namespace may specify multiple virtual networks. Based on the namespace specification data, an orchestrator for the virtualized computing infrastructure may deploy virtual execution elements, labeled with the namespace, to the namespace. Based on the multiple virtual networks specified in the namespace specification data, the orchestrator may cause a network controller for the virtualized computing infrastructure to configure the virtual execution elements with respective virtual network interfaces for the multiple virtual networks. [Paragraph 77], As seen in the above data, the data specifies an object of kind: Pod. The pod is named “my-pod” and the namespace is “my-namespace”. The annotation specifies three virtual networks “net-a,” “net-b,” and “net-c.” In this example, “net-a” and “net-b” are within “my-namespace,” however “net-c” is within another namespace “other-ns”. As such, the virtual execution element specification data corresponding to a pod may annotate a list of virtual networks in which the pod is to be placed, and the list of virtual networks may include virtual networks that are within the namespace of the pod or another namespace.)
As per claim 4, rejection of claim 2 is incorporated:
Vaidya teaches further comprising instructions that, upon execution, cause the one or more processors to: determine whether a fixed internet protocol (IP) address for the Vnic is provided in the resource definition data;
associate the fixed IP address provided in the resource definition data to the Vnic when the fixed IP address is provided; and
dynamically allocate the fixed IP address to the Vnic via dynamic host configuration protocol (DHCP) when the fixed IP address is not provided in the resource definition data. ([Paragraph 53], Network controller 23 creates a virtual network that is shared by all namespaces, from which service and pod IP addresses are allocated. All pods in all namespaces that are spawned in a cluster are able to communicate with one another. The IP addresses for all of the pods are allocated from a pod subnet that is configured in the orchestrator 23. [Paragraph 73], Typically, containers within a pod have a common IP address and port space and are able to detect one another via the localhost. Because they have a shared context, containers within a pod are also communicate with one another using inter-process communications (IPC). [Paragraph 78], irtual execution element specification data corresponding to a pod may also include pod-specific requirements for attachment to one or more virtual networks, such as specific IP addresses and Media Access Control (MAC) addresses associated with at least one virtual network specified in the annotation. For example, the virtual execution element specification data may be given by the following JSON data:… Table 4.. [Paragraph 79], JSON keys may be defined for network attachment maps. For example, “name,” “namespace,” and “ips” represent JSON keys. The “name” key is the name of a NetworkAttachmentDefinition object, either in the Pod's namespace (if the “namespace” key is missing or empty) or another namespace specified by the “namespace” key. In some examples, the “namespace” key defines a value type string and gives the namespace of the NetworkAttachmentDefinition object named by the “name” key. The “ips” key is a value of type string-array. Moreover, the “ips” key requires the plugin handling a network attachment to assign the given IP addresses to the pod. The value of the IPS key must contain at least one array element and each element must be a valid IPv4 or IPv6 address.)
As per claim 5, rejection of claim 1 is incorporated:
Vaidya teaches further comprising instructions that, upon execution, cause the one or more processors to: create the Vnic includes generating a Vnic resource file; inject the Vnic includes moving the Vnic from a namespace of the worker node to a namespace of the application pod; and update an association in the Vnic resource file to identify the application pod. ([Paragraph 69], The above example specifies the four virtual networks using Kubernetes network (CustomResourceDefinition) Objects to conform the virtual network specifications to the Kubernetes Custom Resource Definition De-facto Standard, which specifies requirements and procedures for attaching Kubernetes pods to one or more virtual or physical networks, including requirements for plugins using the Container Network Interface (CNI) to attach pod networks. [Paragraph 79], JSON keys may be defined for network attachment maps. For example, “name,” “namespace,” and “ips” represent JSON keys. The “name” key is the name of a NetworkAttachmentDefinition object, either in the Pod's namespace (if the “namespace” key is missing or empty) or another namespace specified by the “namespace” key. In some examples, the “namespace” key defines a value type string and gives the namespace of the NetworkAttachmentDefinition object named by the “name” key. The “ips” key is a value of type string-array. [Paragraph 62], If this annotation is configured on a pod specification (pod configuration data), then the pod is launched in the named network. If the annotation is configured in the namespace specification (namespace specification data), then all the pods in the namespace are launched in the provided network. In some examples, network controller 24 must configure the virtual network in computing infrastructure 8 before the virtual network name can be used to annotate a pod or namespace. In some examples, network controller 24 can configure additional virtual networks in computing infrastructure 8 as part of deploying virtual execution elements that will use the additional virtual networks. [Paragraph 64], In the example illustrated in FIG. 1, orchestrator 23 accepts namespace specification data 27 as an input. Namespace specification data 27 may be encoded with a human-readable data serialization language, such as YAML Ain't Markup Language (YAML), JavaScript Object Notation (JSON), or the like. Namespace specification data 27 may represent a “namespace specification” or “namespace spec.” [Paragraph 153], FIG. 4 is a flow diagram illustrating the creation of multiple network virtual interfaces for a virtual execution element using a single network module, according to techniques described in this disclosure. The operations are described with respect to components of computing devices 200 and 300 of FIGS. 2-3. API server 320 receives a request to instantiate a pod 202A and modifies the configuration store 328 with configuration for creating the pod 202A (402). [Paragraph 164], FIG. 5 is a flow diagram illustrating the creation of multiple network virtual interfaces for a virtual execution element based on a namespace, according to techniques described in this disclosure. The operations are described with respect to components of computing devices 200 and 300 of FIGS. 2-3. API server 320 receives a request to create one or more namespaces and modifies the configuration store 328 with configuration for creating the one or more namespaces (502). In some examples, the request to create the one or more namespaces includes namespace specification data 27. For example, namespace specification data 27 may be encoded with a human-readable data serialization language (e.g., YAML, JSON, or the like). Namespace specification data 27 designates at least one namespace. Additionally, each namespace of the at least one namespace specifies a plurality of virtual networks. Network controller manager 325 generates namespace configuration data based on namespace specification data 27 and directs network controller 324 to create the virtual networks based on the namespace specification data (504).)
As per claim 10, rejection of claim 1 is incorporated:
Sharma teaches further comprising the containerized software environment includes a Kubernetes cluster. ([Paragraph 6], With containers' inherently lightweight nature, a single host can often support many more container instances than traditional virtual machines (VMs). Often short-lived, containers can be created and moved more efficiently than VMs, and they can also be managed as groups of logically related elements (sometimes referred to as “pods” for some orchestration platforms, e.g., Kubernetes). [Paragraph 7], A computing infrastructure that manages deployment and infrastructure for application execution may involve two main roles: (1) orchestration—for automating deployment, scaling, and operations of applications across clusters of hosts and providing computing infrastructure, which may include container-centric computing infrastructure)
As per claims 11-15 and 20, these are method claims corresponding to the system claims 1-5 and 10. Therefore, rejected based on similar rationale.
Claim(s) 6-9 and 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma in view of Vaidya and further in view of Mariappan et al. (Pub 20220278927) (hereafter Mariappan).
As per claim 6, rejection of claim 1 is incorporated:
Although Sharma in view of Vaidya disclose stale interface cleanup ([Sharma Table 1]) and lifecycle controller (i.e. namespace creation for application pod/container) ([Vaidya Paragraph 141]).
Sharma in view of Vaidya do not explicitly disclose further comprising instructions that, upon execution, cause the one or more processors to: execute a reconciler loop to manage the Vnic, the reconciler loop including: a finalizer module configured to delete a Vnic marked for deletion; a stale resource module configured to delete a Vnic associated with a terminated application pod; and a creation module configured to create a Vnic on a target application pod.
Mariappan teaches further comprising instructions that, upon execution, cause the one or more processors to: execute a reconciler loop to manage the Vnic, the reconciler loop including: a finalizer module configured to delete a Vnic marked for deletion; a stale resource module configured to delete a Vnic associated with a terminated application pod; and a creation module configured to create a Vnic on a target application pod. ([Paragraph 110], A network controller manager (e.g., network controller manager 325 of FIG. 3) listens to pod creation/deletion/update events for orchestrator 23. On detecting a new pod creation event, the network controller manager parses the pod information and creates corresponding interface configuration data for each virtual network interface to be configured for pod 202A. The network controller manager passes this interface configuration data to virtual router agent 216, optionally via network controller 24 having an interface with virtual router agent 216 to manage virtual routing in computing device 200. [Paragraph 146], Configuration store 328 is a backing store for all cluster data. Cluster data may include cluster state and configuration data. Configuration data may also provide a backend for service discovery and/or provide a locking service. Configuration store 328 may be implemented as a key value store. Configuration store 328 may be a central database or distributed database. Configuration store 328 may represent an etcd store. Configuration store 328 may represent a Kubernetes configuration store.)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Sharma and Vaidya wherein a virtual network interface controller (VNIC) is implemented on an application pod of a containerized software environment, the application pod which executes on a worker node(s) is/are identified to add the VNIC, and VNIC is created, into teachings of Mariappan wherein VNIC is deleted for terminated application pod and created on a target application pod, because this would enhance the teachings of Sharma and Vaidya wherein by monitoring pod information for created/deleted application pod, corresponding VNIC can be created/deleted.
As per claim 7, rejection of claim 6 is incorporated:
Mariappan teaches further comprising instructions that, upon execution, cause the one or more processors to: detect a create Vnic event; and invoke the creation module to identify the application pod and to create the Vnic. ([Paragraph 110], A network controller manager (e.g., network controller manager 325 of FIG. 3) listens to pod creation/deletion/update events for orchestrator 23. On detecting a new pod creation event, the network controller manager parses the pod information and creates corresponding interface configuration data for each virtual network interface to be configured for pod 202A. The network controller manager passes this interface configuration data to virtual router agent 216, optionally via network controller 24 having an interface with virtual router agent 216 to manage virtual routing in computing device 200. [Paragraph 146], Configuration store 328 is a backing store for all cluster data. Cluster data may include cluster state and configuration data. Configuration data may also provide a backend for service discovery and/or provide a locking service. Configuration store 328 may be implemented as a key value store. Configuration store 328 may be a central database or distributed database. Configuration store 328 may represent an etcd store. Configuration store 328 may represent a Kubernetes configuration store.)
As per claim 8, rejection of claim 6 is incorporated:
Mariappan teaches further comprising instructions that, upon execution, cause the one or more processors to: detect a delete Vnic event; invoke the finalizer module, including: determine the Vnic has been marked for deletion; read metadata for the Vnic to determine the application pod the Vnic is associated with; determine whether the application pod is in a terminated status; delete the Vnic when the application pod is in the terminated status; and requeue a delete event for the Vnic when the application pod is not in the terminated status. ([Paragraph 110], A network controller manager (e.g., network controller manager 325 of FIG. 3) listens to pod creation/deletion/update events for orchestrator 23. On detecting a new pod creation event, the network controller manager parses the pod information and creates corresponding interface configuration data for each virtual network interface to be configured for pod 202A. The network controller manager passes this interface configuration data to virtual router agent 216, optionally via network controller 24 having an interface with virtual router agent 216 to manage virtual routing in computing device 200. [Paragraph 146], Configuration store 328 is a backing store for all cluster data. Cluster data may include cluster state and configuration data. Configuration data may also provide a backend for service discovery and/or provide a locking service. Configuration store 328 may be implemented as a key value store. Configuration store 328 may be a central database or distributed database. Configuration store 328 may represent an etcd store. Configuration store 328 may represent a Kubernetes configuration store.)
As per claim 9, rejection of claim 6 is incorporated:
Mariappan teaches further comprising instructions that, upon execution, cause the one or more processors to: invoke the stale resource module, including: read metadata for the Vnic to determine the application pod the Vnic is associated with; determine whether the application pod is in a terminated status; delete the Vnic when the application pod is in the terminated status; and do nothing when the application pod is not in the terminated status. ([Paragraph 110], A network controller manager (e.g., network controller manager 325 of FIG. 3) listens to pod creation/deletion/update events for orchestrator 23. On detecting a new pod creation event, the network controller manager parses the pod information and creates corresponding interface configuration data for each virtual network interface to be configured for pod 202A. The network controller manager passes this interface configuration data to virtual router agent 216, optionally via network controller 24 having an interface with virtual router agent 216 to manage virtual routing in computing device 200. [Paragraph 146], Configuration store 328 is a backing store for all cluster data. Cluster data may include cluster state and configuration data. Configuration data may also provide a backend for service discovery and/or provide a locking service. Configuration store 328 may be implemented as a key value store. Configuration store 328 may be a central database or distributed database. Configuration store 328 may represent an etcd store. Configuration store 328 may represent a Kubernetes configuration store.)
As per claims 16-19, these are method claims corresponding to the system claims 6-9. Therefore, rejected based on similar rationale.
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 DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9:00am - 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at 5712723338. 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.
/DONG U KIM/Primary Examiner, Art Unit 2197
Prosecution Insights