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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted, IDS - 08/11/2025 and 06/16/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Amendment
The amendment filed 06/15/2026 has been entered. Claims 1-20 remain pending
in the application. Claims 1, 8-10, 13, and 17 were amended.
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.
(a)(2) the claimed invention was described in a patent issued under section 151,
or in an application for patent published or deemed published under section
122(b), in which the patent or application, as the case may be, names another
inventor and was effectively filed before the effective filing date of the claimed
invention.
Claims 1-16 are rejected under 35 U.S.C. 102(a)(1) as being
anticipated by Miriyala et al. (US-20240129161-A1 includes by reference “CONTAINERIZED ROUTER WITH VIRTUAL NETWORKING” US Application 17/649,632, PGPUB US20220279420A) hereinafter “Miriyala”.
Regarding Claim 1,
Miriyala discloses, ‘A data processing unit (DPU) comprising: memory to store a configuration file specifying a plurality of virtual bridges and interface mappings for the plurality of virtual bridges’ (A computing device in Fig. 5 and Fig. 13 includes virtual routers and processing circuitry to implement configuration [0121]. Network controller generate virtual networks and configure network virtual endpoints. And, configuration of the virtual router e.g., as OVS/Linux/Docker bridge includes virtual network interfaces [0058, 0201-0203, 0210] and in Fig. 4; Disclosure includes the configuration procedures of one or more virtual routers in Fig. 1 and [0160, 0171] and the processing circuitry [0410, 0421]. The controller to connect to a first and a second virtual network [0406]; Configuration [0087, 0372-0373, 0398-0399].)
And discloses, ‘and a processing device operatively coupled to the memory, wherein the processing device, according to the configuration file, is to:
generate a first virtual bridge and a second virtual bridge of the plurality of virtual bridges, the first virtual bridge to be controlled by a first network service hosted on the DPU and having a first set of one or more network rule, and the second virtual bridge to be controlled by a user-defined logic and having a second set of one or more user-defined network rules;’ (Regarding the generates plurality of virtual bridges,
Disclosure, generates to create virtual networks [0210] in Fig. 1. Virtual routers may be processes or threads, or a component thereof, executed by the physical servers, e.g., servers of FIG. 1 , that dynamically create and manage one or more virtual networks usable for communication between virtual network endpoints [0200]. Each virtual network may use its own addressing and security scheme.
PNG
media_image1.png
536
426
media_image1.png
Greyscale
Techniques used to transport packets within and across VNs [0201]. The virtual router/bridge functionality of the Linux bridge/OVS module used for the pods to perform bridging/routing [0202] and to host-application/service/VM [0203], network services [0204] and in Fig. 1 to Fig. 2.
Fig. 3 illustrates a single cluster can includes NW controller, user interface and compute server and telemetry features [0152]. Orchestrator and NW controller execute separate alternatively on the same computing devices [0067].
PNG
media_image2.png
532
718
media_image2.png
Greyscale
NW controller includes processing circuitry to implement configuration node and a control node in Fig. 3. Configured to interconnect a first virtual NW and a second virtual NW. Configured to define a logical abstraction of one/more policies to perform interconnection via one/more VNRs [0121]. VNRs represent VN policy [112].
SDN controller create NW solution for the application uses aggregated API to define virtual NW, virtual interfaces and access control policies. NW controller implement the solution configure one/more virtual NW and virtual NW interfaces in the virtual routers [0252].
Container-based OS virtualization to run multiple systems on a single machine. Provides an application-suite and application specific libs executed by the host machine as user-space instance and share OS and common libs of multiple containers executed on the host machine [0052]. Docker based container app provide app/app-based lib. Multiple Linux system/container uses single OS/Linux kernel [0053]. Compute server in Fig. 1 represent compute device provide NFVI and NFV architecture [0045]. Each of servers host one/more virtual execution elements each having at least one virtual network endpoint for one/more virtual networks. Server/Compute A virtual network endpoint may be a set of one/more containers (e.g., pods). In Fig. 1 server [0055]. Any server of server 12 implement Linux bridge emulates h/w bridge forward packets among virtual network interfaces. For docker implementation of containers hosted by OVS/Linux/docker bridge [0058]. Any NIC 13 include an internal device switch to switch between virtual h/w component associated with the NIC. For example, an SR-IOV-capable NIC, the internal device switch may be a Virtual Ethernet Bridge (VEB) to switch between the SR-IOV VFs [0059]. Encapsulate/de-capsulated packet [0061]. VRs kernel-based and a DPDK-enabled VR run as a user-space app link to the DPDK lib and VNFs [0062-0063].
Automation platform of computing infrastructure includes at least servers, orchestrator and NW controller. Container virtualized uses cluster-based framework includes management of cluster and container hosting devices of a cluster. Kubernetes platform [0066].
Pod 22 in Fig. 1 and Fig. 4 is Kubernetes pod and an example of a virtual NW endpoint. Container Pod is a group of one/more logically-related container shared storage container. Containers of a pod are always co-located on a single server, co-scheduled, and run in a shared context. The shared context of a pod may be a set of Linux namespaces, cgroups [0070].
NW controller operate in response to configuration input received from orchestrator and/or administrator/operator [0068]. Server 12 includes container platform to run containerized-app as pods receives request from orchestrator to obtain and host container in server [0072]. Container NW interface (CNI) configures virtual network interfaces for virtual network endpoints. Orchestrator and container platform use CNI to manage NW for pods [0073].
SDN architecture configuration horizontally scalable implemented computed nodes [0142].
Pods and VMs deployed to compute nodes by VMs/container orchestrator in SDN architecture fig. 2 [0150]. Resources share single physical resources h/w execution NW elements as VMs and containers. Perform individual function can be interconnected can be allowed by security policies L2 VPN [0242].
And, configuration includes a first virtual network and a second virtual network; configuration define-policies [0121]; Customer provided options include features to satisfy the customer requirements/needs [0035, 0137].);
Kubernetes and other container management platform between pods, pods to service, nodes to pods. When establishing the default pod network, network controller 24 (along possibly with orchestrator 23), configure a primary interface for each of the pods. This primary interface supports the Kubernetes-defined networking constructs and advanced networking features like virtual networking, BGPaaS, networking policies [0092].
NW controller define custom resource for primary interface. Different NW topologies used to connect different VNs based on defined policies [0100]. To interconnect multiple VNs, NW controller configure and/or VRs defined policies. VNRs referred as virtual NW policy VNP [0112]. 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 [0237]. Scheduler monitors for newly created/requested virtual execution elements (e.g., pods of containers) and select minion node on which virtual execution elements runs. Select based on resource, h/w, s/w, policy requirement/constraints represents Kubernetes scheduler [0239].
NW controller maintain configurations representative of VNs that represent policies and configuration provides interconnectivity between VNs; and/or VRs also VNRs illustrated Fig. 1 [0113]. A user/admin interact UI of NW controller to define VNs representative of different pods 22 associated to pods with VNs enable communication among one/more pods associate to that VN [0114].
Administrator such as a Kubernetes administrator uses UI/user interface to define VNRs include pods, VNs [0160]. Configuration nodes includes component microservices/Kubernetes-API controller, custom-resource controller within the configuration in Fig. 3. Various components microservice for configuration node and NW controller includes telemetry and UI DPDK-based VRs connect DPDK-pods [0128]. Intent-driven configuration of SDN to push intents to configuration includes VM, container, Kubernetes, UI, one/more applications [0141] and Fig. 4 and Fig. 5.
PNG
media_image3.png
638
510
media_image3.png
Greyscale
PNG
media_image4.png
476
567
media_image4.png
Greyscale
To users Kubernetes API extended. Custom resource definition allow users to create new resources referred as custom-resources [0166] and available to clients [0167]. Kubernetes-api-server receives the Kubernetes configuration objects native objects (pods/services) and custom resources [0168]. Includes ACLs, firewall policy/rules, NW policy [0169]. And, unified intent model includes custom resources consolidated Kubernetes native/built-in resources, a Kubernetes administrator (or other Kubernetes user) may define custom primary interfaces, VNs, and VNRs (such as VNRs 52) using common Kubernetes semantics to policies. This technique promote a more unified user experience that less misconfiguration improve execution in SDN architecture [0170]. Multiple custom API servers/custom resource controllers to support different kinds of custom resources [0171]. Custom resource controller apply business logic to reach user’s intend provided user intent configuration [0172]. Custom resource controller include a logic execute and monitor resources. Determine that matches can perform action to adjust the current resource [0172].
SDN control manager is a collection of one/more Kubernetes custom controllers in single/multi-cluster deployment run on Kubernetes clusters manages objects of the resources perform CRUD operation uses service, namespace, pod, network policy, NW attachment definition [0179-190].
SDN architecture based deliver high performance firewall filter rule at scale exhibit consistent forwarding performance. Customer (e.g., Telcos, financial) required compliance apply encryption. Features of SDN architectures need to satisfy the requirements of customer [0137]. Each compute node 12 includes VR-agent and forwarding component vRouter in Fig. 3. These are component microservices. Converts configuration to forwarding for vRouter, VR-agent perform firewall rule processing, setup flows and interface with orchestration plugins (CNI Kubernetes) [0155].
Telemetry nodes provides metrics, alarms, logging and flow analysis of SDN architectures telemetry [0156] implement functionalities/configuration and auto scale operators/Kubernetes operators [0158] . In Fig. 4 SDN architecture extends and used Kubernetes API server for NW configuration objects that realizes user intents for NW configurations. Kubernetes referred as custom resources and as configuration objects are mainly user intents (VNs, VNRs, BGPaaS, NW policy etc) [0161].
The type of configuration object firewall rule to the first custom resource. In an event obtain configuration data for the firewall rule instance (e.g., the firewall rule specification) and provision the firewall rule in a virtual router for node 12. Includes ACL, firewall policy/rule, NW policy [0192].
In Fig. 5 computing device, computing node/host [0193]. OVS Linux/docker bridge on a host and perform bridging route packets among virtual NW endpoints of one/more virtual NW where the virtual NW endpoints are hosted by one/more server 12 [0201] used for Kubernetes deployments of pods perform bridging (e.g., E-VPN) and routing (e.g., L3VPN), perform NW services as applying security policies [0202]. In Fig. 5 includes forwarding instances (VRFs), overlay tunnel and flow table. L3/L2 packets; encapsulation/de-capsulation [0211].
Configured with one/more forwarding rules to route packets in Fig. 1 and Fig. 5 [0216]. Also, integration pod-to-service-network [0342] and in Fig. 13. Disclosure include customer-controller to provide user specific configuration apply business logic to customize resource-control [0172] and in Fig. 3 and Fig. 8; the configuration integrate users intent apply customizable resource definitions in a unified-intent-model [0161, 0169]. Configuration input from orchestrator, administrator, operator, user [0068, 0082].)
VNRs referred as Virtual Network Policy (VNP) or Virtual Network Topology [0112]. Configuration objects are mainly user intents (e.g., Virtual Networks—such as VNs 50 , VNRs 52 , Network Policy, etc.). the SDN architecture may support application-based security. These security policies can be based upon metatags to apply granular security policy in an extensible manner. Virtual networks are connected by policy. Kubernetes network policy operates at the Kubernetes namespace boundary [0125]. VNRs represent a logical abstraction of policies used to configure import and export of routing information between VNs 50 , whereby VNRs 52 referred to asymmetric or symmetric import and export) of routing information using a common route target established for each of VNRs [0159]. Miriyala includes PGPUB US20220279420A1 regarding the VNR referred as virtual NW policy [0158]. For better network packet I/O performance packet-send/receive, DPDK framework [0308]. K's cluster is performed using YAML includes in container [0330]. DPDK vRouter forwarding performance. DPDK configuration for applications and programming vRouter features include routing, NW namespace, ACL NW policies for security, tunnels and integration with DPDK vRouter 206A for higher forwarding performance , encapsulation , packet filter ing and QoS [0309-0319]. Delivery as set of containers that can deployed in K8s using an YAML spec [0320].
And discloses, ‘add one or more host interfaces to the second virtual bridge’ (creates virtual network interfaces to connects pods to virtual router. Container network interface configures virtual NW interface for virtual NW endpoints [0073]. Pod includes one/more containers/containerized DPDK [0077]. Virtual NW use address and security scheme. Techniques used to transport packets across virtual NW. Virtual router includes Linux/OVS/Docker bridge on a host device and performs switching, bridging, or routing packets among virtual network endpoints of one or more virtual networks where the virtual network endpoints are hosted by one or more of servers, that is compute device in Fig. 5. Virtual routers executes within user space as a DPDK-based virtual router, but virtual router 506 may execute within a hypervisor, a host operating system, a host application. Perform networking services such as applying security policies, NAT, multicast, mirroring, and load balancing [0201-0202]. Fig. 10 illustrates NW controller configures namespaces for set of pods associated to respective VM and interfaces. Connect pod-network-to-service network-to-service(one/more) [0330-0333]. And, pod-to-service in Fig. 13 and [0342-0351] and Fig. 1, );
And discloses, ‘add a first service interface to the first virtual bridge to operatively couple to the first network service’ (virtual network interface between Pod-virtual router and the service e.g. application/VM/host provided from the Pod. And virtual network interface also used as VM/container/Pod interface. And additional VNI can be configured [0081-0083].
PNG
media_image5.png
480
626
media_image5.png
Greyscale
The network service includes customizable services /computing resources networking/security services in the Pods/Kubernetes-pod [0147]. in addition, based on a network utilization view add network-aware scheduling plug-in to perform services load-balancing [0365-0370]. Disclosure include service annotation [0254, 0340] and Fig. 12. );
And discloses, ‘and add one or more virtual ports between the first virtual bridge and the second virtual bridge’ (In Fig. 3 illustrates a single cluster includes NW controller, user interface, compute servers and telemetry. Disclosure includes configuration of pod associated components in Fig. 1 virtual network interface. And, virtual network interface denotes veth-pair where each end of the pair is a Linux (i.e. OVS/docker bridge [0058]), one end of the pair assigned to pod and one end of the pair assigned to virtual router. The veth pair/an end of a veth pair are sometimes referred to as “ports” [0081]. Virtual network interfaces referred to as virtual machine interfaces (VMIs), pod interfaces, container network interfaces, veth interfaces, simply network interfaces [0081].
And, to connect between the pod-virtual router and port-addition [0080-0081, 0181]; addition of virtual routers and virtual port [0210, 0219]; any flow are associated to tuples includes port [0044] and vLAN-tag/identifier [0060, 0213]. In Fig. 5, the computing device includes port. Virtual router implement a packet processing and maintain multiple instances of forwarding bases [0205]. Virtual router has multiple virtual network interfaces kernel interface, vhost0 to communicate to workloads [0205-0206]. Virtual router performs tunnel encapsulation/decapsulation for packets sourced by/destined to any containers of pods, and virtual router exchanges packets with pods via bus and/or a bridge of NIC [0211] and in Fig. 5.
Disclosure includes SDN based architecture high throughput data plane. DPDK-based virtual router “CONTAINERIZED ROUTER WITH VIRTUAL NETWORKING” PGPUB US20220279420A1 [0130]. In Fig. 3B, Server 350 has two data planes for packet forwarding, a first data plane implemented by kernel 380 control traffic and a second data plane implemented by vRouter 206A. DPDK-based vRouter 206A is configured with “ownership” of physical interfaces 322. Physical interfaces 322 may be VPN attachment circuits for VRFs 212. Physical interfaces 322 may be associated with respective interfaces of vRouter 206A by which vRouter 206A sends and receives traffic via physical interfaces 322 [0094].
PNG
media_image6.png
538
642
media_image6.png
Greyscale
The techniques to deploy a logically-related group of one or more containers (“pod”) that supports the DPDK to support fast path packet communication on a data channel between a virtual router and the pod [0009]. And, cRPD 324 supports selective filtering of FIB updates to specific data planes, e.g., to kernel 380 or vRouter 206 A using routing policy constructs that allow for matching against RIB, routings instance, prefix [0101]. A data plane uses APIs 530 , 532 , 534 that can be implemented by any control-plane service. The techniques include workflows for configuring virtual network interfaces for pods, where the virtual router agent 314 obtains the information from a containerized routing protocol daemon (cRPD) 324 in response to a request for a port from CNI 312 [0112].
PNG
media_image7.png
524
620
media_image7.png
Greyscale
the generic data plane proposed an extension to the current contrail based data plane [0112]. the generic data plane interface for either type of virtual router to a control plane can be done by enhancing the current model [0140, 0142-0145]. A combination of schemes (2) and (3) may facilitate a generic data plane [0147].
Miriyala includes PGPUB US20220279420A1 in Fig. 12. Illustrates port add [0148] and for specific service port addition [0151]. )
PNG
media_image8.png
530
688
media_image8.png
Greyscale
Regarding Claim 2,
‘The DPU of claim 1’ (disclosed above),
And discloses, ‘wherein the user-defined logic is part of a user-defined network service hosted on the DPU,
and wherein the processing device is further to add,
according to the configuration file, a second service interface to the second virtual bridge to operatively couple to the user-defined network service.’ (In Fig. 3 illustrates a single cluster can include a NW controller, user interface, compute node and telemetry. Disclosure include customer-controller to provide user specific configuration apply business logic to customize resource-control [0172] and in Fig. 3 and Fig. 8; the configuration integrate users intent apply customizable resource definitions in a unified-intent-model [0161, 0169]. Configuration input from orchestrator, administrator, operator, user [0068, 0082].
In Fig. 4 SDN architecture extends and used Kubernetes API server for NW configuration objects that realizes user intents for NW configurations. Kubernetes referred as custom resources and as configuration objects are mainly user intents (VNs, VNRs, BGPaaS, NW policy etc) [0161].
customizable resources includes the resources, interfaces, and the service-instance also includes security, rule, policy, access control to the unified-intent-model [0169]; customer controller adjust/support different kind of resources based on the logic i.e. user requirement and adjust the compute resources; create instances [0171-0173]. The configurations implemented based on the logic and receives from a user/admin/operator to create one/more virtual networks. And the configurations script [0087] and service addition [0340, 0343-0350] and Fig. 12 to Fig. 15. Administrator/orchestrator extend the configuration procedure to provide better user experience for both administrators and the customer more efficiently [0120]. )
Regarding Claim 3,
‘The DPU of claim 1’ (disclosed above),
And discloses, ‘wherein the user-defined logic is part of a user-defined service hosted on the DPU, wherein the processing device is further to
add, according to the configuration file, a second service interface to the second virtual bridge to operatively couple to the user-defined service,
wherein the user-defined service is at least one of a user-defined security service, a user-defined telemetry service, or a user-defined storage service.’ (SDN architecture insights at infrastructure, cluster, and application using web user interface and telemetry components. Telemetry nodes may be cloud-native and include microservices to support insights [0127]. Techniques include monitoring (telemetry) and user interfaces, a high-performance data plane for containers using a DPDK-based virtual router connecting to DPDK-enabled pods, and container based configuration management [0128]. In Fig. 3 illustrates a single cluster can include a NW controller, user interface, compute node and telemetry. Disclosure include customer-controller to provide user specific configuration apply business logic to customize resource-control [0172]. Each of telemetry, user interface, configuration nodes, control nodes, and servers/compute nodes to implement functionalities of the configuration/UI and telemetry nodes [0158].
configurations includes security/firewall policy/rule, alarms [0169, 0192], and telemetry in UI [0127-0128] in Fig. 3. And, network monitoring/analytics visibility [0128, 0157, 0365-0370]. Configurations support scalability and KPIs for the compute resources [0128].)
Regarding Claim 4,
‘The DPU of claim 1’ (disclosed above),
And discloses, ‘wherein the processing device, according to the configuration file, is further to:
add a first network interface to the first virtual bridge to operatively couple to a first network port of the DPU;
add a second network interface to the first virtual bridge to operatively couple to a second network port of the DPU;
add a first host interface of the one or more host interfaces to the second virtual bridge to operatively couple to a host device;
add a second host interface of the one or more host interfaces to the second virtual bridge to operatively couple to the host device;’ (regarding the addition of network interface that is virtual network interface veth-pair to ports [0044, 0080-0081, 0085, 0181, 0197, 0219] in Fig. 12 to 15 includes addition of host and interface configuration/addition [0087]. That is based on a scalable configuration horizontally and vertically as part of ultra/high performance computing to scale/manage resources more efficiently [0128, 0130-0131, 0142, 0176, 0276]; multiple interface includes annotation and parameters vn1, ethernet1, vn2 eithernet2 [0397-0398]; namespace and automatically provide a pod network and service per namespace [0332-0333] );
And discloses, ‘configure a first link state propagation in the second virtual bridge between the first host interface and the one or more virtual ports’ (VRF forwarding and flow table [0310]. network controller operation of one/more virtual networks and maintain routing tables, VRFs, and tunnels; encap/decap packets VLan identifier/VxLan-tag/VN-tag [0212-0213]; route/network status [0175]; And, virtual routers implements routing by virtual network interface associated to VRF [0310]; converts configuration to forwarding for vRouter and setup flows [0155] and execute functionality of configuration/UI/telemetry by automatic-scaling [0158] . Disclosure include routing daemon/process bi-directional forwarding direction and path computation PCEP/open-Flow functionality; includes route-reflector [0269]. DPDK-based virtual router in Fig. 5 installed user-space app linked to the DPDK libs. Virtual router implement a packet processing and maintain multiple instances of forwarding bases [0205]. Virtual router has multiple virtual network interfaces kernel interface, vhost0 to communicate to workloads [0205-0206]. Virtual router performs tunnel encapsulation/decapsulation for packets sourced by/destined to any containers of pods, and virtual router exchanges packets with pods via bus and/or a bridge of NIC [0211]);
And discloses, ‘and configure a second link state propagation in the second virtual bridge between the second host interface and the one or more virtual ports.’ (configuration to interconnect the second virtual network and configuration abstraction/interconnection to connect one/more VNRs [0121] and in Fig. 1, 4 and 7. )
Regarding Claim 5,
‘The DPU of claim 4’ (disclosed above),
And discloses, ‘wherein the memory is to store an operating system (OS) to be executed on the processing device of the DPU,
and wherein the processing device, according to the configuration file, is further to: configure an OS property in the second virtual bridge.’ (the configuration defines/implement vRouters instances of configuration object [0086-0087, 0113, 0190] and execute OS [0203]; the processor provide the OS environment and the OS execute VM uses proprietary/open-source kernel-based-VM [0198,0234] )
Regarding Claim 6,
‘The DPU of claim 4’ (disclosed above),
And discloses, ‘wherein the processing device, according to the configuration file, is further to:
add a third host interface of the one or more host interfaces to the first virtual bridge to operatively couple to the host device.’ (multiple interface includes annotation and parameters vn1, ethernet1, vn2 eithernet2 [0397-0398];)
Regarding Claim 7,
‘The DPU of claim 4’ (disclosed above),
And discloses, ‘wherein the processing device, according to the configuration file, is further to:
add a first network interface to the first virtual bridge to operatively couple to a first network port of the DPU;
add a second network interface to the first virtual bridge to operatively couple to a second network port of the DPU’ (disclosed above in Claim 4. Virtual network interface represent a virtual ethernet (“veth”) pair, where each end of the pair is a compute device (e.g., a Linux/Unix device), with one end of the pair assigned to pod 22 and one end of the pair assigned to virtual router 21. The veth pair or an end of a veth pair are sometimes referred to as “ports” [0081-0083].);
And discloses, ‘add a first host interface of the one or more host interfaces to the second virtual bridge to operatively couple to a first host device, wherein the first host device is at least one of a virtual machine or a container’ (multiple virtual interfaces connect to host [0206]. Compute device/server in Fig. 5. Each of servers host one or more virtual execution elements each having at least one virtual network endpoint for one or more virtual networks. And, the virtual network endpoint be a virtual machine, a set of one or more containers (e.g., a pod), or another virtual execution element(s). The term “virtual execution element” may also encompass a pod of one or more containers. Each of the virtual network endpoints use one or more virtual network interfaces to perform packet I/O and process packet flow [0055]. );
And discloses, ‘add a second host interface of the one or more host interfaces to the second virtual bridge to operatively couple to a second host device, wherein the second host device is at least one of a virtual machine or a container’ (host e.g., pods/container/VM [0206], Fig. 1, Fig. 2 and Fig. 5 and [0055].);
And discloses, ‘configure a first link state propagation in the second virtual bridge between the first host interface and the one or more virtual ports’ (flow table VRF virtual routing in Fig. 5 and forwarding instance [0310]. Configuration and interface [0087, 0339] and addition/creation includes parameters host/ports [0181], Fig. 12 and Fig. 13. To one/more virtual networks and maintain routing tables, VRFs, and tunnels; encap/decap packets VLan identifier/VxLan-tag/VN-tag [0212-0213]; And, virtual routers executes routing by virtual network interface associated to VRF [0310]; converts configuration to forwarding for vRouter and setup flows [0155]. Disclosure include routing daemon/process bi-directional forwarding direction and path computation PCEP/open-Flow functionality [0269].);
‘and configure a second link state propagation in the second virtual bridge between the second host interface and the one or more virtual ports.’ ( interface configuration [0087] and addition to host interfaces and pods [0339])
Regarding Claim 8,
‘The DPU of claim 1, wherein the memory is to store an operating system (OS) to be executed on the processing device of the DPU, and wherein[[,]] the processing device[[,]] is to generate the plurality of virtual bridges and the interface mappings of the plurality of virtual bridges as part of installation of the OS on the DPU.’ (generates virtual bridges includes interfaces port/host [0086-0087, 0181-0189, 0253]; interface-map [0332-0338] that includes OS installation/execution [0058, 0198,0234].)
Regarding Claim 9,
‘The DPU of claim 1’ (disclosed above),
And discloses, ‘wherein the memory is to store an operating system (OS) to be executed on the processing device of the DPU and, wherein[[,]] the processing device, is to generate the plurality of virtual bridges and the interface mappings of the plurality of virtual bridges as part of runtime of the DPU and without reinstallation of the OS on the DPU.’ (Disclosure, container runtime implementation [0076]. OS executed in the virtual bridges [0058]. Configuration nodes perform CRUD/update operations/events [0145, 0179, 0181] and configuration handling module to updates the configuration [0290].)
Regarding Claim 10,
Similar to Claim 1 disclosed above a method claim, ‘A method of operating a data processing unit (DPU), the method comprising: storing a configuration file specifying a plurality of virtual bridges and interface mappings for the plurality of virtual bridges;
generating, according to the configuration file, a first virtual bridge and a second virtual bridge of the plurality of virtual bridges, the first virtual bridge to be controlled by a first network service hosted on the DPU and having a first set of one or more network rules, and the second virtual bridge to be controlled by a user-defined logic and having a second set of one or more user-defined network rules;
adding, according to the configuration file, one or more host interfaces to the second virtual bridge;
adding, according to the configuration file, a first service interface to the first virtual bridge to operatively couple to the first network service;
and adding, according to the configuration file, add one or more virtual ports between the first virtual bridge and the second virtual bridge.’
Regarding Claim 11,
‘The method of claim 10’ (disclosed above),
Similar to Claim 2 disclosed above, ‘wherein the user-defined logic is part of a user-defined network service hosted on the DPU, and wherein the method further comprises
adding, according to the configuration file, a second service interface to the second virtual bridge to operatively couple to the user-defined network service.’
Regarding Claim 12,
‘The method of claim 10’ (disclosed above),
Similar to Claim 3 disclosed above, ‘wherein the user-defined logic is part of a user-defined service hosted on the DPU, and wherein the method further comprises
adding, according to the configuration file, a second service interface to the second virtual bridge to operatively couple to the user-defined service, wherein the user-defined service is at least one of a user-defined security service, a user-defined telemetry service, or a user-defined storage service.’
Regarding Claim 13,
‘The method of claim 10’ (disclosed above),
Similar to Claim 4 disclosed above, ‘further comprising: adding, according to the configuration file, a first network interface to the first virtual bridge to operatively couple to a first network port of the DPU; adding, according to the configuration file, a second network interface to the first virtual bridge to operatively couple to a second network port of the DPU; adding, according to the configuration file, a first host interface of the one or more host interfaces to the second virtual bridge to operatively couple to a host device; adding, according to the configuration file, a second host interface of the one or more host interfaces to the second virtual bridge to operatively couple to the host device; configuring, according to the configuration file, a first link state propagation in the second virtual bridge between the first host interface and the one or more virtual ports; and configuring, according to the configuration file, a second link state propagation in the second virtual bridge between the second host interface and the one or more virtual ports.’
Regarding Claim 14,
‘The method of claim 10’ (disclosed above),
Similar to Claim 7 disclosed above, ‘further comprising: adding, according to the configuration file, a first network interface to the first virtual bridge to operatively couple to a first network port of the DPU; adding, according to the configuration file, a second network interface to the first virtual bridge to operatively couple to a second network port of the DPU; adding, according to the configuration file, a first host interface of the one or more host interfaces to the second virtual bridge to operatively couple to a first host device, wherein the first host device is at least one of a virtual machine or a container; adding, according to the configuration file, a second host interface of the one or more host interfaces to the second virtual bridge to operatively couple to a second host device, wherein the second host device is at least one of a virtual machine or a container; configuring, according to the configuration file, a first link state propagation in the second virtual bridge between the first host interface and the one or more virtual ports; and configuring, according to the configuration file, a second link state propagation in the second virtual bridge between the second host interface and the one or more virtual ports.’
Regarding Claim 15,
‘The method of claim 10’ (disclosed above),
Similar to Claim 8 disclosed above, ‘further comprising: installing an operating system (OS) to be executed on a processing device of the DPU, and wherein generating the plurality of virtual bridges and the interface mappings of the plurality of virtual bridges is part of installing the OS on the DPU.’
Regarding Claim 16,
‘The method of claim 10’ (disclosed above),
Similar to Claim 9 disclosed above, ‘further comprising: installing an operating system (OS) to be executed on a processing device of the DPU, and wherein generating the plurality of virtual bridges and the interface mappings of the plurality of virtual bridges is part of runtime of the DPU and without reinstallation of the OS on the DPU.’
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 Similarly 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
he claimed invention pertains. Patentability shall not be negated by the manner
in which the invention was made.
The factual inquiries for establishing a background for determining obviousness
under 35 U.S.C. 103 are summarized as follows:
• Determining the scope and contents of the prior art.
• Ascertaining the differences between the prior art and the claims at issue.
• Resolving the level of ordinary skill in the pertinent art.
• Considering objective evidence present in the application indicating
• obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the
claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any
evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to
point out the inventor and effective filing dates of each claim that was not commonly
owned as of the effective filing date of the later invention in order for the examiner to
consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2)
prior art against the later invention.
Claims 17-20 are rejected under 35 U.S.C. 103 as being unpatentable
over Miriyala et al. in view of VAN-DE et al. (US-20210117242-A1) hereinafter “VAN-DE”.
Regarding Claim 17,
Miriyala discloses, ‘A computing system comprising: a host device; and an integrated circuit coupled to the host device and a network, wherein the integrated circuit comprises: a network interconnect coupled to the network; a host interconnect coupled to the host device; a memory to store a configuration file specifying a plurality of virtual bridges and interface mappings for the plurality of virtual bridges’ (Disclosure the computing device perform/execute computing to host VM/kernel-based OS [0198]. And, the compute device microprocessor include multi-core processor in Fig. 5 and [0230]. and configuration disclosed above in Claim 1 and in Fig. 1-2, 4-5 and 12 to 15. Disclosure the network interconnect host interconnect includes virtual network interface to interconnect/communicate between the components uses VM/container interfaces, pod interfaces, veth interfaces and the network interfaces [0081] );
And discloses, ‘accelerated’ container/Pod and ‘hardware engine’ (Disclosure, Pod/containerized compute and accelerate flow processing [0077]. And Infrastructure on server run/execute application/services require high throughput > 20Gbps per server to support high availability [0136, 0148, 0230] and in Fig. 5. Includes container engine executed by microprocessor [0218].);
And didn’t disclose, ‘an acceleration hardware’ engine,
VAN-DE in the relevant art discloses, acceleration hardware [0081]. Fig. 9 illustrates orchestrator server and executes one/more workload implemented as compute node similar to accelerator node [0090] and in Fig. 6 perform a workload (e.g., an application 932 executed in a virtual machine or in a container) [0090]. In Fig. 18 illustrates IPU perform router/load-balancer/fire wall, service mess (SDN), security, telemetry, etc. [0146]. CPU capabilities includes inter-node and intra-node telemetry, security; and/or integrated acceleration engines that provide flexible and programmable acceleration engines [0149].
Therefore, a person in the ordinary skill in the art before the effective filing date of
the claim invention would have recognized that the disclosure of Miriyala and to include
with that of VAN-DE to come up with the claim invention,
Miriyala motive to provide ultra/high performance computing as part of SDN architecture and orchestration. Includes server architecture to perform accelerated and high-end computation [0130-0131] and support applications >20Gbps [0136]. And, container engine executed by multi-core processors [0230]. Specific motive to compute/execute compute node/server and deliver workload-specific to accelerate processing capability [0077] uses specialized hardware/GPU for high performance [0134] as part of SDN architecture to deliver throughput >20Gbps. And, efficient utilization of compute resources based on analytics, telemetry, metrics perform scheduling/addition based on metrics [0365-0370]. That is complemented by VAN-DE, workload are well-managed by hyperconverged server and computing resources uses accelerator based on the workload to more efficiently utilize resources optimize operating cost [0060]. Uses h/w accelerator nodes in Fig. 6 and also IPU in Fig. 18.
Similar to Claim 1 disclosed above, ‘and a central processing unit (CPU) coupled to the network interconnect, the host interconnect, and the hardware engine, wherein the CPU is to: generate, according to the configuration file, a first virtual bridge and a second virtual bridge of the plurality of virtual bridges, the first virtual bridge to be controlled by a first network service hosted on the integrated circuit and having a first set of one or more network rules, and the second virtual bridge to be controlled by a user-defined logic and having a second set of one or more user-defined network rules;
add, according to the configuration file, one or more host interfaces to the second virtual bridge; add, according to the configuration file, a first service interface to the first virtual bridge to operatively couple to the first network service; and add, according to the configuration file, one or more virtual ports between the first virtual bridge and the second virtual bridge.’ (Disclosure, container engine associated to the virtual bridges in Fig. 5)
And didn’t disclose, ‘acceleration’ hardware engine disclosed above and motive would be Similar disclosed above.
Regarding Claim 18,
‘The computing system of claim 17’ (disclosed above),
And discloses ‘wherein the integrated circuit is at least one of a data processing unit (DPU), a network interface card (NIC), a network interface device, or a switch, wherein the DPU is a programmable data center infrastructure on a chip.’ (computing device includes NIC and processor [0229-0230] and Fig. 13.)
Regarding Claim 19,
‘The computing system of claim 17’ (disclosed above),
Similar to Claim 2 and 11 disclosed above, ‘wherein the user-defined logic is part of a user-defined network service hosted on the integrated circuit, and wherein the CPU is further to add, according to the configuration file, a second service interface to the second virtual bridge to operatively couple to the user-defined network service.’
Regarding Claim 20,
‘The computing system of claim 17’ (disclosed above),
Similar to Claim 4 and 13 disclosed above, ‘wherein the CPU, according to the configuration file, is further to: add a first network interface to the first virtual bridge to operatively couple to a first network port of the integrated circuit; add a second network interface to the first virtual bridge to operatively couple to a second network port of the integrated circuit; add a first host interface of the one or more host interfaces to the second virtual bridge to operatively couple to the host device; add a second host interface of the one or more host interfaces to the second virtual bridge to operatively couple to the host device; configure a first link state propagation in the second virtual bridge between the first host interface and the one or more virtual ports; and configure a second link state propagation in the second virtual bridge between the second host interface and the one or more virtual ports.’
Response to Arguments
Applicant's arguments filed 06/15/2026 have been fully considered but they are
not persuasive.
Arguments and Examiners response:
With respect to applicant’s arguments/remarks, examiner responses are:
Regarding the applicant arguments in page 10, “The Examiner has alleged that Miriyala discloses the claimed virtual bridge architecture, citing Miriyala's virtual router/bridge functionality at paragraph [0202], a customer controller applying business logic at paragraph [0172], user intents with customizable resource definitions at paragraphs [0161] and [0169], and multiple virtual networks with configuration policies at paragraph [0121].”
Disclosure, generates to create virtual networks [0210] in Fig. 1. Virtual routers may be processes or threads, or a component thereof, executed by the physical servers, e.g., servers of FIG. 1 , that dynamically create and manage one or more virtual networks usable for communication between virtual network endpoints [0200]. Each virtual network may use its own addressing and security scheme. Techniques used to transport packets within and across VNs [0201]. The virtual router/bridge functionality of the Linux bridge/OVS module used for the pods to perform bridging/routing [0202] and to host-application/service/VM [0203], network services [0204] and in Fig. 1 to Fig. 2.
Fig. 3 illustrates a single cluster can includes NW controller, user interface and compute server and telemetry features [0152]. Orchestrator and NW controller execute separate alternatively on the same computing devices [0067].
Regarding applicant arguments in page-11 first paragraph, “Claims 1 and 10 as amended require, inter alia, generating "a first virtual bridge and a second virtual bridge of the plurality of virtual bridges, the first virtual bridge to be controlled by a first network service hosted on the DPU and having a first set of one or more network rules, and the second virtual bridge to be controlled by a user-defined logic and having a second set of one or more user-defined network rules."
Disclosure, Configured to interconnect a first virtual NW and a second virtual NW. Configured to define a logical abstraction of one/more policies to perform interconnection via one/more VNRs [0121]. VNRs represent VN policy [112]. Each VN use its own addressing and security scheme. Techniques used to transport packets within and across VNs [0201]. In Fig. 3 illustrates a single cluster can implement even augment three components includes NW controller, UI for user, compute node and telemetry features to provide analytics [0152].
Regard applicant argument in page-11 second paragraph “Miriyala does not disclose this architecture. The Examiner cited Miriyala paragraph [0202] for virtual router 506, which "may replace and subsume the virtual routing/bridging functionality of the Linux bridge/OVS module that is commonly used for Kubernetes deployments of pods….”
Disclosure, Container-based OS virtualization to run multiple systems on a single machine. Provides an application and application specific libs executed by the host machine as user-space instance and share OS and common libs of multiple containers executed on the host machine [0052]. Docker based container app provide app/app-based lib. Multiple Linux system/container uses single OS/Linux kernel [0053]. Compute server in Fig. 1 represent compute device provide NFVI and NFV architecture [0045]. Each of servers host one/more virtual execution elements each having at least one virtual network endpoint for one/more virtual networks. Server/Compute A virtual network endpoint may be a set of one/more containers (e.g., pods). Any server of server implement Linux bridge emulates h/w bridge forward packets among virtual network interfaces. For docker implementation of containers hosted by OVS/Linux/docker bridge [0058]. Any NIC include an internal device switch to switch between virtual h/w component associated with the NIC. For example, an SR-IOV-capable NIC, the internal device switch may be a Virtual Ethernet Bridge (VEB) to switch between the SR-IOV VFs [0059]. Encapsulate/de-capsulated packet [0061]. VRs kernel-based and a DPDK-enabled VR run as a user-space app link to the DPDK lib and VNFs [0062-0063]. Any server of server 12 implement Linux bridge emulates h/w bridge forward packets among virtual network interfaces. For docker implementation of containers hosted by OVS/Linux/docker bridge [0058]. Any NIC 13 include an internal device switch to switch between virtual h/w component associated with the NIC. For example, an SR-IOV-capable NIC, the internal device switch may be a Virtual Ethernet Bridge (VEB) to switch between the SR-IOV VFs [0059]. Encapsulate/de-capsulated packet [0061]. VRs kernel-based and a DPDK-enabled VR run as a user-space app link to the DPDK lib and VNFs [0062-0063].
Miriyala include disclosure “CONTAINERIZED ROUTER WITH VIRTUAL NETWORKING” PGPUB US20220279420A1 [0130]. In Fig. 3B and Fig. 6, Server implements two data planes for packet forwarding, a first data plane implemented by kernel 380 control traffic and a second data plane implemented by vRouter 206A. DPDK-based vRouter 206A is configured physical interfaces 322. Physical interfaces 322 s VPN attachment circuits for VRFs 212 and associated with respective interfaces of vRouter 206A by which vRouter 206A sends and receives traffic via physical interfaces 322 [0094]. The techniques to deploy a logically-related group of one or more containers (“pod”) that supports the DPDK to support fast path packet communication on a data channel between a virtual router and the pod [0009].
Regarding applicant argument in page-11 last paragraph, "controlled by user-defined logic" limitation is disclosed by Miriyala's customer controller…And “…different control paradigms and independent sets of network rules on the same device”. And in page-12 first paragraph, “the newly added limitation requiring the second virtual bridge to have "a second set of one or more user-defined network rules",
Disclosure Miriyala includes [0130] of PGPUB US20220279420A1 discloses, cRPD 324 supports selective filtering of FIB updates to specific data planes, e.g., to kernel 380 or vRouter 206 A using routing policy constructs that allow for matching against RIB, routings instance, prefix [0101]. A data plane uses APIs 530 , 532 , 534 that can be implemented by any control-plane service. The techniques include workflows for configuring virtual network interfaces for pods, where the virtual router agent 314 obtains the information from a containerized routing protocol daemon (cRPD) 324 in response to a request for a port from CNI 312 [0112].
And main disclosure Mirilyala, Configured with one/more forwarding rules to route packets in Fig. 1 and illustrated as flow table Fig. 5. Integration pod-to-service-network [0342] and in Fig. 13. Disclosure include customer-controller to provide user specific configuration apply business logic to customize resource-control [0172] and in Fig. 3 and Fig. 8; the configuration integrate users intent apply customizable resource definitions in a unified-intent-model [0161, 0169]. Configuration input from orchestrator, administrator, operator, user [0068, 0082]. VNRs referred as Virtual Network Policy (VNP) or Virtual Network Topology [0112]. Configuration objects are mainly user intents (e.g., Virtual Networks—such as VNs 50 , VNRs 52 , Network Policy, etc.). the SDN architecture support application-based security. These security policies can be based upon metatags to apply granular security policy in an extensible manner. Virtual networks are connected by policy. Kubernetes network policy operates at the Kubernetes namespace boundary [0125]. VNRs represent a logical abstraction of policies used to configure import and export of routing information between VNs 50 , whereby VNRs 52 referred to asymmetric or symmetric import and export) of routing information using a common route target established for each of VNRs [0159].
Mirilaya PGPUB US20220279420A1 discloses, cRPD 324 supports selective filtering of FIB updates to specific data planes, e.g., to kernel 380 or vRouter 206 A using routing policy constructs that allow for matching against RIB, routings instance, prefix [0101].
Mirilaya main disclosure the Data plane consists of two components: virtual router agent 514 (aka Agent) and virtual router forwarding plane 506 (also referred to as DPDK vRouter/Kernel vRouter) Agent 514 in the SDN architecture solution is responsible to manage the data plane component. Agent 514 establishes neighborships with two control nodes 232, then perform routing. The vRouter agent 514 also dynamically generates flow entries and injects them into the virtual router 506 . This gives instructions to virtual router 506 to forward packets [0308]. An administrator/ Kubernetes administrator interface with user interface 244 (e.g., web UI 306) to define VNRs that is the virtual NW policy [0160].
Miriyala discloses, PGPUB US20220279420A1 regarding the VNR referred as virtual NW policy [0158]. For better network packet I/O performance packet-send/receive, DPDK framework [0308]. K's cluster is performed using YAML includes in container [0330]. DPDK vRouter forwarding performance. DPDK configuration for applications and programming vRouter features include routing, NW namespace, ACL NW policies for security, tunnels and integration with DPDK vRouter 206A for higher forwarding performance , encapsulation , packet filter ing and QoS [0309-0319]. Delivery as set of containers that can deployed in K8s using an YAML spec [0320].
Regarding applicant argument page 12 second paragraph, “virtual ports between the first virtual bridge and the second virtual bridge" limitation is disclosed by Miriyala's veth pairs (paragraphs [0080]-[0081])….”
Mirilaya discloses, virtual network interface denotes veth-pair where each end of the pair is a Linux (i.e. OVS/docker bridge [0058]), one end of the pair assigned to pod and one end of the pair assigned to virtual router. The veth pair/an end of a veth pair are sometimes referred to as “ports” [0081]. Virtual network interfaces referred to as virtual machine interfaces (VMIs), pod interfaces, container network interfaces, veth interfaces, simply network interfaces [0081]. Kubernetes objects for CRUD events uses Pod, service, Node-Port, Ingress, Endpoint, Namespace, Deployment, Network Policy [0181].
Regarding USC 35 103 rejection and applicant argument page-13 “Claim 17 as amended requires the same independent bridge control domains with independent sets of network rules as discussed above with respect to claim 1. Specifically, claim 17 requires generating "a first virtual bridge and a second virtual bridge of the plurality of virtual bridges, the first virtual bridge to be controlled by a first network service hosted on the integrated circuit and having a first set of one or more network rules, and the second virtual bridge to be controlled by a user-defined logic and having a second set of one or more user-defined network rules." Examiner provided relevant disclosure in the above in Claim 17.
And, VAN-DE discloses, acceleration hardware [0081]. In Fig. 9 illustrates orchestrator server and executes one/more workload implemented as compute node similar to accelerator node [0090] and in Fig. 6 perform a workload (e.g., an application 932 executed in a virtual machine or in a container) [0090]. In Fig. 18 illustrates IPU perform router/load-balancer/fire wall, service mesh (SDN), security, telemetry, etc. [0146]. CPU capabilities includes node telemetry, security; and/or integrated acceleration engines that provide flexible and programmable acceleration engines [0149]. Examiner included motivation for the combination of prior arts.
Examiner thanks applicant and attorney for their time and effort.
Conclusion
The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure:
H. M. Tseng, H. L. Lee, J. W. Hu, T. L. Liu, J. -G. Chang and W. C. Huang, "Network Virtualization with Cloud Virtual Switch," 2011 IEEE 17th International Conference on Parallel and Distributed Systems, Tainan, Taiwan, 2011, pp. 998-1003; Virtual Ethernet Bridge (VEB), virtual switch (vSwitch) as the bridge module in common Linux distributions. Each virtual machine in VMM has least one virtual network interface cards (vNICs) connect to the Host, page-998 and Fig. 1-2. Disclosure, VN-tag in Fig. 3-4 VN-tag and tag-format/operation. And, interface and integrated Linux-based HyperV and VM, i.e. OVS/Linux-based bridge. In Fig. 5, vSwitch/OVS connected to two Host includes, a Host-1 is a management network and a Host-2 data network are executed in VM exhibits VLAN partitioning. Install OVS bridge interface perform virtual switch function connect to network interface ethernet. Includes network configuration libVirt run in console/CLI/interface/management GUI. Installation Linux distributions page-1001. And, VM configuration and open-source-toolkit to execute the vSwitch settings in Fig. 11-12. Disclosure, Fig. 3 to 5.
PNG
media_image9.png
463
804
media_image9.png
Greyscale
Njavro, Anton, et al. "A DPU solution for container overlay networks." 2022. (Year: 2022); Disclosure includes data processing units (DPU) includes docker-bridge
PNG
media_image10.png
295
826
media_image10.png
Greyscale
PNG
media_image11.png
437
411
media_image11.png
Greyscale
Monaco, Francesco. Enabling Seamless Autoscaling of Service Function Chains in Kubernetes. Diss. Polytechnic di Torino, 2022. (Year: 2022); Virtual ethernet pair connected by Linux bridge page-71 to 72, and Fig. 6.
Firestone, Daniel. "VFP: A virtual switch platform for host SDN in the public cloud." 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17). 2017. VFP design Fig. 1, page-318; Connect VMs to the network, which scales well with the number of servers, and allows the physical network to be simple, scalable and very fast. A control from a data plane on the host. Frequent updates, Linux and Windows OS support bridging, filter-model for ports and NICs; User-defined-rule/definitions an End User definitions to secure their VMs, ACLs included in VFPv2 to add user-defined actions, page-316, 320-321, section 5.3.3. VFP unified-flow table in Fig. 7; Xeon Sandy Bridge CPU in Fig. 9.
PNG
media_image12.png
324
744
media_image12.png
Greyscale
PNG
media_image13.png
311
635
media_image13.png
Greyscale
PNG
media_image14.png
434
446
media_image14.png
Greyscale
Fernandes, Diogo AB, et al. "Security issues in cloud environments: a survey." International journal of information security 13.2 (2014): 113-170.
Service Function Chaining Design & Implementation Using Network Service Mesh in Kubernetes (Year: 2022). Kubernetes container workloads and network services. Automate deployment, scaling, and management of containerized applications, section 2.2, page-12 3rd paragraph. Self-contained NFs are moved into container such as router or firewalls. Container-native Network Function (CNF) is a software implementation of a network function, page-125, 2nd paragraph. Networking in Kubernetes provides container NW interface (CNI) and comprises specifications and libraries for plug-ins to configure network interfaces in Linux containers. A unique file called the CNI plug-in is responsible for inserting the correct network interface into the container network while making any necessary changes on the host, section 2.4, page, 125, 3rd paragraph. Network Service Mesh (NSM) utilizes Kubernetes networking model to perform specific networking functions. NSM illustrated in Fig. 3, is a novel approach to solving L2/L3 such as SFC. Includes NW-service L2/L3, NW service-endpoints (NSEs) a Pod in a Kubernetes cluster that provides the NS application., and L2/L3 connection between the client’s Pod and the NSE(s). NSM extends beyond kernel interface to support complex use cases and provides other interfaces such as memif or vhost-user interfaces. A memif inter face, called Shared Memory Packet Interfaces, provides high-performance packet transmit and receive between the user application and Vector Packet Processing (VPP). NSM connectivity is in Fig.2. illustrates how a client can access an NS on the Kubernetes cluster. NW service a chain of microservices identified in a cluster to allow users to access. After creating an NW service, users will request to join a specific NW service in the cluster by assigning a Pod to the user and creating a vWire to connect to the NW service. page-126 first paragraph. In Fig.4. Kubernetes configuration files, YAML. Matching rules in Fig. 4b. Specifically, the first matching rule requires that the forwarder direct all traffic flow from any client that connects with this NS to the ‘firewall’ Pod, the entry point to the chain in the cluster. The matching rule is indicated in the red box in Fig.4b. The second matching rule requires that traffic flow from the firewall Pod be steered to a second Pod, the ‘vid-reduction’ Pod, in Fig. 4b. And, SFC in Kubernetes to deploy the Pods in the cluster in Fig. 5 and details in page-130, 2nd and 3rd paragraph.
PNG
media_image15.png
628
856
media_image15.png
Greyscale
PNG
media_image16.png
358
634
media_image16.png
Greyscale
PNG
media_image17.png
837
741
media_image17.png
Greyscale
Applicant's amendment necessitated the new ground(s) of rejection presented in
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a).
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 extension
fee 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 date of this final action.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Syed Ahmed whose telephone number is (703)-756-5308. The examiner can normally be reached from Monday-Friday 9am-6pm. The examiner can also be reached on alternate If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Faruk Hamza can be reached on (571) 272-7969. 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.
/S.A./Examiner, Art Unit 2466
/CHRISTOPHER M CRUTCHFIELD/Primary Examiner, Art Unit 2466
Prosecution Insights