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 .
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Raut (US pat. no. 10944691), further in view of Liu (US pg. no. 20210314190).
Regarding claim 1. Raut discloses a computing system (fig. 1110 computer system comprising container plugin) comprising:
processing circuitry having access to storage media, the processing circuitry configured to, based on an event for a native resource of a container orchestration system process the event for the native resource (col. 2, lines 18-55 computer system (container plugin) is configured to act as an interface between container orchestration system 101 and SDN manager 102. For example the plugin 110 may monitor events on container orchestration system 101 (based on events of native resource) and translate them into instructions to SDN manager 102 (processing events of native resource); ecol.8, lines 43-55 container-based resource (native resource) may be configured for cluster 120 via container orchestration (Kubernetes) that corresponds to event. In response container plugin 110 may cause SDN manager 103 to configure a network topology for the namespace. This may involve configuring tier-1 logical router, T1-LR1 (custom resource));
create, based on the native resource, an instance of a custom resource for software defined networking (SDN) architecture configuration (col. 3 , lines 39-60 container plugin 110 may detect events (create, read update and delete) associated with container-based resources (native resources) and translate the desired state into necessary configuration of logical network elements (custom resources) via SDN manager 101. In the example in FIG. 1, individual containers may be grouped as pods (native resources) and run in VMs. Container plugin 110 may interact with SDN manager 102 to configure various logical network elements connecting containers, such as logical routers, logical switches, logical ports; col. 8, lines 7-26 At 405 in FIG. 4, container plugin 110 may monitor events on container orchestration system 101, including configuration container-based resource (native resource). Using Kubernetes and an example, container plugin 110 may monitor and API server supported by container orchestration system 101 for any create, read, update, and remove events (native resource events)…At 410, 405, and 420 in FIG. 4, in response to detecting a request to configure a container-based resource, container plugin 110 may configure a logical network element (custom resource) by generating and sending instructions (configuration)to SDN manager 102);
obtain configuration data for the instance of the custom resource (col. 8, lines 7-26 At 405 in FIG. 4, container plugin 110 may monitor events on container orchestration system 101, including configuration container-based resource (native resource). Using Kubernetes as an example, container plugin 110 may monitor and API server supported by container orchestration system 101 for any create, read, update, and remove events (native resource events)…At 410, 405, and 420 in FIG. 4, in response to detecting a request to configure a container-based resource (native resource event), container plugin 110 may configure a logical network element by generating and sending instructions (configuration data)to SDN manager 102); and
But, Raut does not explicitly disclose: configure, based on the configuration data for the instance of the custom resource, a corresponding instance of a configuration object in an SDN architecture system.
However, in the same field of endeavor, Liu discloses configure, based on the configuration data for the instance of the custom resource, a corresponding instance of a configuration object in an SDN architecture system ([0104] Upon VNet creation event (detected event), NCP will realize the corresponding network resources (custom resources) and routing configuration (configuration data) based on the connectivity field in Virtual Network specification, and direct the SDN managers/controllers to deploy (configure) such a virtual network with the desired network elements (e.g., switches, routers, and/or gateways). As mentioned above by reference to FIG. 5, some embodiments support virtual network with different types of connectivity; [0065-0067] NCP 145 detects network events by processing the data supplied by its corresponding API server 140, and uses NSX-T APIs to direct the NSX-T manager 110 to deploy and/or modify NSX-T network constructs needed to implement the network state expressed by the API calls… [0066] After receiving the APIs from the NCPs 145, the SDN managers 110 in some embodiments direct the SDN controllers 115 to configure the network elements to implement the network state expressed by the API call…the SDN controllers 115 push the high-level configuration data to the local control plane (LCP) agents 220 on host computers 205, LCP agents 225 on edge appliances 210 and TOR (top-of-rack) agents 230 of TOR switches 215. [0067] Based on the received configuration data, the LCP agents 220 on the host computers 205 configure one or more software switches 250 and software routers 255 to implement distributed logical switches, routers, bridges and/or service nodes (e.g., service VMs or hypervisor service engines) of one or more logical networks with the corresponding switches and routers on other host computers 205, edge appliances 210, and TOR switches 215).
Therefore, it would have been obvious to a person having ordinary skill in the art at the time of the invention was effectively filed to combine the teaching of Raut with Liu. The modification would allow use of a known Kubernetes technique for its established purpose and would have predictably resulted permitting the desired network configuration generated from a native Kubernetes event to be represented declaratively as a Kubernetes resource and realized by SDN controller for configuring custom resources. The modification would allow configuring the scalable custom resources to be integrated with the native resources effectively.
Regarding claim 2 . The combination discloses computing system of claim 1.
Raut discloses, wherein the computing system comprises a network controller for the SDN architecture system (fig. 1 SDN manager 102).
Regarding claim 3. The combination discloses computing system of claim 1.
Raut discloses, wherein the event for the native resource of the container orchestration system comprises a create event of an instance of the native resource (col. 3 , lines 39-60 container plugin 110 may detect events (create, read update and delete) associated with container-based resources (native resources) and translate the desired state into necessary configuration of logical network elements (custom resources) via SDN manager 101. In the example in FIG. 1, individual containers may be grouped as pods (native resources) and run in VMs. Container plugin 110 may interact with SDN manager 102 to configure various logical network elements connecting containers, such as logical routers, logical switches, logical ports).
Regarding claim 4. The combination discloses computing system of claim 1.
Liu discloses, wherein the processing circuitry is configured to:
based on detecting an event on the instance of the custom resource, obtain additional configuration data for the instance of the custom resource and configure the corresponding instance of the configuration object in the SDN architecture system ([0104] Upon VNet creation event (detected event), NCP will realize the corresponding network resources (custom resources) and routing configuration based on the connectivity field in Virtual Network specification, and direct the SDN managers/controllers to deploy (configure) such a virtual network with the desired network elements (e.g., switches, routers, and/or gateways). As mentioned above by reference to FIG. 5, some embodiments support virtual network with different types of connectivity; [0065-0067] NCP 145 detects network events by processing the data supplied by its corresponding API server 140, and uses NSX-T APIs to direct the NSX-T manager 110 to deploy and/or modify NSX-T network constructs needed to implement the network state expressed by the API calls… [0066] After receiving the APIs from the NCPs 145, the SDN managers 110 in some embodiments direct the SDN controllers 115 to configure the network elements to implement the network state expressed by the API call…the SDN controllers 115 push the high-level configuration data to the local control plane (LCP) agents 220 on host computers 205, LCP agents 225 on edge appliances 210 and TOR (top-of-rack) agents 230 of TOR switches 215).
Regarding claim 5. The combination discloses computing system of claim 1, wherein:
Liu discloses the native resource is an application workload for deployment to a compute node of the SDN architecture system ([0008] Kubernetes-based container Pods),
the custom resource is a virtual network interface resource ([0115] As mentioned above, the network control system of some embodiments uses VIF CRDs to define and deploy VIFs(virtual network interface) for non-Kubernetes Pods and for VMs (non-native or custom resources; [0050] A VIF CRD(virtual network interface resource CRD) in some embodiments is used to define a virtual interface to connect a non-Kubernetes container Pod or VM (custom resources)to software forwarding elements), and
to configure the corresponding instance of the configuration object in the SDN architecture system, the processing circuitry is configured to configure, in a virtual router of the compute node, a virtual network interface with the configuration data for the instance of the custom resource ([0127] The NCP 145 in some embodiments performs the process 700 each time that 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).
Regarding claim 6. The combination discloses computing system of claim 5.
Liu discloses, wherein the virtual network interface enables communication by the application workload via a virtual network in the SDN architecture system ([0008] discloses for the non-Kubernetes Pods and for VMs, the method of some embodiments uses virtual network interfaces (VIF) (virtual network interface) 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; fig. 11 discloses VM 1105 and pod 1110 communicate to VN 1122 via VIF 1107, VIF 112 respectively).
Regarding claim 7 The combination discloses computing system of claim 1.
Raut discloses, wherein: the custom resource is a first custom resource, the configuration object in the SDN architecture system is a first configuration object in the SDN architecture system (col. 8, lines 7-26 At 405 in FIG. 4, container plugin 110 may monitor events on container orchestration system 101, including configuration container-based resource (native resource). Using Kubernetes as an example, container plugin 110 may monitor and API server supported by container orchestration system 101 for any create, read, update, and remove events (native resource events)…At 410, 405, and 420 in FIG. 4, in response to detecting a request to configure a container-based resource (native resource event), container plugin 110 may configure a logical network element (custom resource) by generating and sending instructions (configuration data)to SDN manager 102. Both the first native or custom resource configured corresponds to the first resource and the configuration data corresponds to the first configuration data), and
the processing circuitry is configured to, based on the event for the native resource of the container orchestration system ((col. 2, lines 18-55 computer system (container plugin) is configured to act as an interface between container orchestration system 101 and SDN manager 102. For example the plugin 110 may monitor events on container orchestration system 101 (based on events of native resource) and translate them into instructions to SDN manager 102 (processing events of native resource); ecol.8, lines 43-55 container-based resource (native resource) may be configured for cluster 120 via container orchestration (Kubernetes) that corresponds to event. In response container plugin 110 may cause SDN manager 103 to configure a network topology for the namespace. This may involve configuring tier-1 logical router, T1-LR1 (custom resource):
create, based on the native resource, an instance of a second custom resource for a SDN architecture configuration, wherein the first custom resource and the second custom resource correspond to different types of configuration objects in the SDN architecture system ((col. 3 , lines 39-60 container plugin 110 may detect events (create, read update and delete) associated with container-based resources (native resources) and translate the desired state into necessary configuration of logical network elements (custom resources) via SDN manager 101. In the example in FIG. 1, individual containers may be grouped as pods (native resources) and run in VMs. Container plugin 110 may interact with SDN manager 102 to configure various logical network elements connecting containers, such as logical routers, logical switches, logical ports; col. 8, lines 7-26 At 405 in FIG. 4, container plugin 110 may monitor events on container orchestration system 101, including configuration container-based resource (native resource). Using Kubernetes and an example, container plugin 110 may monitor and API server supported by container orchestration system 101 for any create, read, update, and remove events (native resource events)…At 410, 405, and 420 in FIG. 4, in response to detecting a request to configure a container-based resource, container plugin 110 may configure a logical network element (custom resource) by generating and sending instructions (configuration)to SDN manager 102);
obtain configuration data for the instance of the second custom resource (col. 8, lines 7-26 At 405 in FIG. 4, container plugin 110 may monitor events on container orchestration system 101, including configuration container-based resource (native resource). Using Kubernetes as an example, container plugin 110 may monitor and API server supported by container orchestration system 101 for any create, read, update, and remove events (native resource events)…At 410, 405, and 420 in FIG. 4, in response to detecting a request to configure a container-based resource (native resource event), container plugin 110 may configure a logical network element (custom resource) by generating and sending instructions (configuration data)to SDN manager 102); and
Liu discloses configure, based on the configuration data for the instance of the second custom resource, a corresponding instance of a second configuration object in the SDN architecture system ([0104] Upon VNet creation event (detected event), NCP will realize the corresponding network resources (custom resources) and routing configuration (configuration data) based on the connectivity field in Virtual Network specification, and direct the SDN managers/controllers to deploy (configure) such a virtual network with the desired network elements (e.g., switches, routers, and/or gateways). As mentioned above by reference to FIG. 5, some embodiments support virtual network with different types of connectivity; [0065-0067] NCP 145 detects network events by processing the data supplied by its corresponding API server 140, and uses NSX-T APIs to direct the NSX-T manager 110 to deploy and/or modify NSX-T network constructs needed to implement the network state expressed by the API calls… [0066] After receiving the APIs from the NCPs 145, the SDN managers 110 in some embodiments direct the SDN controllers 115 to configure the network elements to implement the network state expressed by the API call…the SDN controllers 115 push the high-level configuration data to the local control plane (LCP) agents 220 on host computers 205, LCP agents 225 on edge appliances 210 and TOR (top-of-rack) agents 230 of TOR switches 215. [0067] Based on the received configuration data, the LCP agents 220 on the host computers 205 configure one or more software switches 250 and software routers 255 to implement distributed logical switches, routers, bridges and/or service nodes (e.g., service VMs or hypervisor service engines) of one or more logical networks with the corresponding switches and routers on other host computers 205, edge appliances 210, and TOR switches 215).
Regarding claim 8. The combination discloses computing system of claim 1.
Liu discloses, wherein: the custom resource is virtual network resource, and to configure the corresponding instance of the configuration object in the SDN architecture system, the processing circuitry is configured to configure an instance of a virtual network in a compute node of the SDN architecture system ([0008] To deploy the network elements, the method of some embodiments uses one or more Custom Resource Definitions (CRDs) to define attributes of custom-specified network resources (custom resources) that are referred to by the received API requests. When these API requests are Kubernetes APIs, the CRDs define extensions to the Kubernetes networking requirements. In addition to the Kubernetes-based container Pods (native resources), the method of some embodiments deploys network elements to connect non-Kubernetes Pods and/or virtual machines (VMs) (custom resources). For the non-Kubernetes Pods and for VMs (virtual network resource), the method of some embodiments 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 that corresponds to configuring virtual network).
Regarding claim 9. The combination discloses computing system of claim 1,
Liu discloses wherein the processing circuitry is configured to: for each type of configuration object in the SDN architecture system, execute a different custom resource controller to implement a corresponding custom resource for SDN architecture configuration (fig. 1 discloses compute manager and controllers cluster that corresponds to different custom resource controllers; [0058] The API processing server 140 parses each received intent-based API request into one or more individual requests. When the requests relate to the deployment of machines, the API server provides these requests directly to compute managers and controllers 117. The compute managers and controllers 117 then deploy VMs and/or Pods on host computers in the availability zone).
Regarding claim 10 (New). The computing system of claim 1, wherein the processing circuitry is configured to:
Raut discloses set a watch on the native resource of the container orchestration system; and process the event for the native resource based on the watch (col. 7, lines 11-20 discloses container plugin 110 may detect a first request (see 181 in FIG. 1) to assign a container-based resource with a first label via container orchestration system 101. In the example in FIG. 1, container-based resource=master node 121 in cluster 120 may be associated with logical network element=logical switch port LP1 151. Depending on the desired implementation, the request at block 310 may be detected when master node 121 is created, or at a later time. In the former case, container plugin 110 may also configure logical network element=LP1 151 at block 320).
set a watch on the native resource of the container orchestration system; and process the event for the native resource based on the watch ([0111] discloses NCP 145 watches these virtual network events, and allocates NSX network resources for VIF objects, then reports status back regarding the VIF to the network control system. WCP is then notified about the networking realization result by a CRD status update).
Regarding claim 11. The combination discloses computing system of claim 1.
Liu discloses, wherein the computing system is a cluster comprising a compute node of the SDN architecture system (fig. 1 discloses SDN controller cluster 115; SDN manager cluster 110).
Regarding claim 12 The combination discloses method comprising:
All other limitations of claim 12 are similar with the limitations of claim 1 rejected above.
Regarding claim 13. The combination discloses method of claim 12.
All other limitations of claim 13 are similar with the limitations of claim 3 rejected above.
Regarding claim 14. The combination discloses method of claim 12.
All other limitations of claim 14 are similar with the limitations of claim 4 rejected above.
Regarding claim 15. The combination discloses method of claim 12.
All other limitations of claim 15 are similar with the limitations of claim 5 rejected above.
Regarding claim 16. The combination discloses method of claim 15.
All other limitations of claim 16 are similar with the limitations of claim 6 rejected above.
Regarding claim 17. The combination discloses method of claim 12.
All other limitations of claim 17 are rejected on the analysis of claim 7 rejected above.
Regarding claim 18. The combination discloses method of claim 12.
All other limitations of claim 8 are rejected on the analysis of claim 8 rejected above.
Regarding claim 19. The combination discloses method of claim 12.
All other limitations of claim 19 are similar with the limitations of claim 10 rejected above.
Regarding claim 20. The combination discloses Non-transitory computer-readable media comprising instructions that, when executed by processing circuitry, cause the processing circuitry to:
All other limitations of claim 20 are similar with the limitations of claim 1 rejected above
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MESSERET F. GEBRE whose telephone number is (571)272-8272. The examiner can normally be reached 9:00 am-5:30PM.
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, Oscar Louie can be reached at 5712701684. 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.
/MESSERET F GEBRE/Primary Examiner, Art Unit 2445
Prosecution Insights