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 .
Claims 1-20 are pending.
Claim Objections
Claims 9, 10, 19, and 20 are objected to as they contain a duplicate instance of “the”. Claims 10 and 20 inherit the duplicate instances in claims 9 and 19 respectfully.
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.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1-20, the claims are found to be indefinite as they contain the trademarked term: “Kubernetes” which limits the claimed cluster to be a Kubernetes cluster ([MPEP 2173.05(u)] If the 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 the 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. Ex parteSimpson, 218 USPQ 1020 (Bd. App. 1982)).
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.
Claims 1-5, 7, 9-11, 12-16, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Henkel et al. US 20230106531 A1 in view of Sridhar et al. US 20240078123 A1.
Regarding claim 1, Henkel teaches the invention substantially as claimed including:
A method for configuring a logical network in a Kubernetes cluster, the method comprising:
at a network management system external to the Kubernetes cluster (in at least Figs 1, 2; [0009] a network controller for creating and managing virtual networks; [0064] network controller 24 may implement respective cluster masters for one or more Kubernetes clusters)):
receiving a definition of a logical router for the logical network (in at least [0091] In the simplest form, VNRs 52 represent a logical abstraction of a router set in the context of Kubernetes; [0251] control nodes 232 may obtain custom resources defining VNRs 52), the logical router definition specifying a set of one or more layer services to be performed on data messages processed by the logical router ([0142] Such custom resources may be alternately termed and referred to herein as “custom resources for SDN architecture configuration.” These may include VNs, VNRs, bgp-as-a-service (BGPaaS), subnet, virtual router, service instance, project, physical interface, logical interface, node, network ipam, floating ip, alarm, alias ip, access control list, firewall policy, firewall rule, network policy, route target, routing instance); and
via a control plane of the Kubernetes cluster, defining (i) a first custom resource (CR) instance associated with a first custom resource definition (CRD) for implementing logical forwarding for the logical router (Control in Fig. 1, 2, 3; in at least [0091] where VNRs 52 may be defined as a custom resource to facilitate interconnectivity between VNs 50) and (ii) for each L7 service, a separate CR instance associated with a second CRD for implementing the L7 service (in at least [0117] configuration resources also include custom resources, which are used to extend the Kubernetes platform by defining an application program interface (API) that may not be available in a default installation of the Kubernetes platform. In the example of SDN architecture 200, custom resources may describe physical infrastructure, virtual infrastructure (e.g., VNs 50 and/or VNRs 52), configurations, and/or other resources of SDN architecture 200. As part of the configuration and operation SDN architecture 200, various custom resources may be instantiated (e.g., VNRs 52 within vRouter 21).
Henkel does not explicitly teach the logical router definition specifying a set of one or more layer 7 (L7) services to be performed on data messages processed by the logical router.
However, Sridhar teaches the logical router definition specifying a set of one or more layer 7 (L7) services (Fig. 2, 3; [0061] Network services of services 233 may include security services (e.g., firewall), policy enforcement, proxy, load balancing, or other L4-L7 services).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Sridhar’s L7 services with the existing system of Henkel. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of implementing sharing of common layer 7 services within the cluster environment of Henkel (see Sridhar [0002] A service mesh provides an infrastructure layer for modern distributed applications to exchange information between various microservices in a secure and observable way. For example, a simple e-commerce application can be divided into microservices, which may include a product-view service to show product information, a database service to maintain inventory of products, and a cart service to track products selected by a user. Other examples of distributed applications can have hundreds or even thousands of different microservices. The service mesh layer may control and manage inter-service communication. These microservices may interact with other services through a service proxy. These service proxies are configured and managed by service mesh controllers).
Regarding claim 2, Henkel and Sridhar teach the method of claim 1.
Henkel further teaches the logical router is a first logical router defined for the network; the logical router provides a connection between the logical network and external networks (at least [0010] Instances of the Virtual Network Router custom resource facilitate the exchange (referring to asymmetric or symmetric import and export) of routing information using import and export route targets that are configured within routing instances for respective virtual networks; [0317] FIGS. 13A and 13B are diagrams illustrating a fourth instance in which virtual network routers may be configured to enable mesh interconnectivity between virtual networks in accordance with various aspects of the techniques described in this disclosure. In the example of FIG. 13A, the general network structure is similar to that shown in the example of FIG. 12A except that VNs 1500A and 1500B, pods 1502A and 1502B, and VNR 1506A are in a first namespace 1504A (shown as “namespace-1”) while VNs 1500C and 1500D, pods 1502C and 1502D, and VNR 1506B are in a second, different namespace 1504B (shown as “namespace-2”)); and
in response to the definition of the first CR instance and the separate CR instances, the Kubernetes control plane instantiates (i) at least one Pod for the first CR instance to perform logical forwarding for data messages sent between the logical network and the external networks and (ii) at least one Pod for each separate CR instance to perform the associated L7 service (Fig 13 Pods; ([0043] Any server of servers 12 may be configured with virtual execution elements, such as pods or virtual machines, by virtualizing resources of the server to provide some measure of isolation among one or more processes (applications) executing on the server)).
Regarding claim 3, Henkel and Sridhar teach the method of claim 2.
Henkel further teaches configuring at least one interface on the Pod for the first CR instance to communicate with an external router, wherein a configuration of the interface is based on the definition of the logical router (Fig. 13-15 Intra VNR communications; [0092] That is, rather that resort to defining how routing is to occur between two or more VNs 50, the administrator may define one or more VNRs 52 to interconnect VNs 50 without having to manually develop and deploy extensive policies and/or routing instance configurations to enable the exchange of routing information between such VNs 50. Instead, the administrator (which may have little understanding of routing protocols) may define a custom resource (e.g., one or more of VNRs 52) using familiar Kubernetes syntax/semantics (or even just by dragging graphical elements and specifying interconnections between this graphical element representative of, as an example, VNR 52A, and graphical elements representative of, again as an example, VNs 50A and 50N)).
Regarding claim 4, Henkel and Sridhar teach the method of claim 2.
Henkel further teaches configuring connectivity between the Pod for the first CR instance and the Pods for each of the separate CR instances (Fig 12; [0315] All Pods of VNs connected to both VNR 1506A (“VNR-web”) and VNR 1506B (“VNR-db”) can, by causing VNR 1506A, 1506B to import/export each others' routes, in this way be enabled to communicate with each other using VNRs and labels; Fig 14/15; [0328] In this instance, VNs 1500A-1500C can only interconnect with a VNR 1516A and 1516B in the same namespace, and only spoke VNR 1516B and hub VNR 1516A can communicate across namespaces 1504A and 1504B for the reasons noted above. Assuming authorization is given by the administrators of both namespaces 1504A and 1504B, the hub-and-spoke connectivity shown at the bottom of FIG. 15 may be enabled in a similar if not substantially similar manner to that described above with respect to the example of FIG. 14).
Regarding claim 5, Henkel and Sridhar teach the method of claim 2.
Henkel further teaches the set of L7 services is a first set of L7 services, the method further comprising: receiving a definition of a second logical router for the logical network that specifies a second set of L7 services to be performed on data messages processed by the logical router; and defining additional separate CR instances associated with the second CRD for each L7 service specified for the second logical router (Fig 15 VNR spoke in namespace-1 routing Pod 1/VN1 and Pod 2/VN2 and VNR hub in namespace-2 routing Pod 3/VN3; Examiner notes: Kubernetes is able to spin up additional routers and associated pods for different services).
Regarding claim 7, Henkel and Sridhar teach the method of claim 5.
Henkel further teaches the first logical router is a first tier of logical router for interfacing with the external networks (Fig 15 VNR spoke interfaces with VNR hub) and the second logical router is a second tier of logical router for handling data traffic to a subset of logical network endpoints (Fig 15 VNR hub handles traffic for endpoints in VN3; [0173] Virtual routers may be processes or threads, or a component thereof, executed by the physical servers, e.g., servers 12 of FIG. 1, that dynamically create and manage one or more virtual networks usable for communication between virtual network endpoints. In one example, virtual routers implement each virtual network using an overlay network, which provides the capability to decouple an endpoint's virtual address from a physical address (e.g., IP address) of the server on which the endpoint is executing).
Regarding claim 9, Henkel and Sridhar teach the method of claim 1.
Henkel further teaches the network management system specifies to the control plane initial numbers of Pods for implementing the first CR instance and each of the separate CR instances ([0209] A service may be an abstraction that defines a logical set of pods and the policy used to access the pods. The set of pods implementing a service are selected based on the service definition. A service may be implemented in part as, or otherwise include, a load balancer. API server 300A and custom API server 301A may implement a Representational State Transfer (REST) interface to process REST operations and provide the frontend, as part of the configuration plane for an SDN architecture, to a corresponding cluster's shared state stored to configuration store 1328. API server 300A may represent a Kubernetes API server).
Regarding claim 10, Henkel and Sridhar teach the method of claim 9.
Henkel further teaches the network management system specifies a physical connectivity requirement for each of the Pods that implement the first CR instance indicating that said Pods are required to have physical connectivity to a set of one or more external routers outside of the cluster (Table 2; [0226] This metadata information may be copied to each pod replica created by the controller manager 1326. When the SDN controller manager 1325 is notified of these pods, SDN controller manager 1325 may create virtual networks as listed in the annotations (“red-network”, “blue-network”, and “default/extns-network” in the above example) and create, for each of the virtual networks, a virtual network interface per-pod replica (e.g., pod 202A) with a unique private virtual network address from a cluster-wide address block (e.g. 10.0/16) for the virtual network).
Regarding claim 11, Henkel and Sridhar teach the method of claim 1.
Henkel further teaches defining an orchestrator for monitoring Pods that implement the first CR instance and the separate CR instances ([0064] orchestrator 23 controls the deployment, scaling, and operations of containers across clusters of servers 12 and providing computing infrastructure, which may include container-centric computing infrastructure. Orchestrator 23 and, in some cases, network controller 24 may implement respective cluster masters for one or more Kubernetes clusters; [0068] The orchestrator 23 and container platform 19 use CNI 17 to manage networking for pods, including pod 22; [0193] Orchestration agent 592 is an agent of an orchestrator, e.g., orchestrator 23 of FIG. 1, that receives container specification data for containers and ensures the containers execute by computing device 500. Container specification data may be in the form of a manifest file sent to orchestration agent 592 from orchestrator 23 or indirectly received via a command line interface, HTTP endpoint, or HTTP server. Container specification data may be a pod specification (e.g., a PodSpec—a YAML (Yet Another Markup Language) or JSON object that describes a pod) for one of pods 502 of containers. Based on the container specification data, orchestration agent 592 directs container engine 590 to obtain and instantiate the container images for containers 529, for execution of containers 529 by computing device 500).
Regarding claim 12, it is the non-transitory machine-readable medium of claim 1. Therefore, it is rejected for the same reasons as claim 1.
Regarding claims 13-16, they are the non-transitory machine-readable media of claims 2-5respectively. Therefore, they are rejected for the same reasons as claims 2-5 respectively.
Regarding claims 19 and 20, they are the non-transitory machine-readable media of claims 9 and 10 respectively. Therefore, they are rejected for the same reasons as claims 9 and 10 respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to HARRISON LI whose telephone number is (703) 756-1469. The
examiner can normally be reached Monday-Friday 9:00am-5:30pm 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, Aimee Li can be reached on (571) 272-4169. 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.
/H.L./
Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights