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 action is responsive to the communication filed 8/23/2023.
Claims 1-20 are presented for examination.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirely as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d) or (f).
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 3/19/2025. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 102
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 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102 (a) (1) as being anticipated by Zhou et al. (US 20210314388 A1, hereafter Zhou).
Regarding to claim 1, Zhou discloses: A method for assigning containerized workloads to isolated network constructs within a networking environment associated with a container-based cluster (see [0021], [0054]-[0056], [0112] and [0190]-[0191]; “The network control system receives intent-based API (Application Programming Interface) requests, and parses these API requests (API calls) to identify network elements to deploy for the set of machines … automated processes to define a virtual private cloud (VPC) to connect the set of machines to a logical network that segregates these machines from other machines in the datacenter set. In some embodiments, the set of machines include virtual machines (VMs) and container Pods” and “The workloads (e.g., VMs, Pods, etc.) being placed on the deployed virtual network, map to the ports on the segments”), comprising:
receiving, at the container-based cluster, a subnet port custom resource specification to initiate creation of a subnet port object to assign a node to a subnet within the networking environment, wherein one or more containerized workloads are running on the node (see [0054]-[0056], [0059]; “The network control system receives intent-based API (Application Programming Interface) requests, and parses these API requests (API calls) to identify network elements to deploy for the set of machines. In some embodiments, the API is a hierarchical document that can specify multiple different compute and/or network elements at different levels of compute and/or network element hierarchy … to connect the set of machines to a logical network that segregates these machines from other machines in the datacenter set. In some embodiments, the set of machines include virtual machines (VMs) and container Pods”. Also see [0191], [0195]-[0206]; “the service-creating API 1506 specifies the name and port attributes of the service”, “detects a create VSO event (e.g., when it is notified by API server 140 that it has received an API to create a VSO). A VSO in some embodiments maps a set of one or more L4 ports (e.g., a port range) and/or a protocol to an endpoint group of machines for providing the service”. The received API specifies port information, i.e., claimed subnet port custom resource specification, to create a subnet port object to assign or connect set of containers or VMs to be created to a subnet);
in response to receiving the subnet port custom resource specification, creating the subnet port object; and modifying a state of the container-based cluster to match a first intended state of the container-based cluster at least specified in the subnet port object, wherein modifying the state comprises assigning the node to the subnet in the networking environment (see [0112], [0153] and the explanation of the receiving limitation above; “The workloads (e.g., VMs, Pods, etc.) being placed on the deployed virtual network, map to the ports on the segments. Each segment is allocated with a subnet from the private IP block”, “For each VIF specified by an API, NCP will create a Port with allocated IP address and an allocated MAC address”. The system creates a set of containers or VMs and then adds or joins the set of containers or VMs to a logical network or subnet of VPC via specified port. It is understood that in order to achieve such feature, the specified port is required to be created and then assigning or joining such created set of containers or VMs to the subnet via the created specified port. Also see “configure hooks in the VIF-associated ports 810 … where the port hooks are configured to direct ingress/egress data message flows from/to a VIF-associated machine 830 to a firewall engine 915 on the same host computer 850 that performs firewall operations on these flows” from [0149] and “a port to use to access the service or compute provided by the endpoint machine associated with the VIF” from [0183]. These descriptions provide evidences of ports are functioning on certain specific subnets, and thus such subnet ports are required to be created. Also see [0063], [0072]-[0073]; “processes APIs that use the Kubernetes-based declarative model to describe the desired state of (1) the machines to deploy, and (2) the connectivity, security and service operations that are to be performed for the deployed machines (e.g., private and public IP addresses connectivity, load balancing, security policies, etc.)”, “deploy and/or modify NSX-T network constructs needed to implement the network state expressed by the API calls” and “configure the network elements to implement the network state expressed by the API calls”).
Regarding to Claim 2, the rejection of Claim 1 is incorporated and further Zhou discloses: one or more internet protocol (IP) addresses in an IP classless inter-domain routing (CIDR) block are assigned to the subnet (see [0013] and [0081]; “allocates (at 305) an IP subnet for the VPC. In some embodiments, the VPC is part of a supervisor cluster that is a single routing domain with a corresponding IP CIDR (Classless Inter-Domain Routing) that specifies a range of IP addresses internal to the availability zone”), and
assigning the node to the subnet comprises assigning an IP address of the one or more IP addresses assigned to the subnet to the node (see [0013]; “VIF CRDs to define and deploy VIFs for non-Kubernetes Pods and for VMs. The VPC in some embodiments operates within a single routing domain that has an associated IP CIDR (Classless Inter-Domain Routing). For a VIF that belongs to a network segment, the method in some embodiments automatically allocates an IP address from an IP subnet of the VPC IP CIDR that is automatically allocated for the segment … it automatically allocates a new IP subnet from the VPC IP CIDR and automatically allocates an IP address from the newly allocated IP subnet”. Also see [0133] for similar description).
Regarding to Claim 3, the rejection of Claim 1 is incorporated and further Zhou discloses: wherein the node comprises a pod virtual machine (VM) provisioned from a pod VM object in the container-based cluster (see [0069] and [0112]; “the API server 140 is a Kubernetes master VM, and the NCP 145 runs in this VM as a Pod” and “The workloads (e.g., VMs, Pods, etc.) being placed on the deployed virtual network, map to the ports on the segments”), wherein the pod VM object comprises a custom resource introduced in the container-based cluster to extend an API of the container-based cluster (also see [0056], [0067], [0071] and [0123], “the API calls refer to extended resources that are not defined per se by Kubernetes. For these references, the API processing server 140 uses one or more CRDs 120 to interpret the references in the API calls to the extended resources”, “The API server provides the CRDs that have been defined for these extended network constructs to the NCP for it to process the APIs that refer to the corresponding network constructs” and “create and specify N virtual interface in the VM CRD specification. The VIF CRD defines the virtual interface, which in some embodiments will be realized as an NSX-T logical port connected to the VPC segment”).
Regarding to Claim 4, the rejection of Claim 1 is incorporated and further Zhou discloses: wherein the node comprises a VM provisioned from a VM object in the container-based cluster, wherein the VM object comprises a custom resource introduced in the container-based cluster to extend an API of the container-based cluster (see [0134]; “it detects a new VIF creation event. For instance, the NCP would detect such an event each time the API server 140 receives an API that requires a new VIF to be created. Such an API in some embodiments refers to a VIF CRD. As mentioned above, some embodiments define a new VIF to connect a VM or non-Kubernetes Pod to the logical network of a VPC. Hence, in these embodiments, the VIF creation is accompanied by the configuration of a VM that is being deployed on a host computer to join a logical network”. Also see [0056], [0067], [0071] and [0123], “the API calls refer to extended resources that are not defined per se by Kubernetes. For these references, the API processing server 140 uses one or more CRDs 120 to interpret the references in the API calls to the extended resources”, “The API server provides the CRDs that have been defined for these extended network constructs to the NCP for it to process the APIs that refer to the corresponding network constructs” and “create and specify N virtual interface in the VM CRD specification. The VIF CRD defines the virtual interface, which in some embodiments will be realized as an NSX-T logical port connected to the VPC segment”).
Regarding to Claim 5, the rejection of Claim 4 is incorporated and further Zhou discloses: receiving a VM custom resource specification specifying parameters for creating the VM object, wherein the parameters at least reference a network interface object that defines a network attachment for the VM object (see [0070], [0122]-[0123]; “the control system 100 deploys Pods using Kubernetes Pod manifest, and VMs using a VM CRDs … For a VM, the administrator in some embodiments can create and specify N virtual interface in the VM CRD specification”);
receiving a network interface custom resource specification specifying parameters for creating the network interface object referenced by the VM custom resource specification, wherein the network interface object defines the network attachment for the VM as the subnet (see [0008], [0056]-[0057]; “uses virtual network interfaces (VIF) CRDs to specify virtual interfaces for connecting the non-Kubernetes Pods and the VMs to software forwarding elements (e.g., software switches) executing on host computers on which the non-Kubernetes Pods and VMs execute”. Also see [0070], [0077] and [0123]; “NCP 145 processes the parsed API requests relating to VIFs, virtual networks, load balancers, endpoint groups, security policies, and VSOs, to direct the SDN manager cluster 110 to implement (1) the VIFs needed to connect VMs and Pods to forwarding elements on host computers”); and
modifying the state of the container-based cluster to match a second intended state of the container-based cluster at least specified in the VM object and the network interface object, wherein modifying the state comprises provisioning the VM in the container-based cluster with the network attachment (see [0070], [0118]-[0119], [0123]; “NCP 145 processes the parsed API requests relating to VIFs, virtual networks, load balancers, endpoint groups, security policies, and VSOs, to direct the SDN manager cluster 110 to implement (1) the VIFs needed to connect VMs and Pods to forwarding elements on host computers”, “creates VIF object for each master VM. For guest cluster creation, WCP in some embodiments creates VNet per cluster and creates VIF object per node VM … the master VM in supervisor cluster uses VIFs to attach to NSX network … nodes in guest cluster use VIF CRD to create a network resource that attaches to the virtual network”. Also see [0063], [0072]-[0073]; “processes APIs that use the Kubernetes-based declarative model to describe the desired state of (1) the machines to deploy, and (2) the connectivity, security and service operations that are to be performed for the deployed machines (e.g., private and public IP addresses connectivity, load balancing, security policies, etc.)”, “deploy and/or modify NSX-T network constructs needed to implement the network state expressed by the API calls” and “configure the network elements to implement the network state expressed by the API calls”).
Regarding to Claim 6, the rejection of Claim 5 is incorporated and further Zhou discloses: creating the subnet port object comprises generating the subnet port object based on the subnet port custom resource specification and the network interface object (see [0017], [0137]; “hooks defined in the ports connecting to the interfaces (e.g., VIFs) of VMs and container Pods”, “associates the VIF with the port of a software switch (i.e., creates a logical connection between the VIF and the port) executing on a host computer on which the VIF's associated VM execute”. Also see [0153] and [0182]; “For each VIF specified by an API, NCP will create a Port with allocated IP address and an allocated MAC address” and “each endpoint machine is associated with a VIF or Pod interface, and is either specified by an IP address and a port value when the VIF is associated with a VM or a non-Kubernetes Pod”).
Regarding to Claim 7, the rejection of Claim 5 is incorporated and further Zhou discloses: wherein the parameters for creating the network interface object comprise the network attachment for the VM and at least one of: virtual network interface card (VNIC) parameters, guest network settings, or IP address management (IPAM) configuration (see [0123]-[0133]; “For a VM, the administrator in some embodiments can create and specify N virtual interface in the VM CRD specification. The VIF CRD defines the virtual interface, which in some embodiments will be realized as an NSX-T logical port connected to the VPC segment. NSX-T in some embodiments also realizes a VNIC for the VM”. Each parameters described by [0125]-[0132] can be considered as either one of claimed VNIC parameter or guest network settings).
Regarding to Claim 8, the rejection of Claim 1 is incorporated and further Zhou discloses: the networking environment is divided into one or more first level isolation constructs (see [0002] and [0094]; “deploying network elements for a set of machines in a set of one or more software defined datacenters (SDDCs). The datacenter set is part of one availability zone in some embodiments” and “the gateway from outside of the availability zone”. The networking environment is divided into different availability zones, i.e., claimed one or more first level isolation constructs, (or at least one availability zone and one non-availability zone, i.e., outside of the availability zone) having different datacenter sets),
each of the one or more first level isolation constructs is divided into one or more second level isolation constructs (see [0002]; “deploying network elements for a set of machines in a set of one or more software defined datacenters (SDDCs). The datacenter set is part of one availability zone in some embodiments” and “the gateway from outside of the availability zone”. Each of the availability zone comprised of a set of datacenters, and thus it is dividing the availability zone into different datacenters, i.e., claimed one or more second level isolation constructs),
each of the one or more second level isolation constructs is divided into one or more virtual private clouds (see [0076]; “FIG. 2 illustrates an example of a logical network 295 that define a VPC for one entity, such as one corporation in a multi-tenant public datacenter, or one department of one corporation in a private datacenter”. The datacenter associated with set of datacenter is divided into VPCs of corporations or VPCs of departments of corporation),
each of the one or more virtual private clouds is divided into one or more subnets, and the subnet belongs to a virtual private cloud of the one or more subnets (see Fig. 5 and [0099]; “The last virtual network is the private type virtual network 510. It includes one or more segments of the logical network that are isolated inside the VPC and connected to their own gateway router 530. Each of the sub-networks 502-510 in FIG. 5 can have more than one segment because when all of the IP addresses in an IP range allocated to the existing segment(s) in the sub-network are used”. Each VPC is divided into different subnets).
Regarding to Claim 9, Claim 9 is a system claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above (note: Also see [0249]-[0251]; “Computer system 3100 includes a bus 3105, processing unit(s) 3110, a system memory 3125, a read-only memory 3130” and “From these various memory units, the processing unit(s) 3110 retrieve instructions to execute and data to process in order to execute the processes of the invention” for claimed limitation of “one or more processors; and at least one memory, the one or more processors and the at least one memory configured to”).
Regarding to Claim 10, the rejection of Claim 9 is incorporated and further Claim 10 is a system claim corresponds to method Claim 2 and is rejected for the same reason set forth in the rejection of Claim 2 above.
Regarding to Claim 11, the rejection of Claim 9 is incorporated and further Claim 11 is a system claim corresponds to method Claim 3 and is rejected for the same reason set forth in the rejection of Claim 3 above.
Regarding to Claim 12, the rejection of Claim 9 is incorporated and further Claim 12 is a system claim corresponds to method Claim 4 and is rejected for the same reason set forth in the rejection of Claim 4 above.
Regarding to Claim 13, the rejection of Claim 12 is incorporated and further Claim 13 is a system claim corresponds to method Claim 5 and is rejected for the same reason set forth in the rejection of Claim 5 above.
Regarding to Claim 14, the rejection of Claim 13 is incorporated and further Claim 14 is a system claim corresponds to method Claim 6 and is rejected for the same reason set forth in the rejection of Claim 6 above.
Regarding to Claim 15, the rejection of Claim 13 is incorporated and further Claim 15 is a system claim corresponds to method Claim 7 and is rejected for the same reason set forth in the rejection of Claim 7 above.
Regarding to Claim 16, the rejection of Claim 9 is incorporated and further Claim 16 is a system claim corresponds to method Claim 8 and is rejected for the same reason set forth in the rejection of Claim 8 above.
Regarding to Claim 17, Claim 17 is a product claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above (note: Also see [0247] and [0249]; “Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions” and “This computer system includes various types of non-transitory machine readable media and interfaces for various other types of machine readable media” for claimed limitations of “a non-transitory computer-readable medium … cause the computing system to perform operations”).
Regarding to Claim 18, the rejection of Claim 17 is incorporated and further Claim 18 is a product claim corresponds to method Claim 2 and is rejected for the same reason set forth in the rejection of Claim 2 above.
Regarding to Claim 19, the rejection of Claim 17 is incorporated and further Claim 19 is a product claim corresponds to method Claim 3 and is rejected for the same reason set forth in the rejection of Claim 3 above.
Regarding to Claim 20, the rejection of Claim 17 is incorporated and further Claim 20 is a product claim corresponds to method Claim 4 and is rejected for the same reason set forth in the rejection of Claim 4 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lochhead et al. (US 20200396181 A1) discloses: configuration data is received from the client device. The configuration data is for one or more virtual networks to be accessed by a first computing device mounted in the first rack. In one example, the configuration data includes a specification of the devices and ports that a customer desires to connect to each of the virtual networks (see [0095]).
Brar et al. (US 20230370371 A1) discloses: the above input can be received by the control plane, where the customer specifies the parameters of each storm control configuration type using its own customer presentation (e.g., by using its own nomenclature of the ports of the vswitch). The control plane generates storm control information based on the actual network implementation (e.g., the L2 distributed switch) and the L2 VLAN configuration 1322 (e.g., the customer definition of ports) (see [0239]).
Rosoff et al. (US 20210311764 A1) discloses: each pod VM 130 maintains its own transmission control protocol/internes protocol (TCP/IP) stack managed by kernel 210. Each pod VM 130 includes a virtual NIC coupled to a logical port on virtual switch 616 managed by hypervisor 150 (see [0063]).
Miryiyala et al. (US 20230107891 A1) discloses: IPAM specified by configuration schema of custom resources (see [0157]).
Shen et al. (US 20220038501 A1) discloses: CNI is responsible for performing IP address management (IPAM) operations and allocating secondary IP addresses from virtual private cloud (VPC) subnets and the CNI implements its own policy specification using CRDs (see [0044]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 571-270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196