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 on 04/27/2026 is 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
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.
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.
Claims 1-3, 13-14 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Zhang et al. (US 2016/0226957), Zhang hereinafter.
Re. Claim 1, Zhang teaches a system comprising: (Fig. 2, 11, 18-20);
processing circuitry; a physical interface; (¶0048 - As illustrated, the gateway 111 comprises processing cores 211-214 and a network interface controller (NIC) 220));
a data plane development kit (DPDK) data plane configured to execute on the processing circuitry to determine whether to transfer a packet, received via the physical interface, to a kernel data plane for decapsulation; (Fig. 8, 18 & ¶0134 - As illustrated, the packet processing threads 1810 (i.e., the datapath daemon) is operating in the user space for handling L2 switching, L3 routing, and services such as Firewall, NAT. Other service tasks such as ARP … learning, BFD … are considered slower running and therefore handled by separate processes 1820 in the user space. These slower tasks are not handled by the datapath daemon. The packet processing threads 1810 relies on a set of DPDK libraries 1830 (Data Plane Development Kit® by Intel®) for receive packets from a NIC 1840. In some embodiments, the datapath daemon relies on a user space NIC driver that uses poll mode to receive packets from the NIC 1840. Please also see ¶0135 and ¶0144);
and the kernel data plane, configured to execute on the processing circuitry to perform the decapsulation for the packet (Fig. 8, 18 & ¶0044 - In some of these embodiments, each of the host machines and the gateway machines is a VXLAN endpoint (referred to as VTEP) that transmits packets using overlay encapsulation. ¶0084 - In some of these embodiments, datapath daemon uses user-kernel data transport mechanism such as KNI (Kernel NIC Interface) or TUN/TAP virtual network kernel devices to transport packets between the user space datapath daemon and the external process (e.g., through the kernel network stack). ¶0088 - The user-kernel transport 860 receives a packet 883 dispatched from the stage 813 (i.e., when the datapath is performing the stage 813), and the dispatched packet 883 is delivered to the network stack 890. The network stack 890 is in the kernel space of the operating system. The kernel network stack 890 processes the dispatched packet 883 and makes it ready for consumption by other processes in the machine… ¶0144 - The VTEP at the destination host decapsulates the packet and forwards only the original inner data packet to the destination VM).
Re. Claim 2, Zhang teaches Claim 1.
Zhang further teaches the packet is destined to a workload executed by the processing circuitry (Fig. 2, 11, 18-20 & ¶0078 - … the datapath daemon of an edge gateway offloads workload by performing one or more of its stages or operations by using processes or processing threads that are external the datapath daemon. In some of these embodiments, the datapath daemon dispatches packets to those external processes at certain points of the datapath daemon. Please also see ¶0074).
Re. Claim 3, Zhang teaches Claim 1.
Zhang further teaches a containerized routing protocol process configured to execute on the processing circuitry to configure the DPDK data plane to set, for an address prefix, a next hop to an interface of the kernel data plane, wherein the DPDK data plane is configured to transfer, based on the next hop for the address prefix, the packet to the kernel data plane (Fig. 2, 11, 18-20 & ¶0051 - For some stages that correspond to logical routers or switches, the DP configuration database in some embodiments provide content for routing tables or forwarding tables that specify next hops. ¶0054 - Such next hop identifying rules in some embodiments allow the datapath daemon to determine the identity of the next hop by examining the content of the packet (e.g., its source and destination addresses) … ¶0084 - datapath daemon uses user-kernel data transport mechanism such as KNI (Kernel NIC Interface) … to transport packets between the user space datapath daemon and the external process (e.g., through the kernel network stack). ¶0138 - In some other embodiments, a service process runs within a container and does not use IPC to communicate with the RTC thread and is in fact unaware of the RTC threads. The process opens standard TCP/UDP socket to send and receive packets from Linux kernel. Instead of using IPC to communicate between service process and RTC threads, … KNI devices are created within the container. Routing table for the container is properly populated so that packets sent by service process can be routed using the proper … KNI devices).
Re. Claim 13, Zhang teaches non-transitory computer-readable storage media comprising instructions that are executable to cause processing circuitry of a system to: (Fig. 2, 11, 18-20 & ¶0154);
determine, by a data plane development kit (DPDK) data plane of the system, whether to transfer a packet, received via a physical interface of the system, to a kernel data plane of the system for decapsulation; (Fig. 8, 18 & ¶0134 - As illustrated, the packet processing threads 1810 (i.e., the datapath daemon) is operating in the user space for handling L2 switching, L3 routing, and services such as Firewall, NAT. Other service tasks such as ARP … learning, BFD … are considered slower running and therefore handled by separate processes 1820 in the user space. These slower tasks are not handled by the datapath daemon. The packet processing threads 1810 relies on a set of DPDK libraries 1830 (Data Plane Development Kit® by Intel®) for receive packets from a NIC 1840. In some embodiments, the datapath daemon relies on a user space NIC driver that uses poll mode to receive packets from the NIC 1840. Please also see ¶0135 and ¶0144);
and perform, by the kernel data plane, decapsulation for the packet (Fig. 8, 18 & ¶0044 - In some of these embodiments, each of the host machines and the gateway machines is a VXLAN endpoint (referred to as VTEP) that transmits packets using overlay encapsulation. ¶0084 - In some of these embodiments, datapath daemon uses user-kernel data transport mechanism such as KNI (Kernel NIC Interface) or TUN/TAP virtual network kernel devices to transport packets between the user space datapath daemon and the external process (e.g., through the kernel network stack). ¶0088 - The user-kernel transport 860 receives a packet 883 dispatched from the stage 813 (i.e., when the datapath is performing the stage 813), and the dispatched packet 883 is delivered to the network stack 890. The network stack 890 is in the kernel space of the operating system. The kernel network stack 890 processes the dispatched packet 883 and makes it ready for consumption by other processes in the machine… ¶0144 - The VTEP at the destination host decapsulates the packet and forwards only the original inner data packet to the destination VM).
Re. Claim 14, Zhang teaches the instructions are further executable to cause the processing circuitry to: configure, by a containerized routing protocol process of the system, the DPDK data plane to set, for an address prefix, a next hop to an interface of the kernel data plane; and transfer, by the DPDK data plane, based on the next hop for the address prefix, the packet to the kernel data plane (Fig. 2, 11, 18-20 & ¶0051 - For some stages that correspond to logical routers or switches, the DP configuration database in some embodiments provide content for routing tables or forwarding tables that specify next hops. ¶0054 - Such next hop identifying rules in some embodiments allow the datapath daemon to determine the identity of the next hop by examining the content of the packet (e.g., its source and destination addresses) … ¶0084 - datapath daemon uses user-kernel data transport mechanism such as KNI (Kernel NIC Interface) … to transport packets between the user space datapath daemon and the external process (e.g., through the kernel network stack). ¶0138 - In some other embodiments, a service process runs within a container and does not use IPC to communicate with the RTC thread and is in fact unaware of the RTC threads. The process opens standard TCP/UDP socket to send and receive packets from Linux kernel. Instead of using IPC to communicate between service process and RTC threads, … KNI devices are created within the container. Routing table for the container is properly populated so that packets sent by service process can be routed using the proper … KNI devices).
Re. Claim 20, Zhang teaches a method comprising: sending, by a data plane development kit (DPDK) data plane of a system, first packets via a physical interface of the system; determining, by the DPDK data plane, whether to transfer a packet, received via the physical interface, to a kernel data plane of the system for decapsulation; (Fig. 8, 18 & ¶0134 - As illustrated, the packet processing threads 1810 (i.e., the datapath daemon) is operating in the user space for handling L2 switching, L3 routing, and services such as Firewall, NAT. Other service tasks such as ARP … learning, BFD … are considered slower running and therefore handled by separate processes 1820 in the user space. These slower tasks are not handled by the datapath daemon. The packet processing threads 1810 relies on a set of DPDK libraries 1830 (Data Plane Development Kit® by Intel®) for receive packets from a NIC 1840. In some embodiments, the datapath daemon relies on a user space NIC driver that uses poll mode to receive packets from the NIC 1840. Please also see ¶0135 and ¶0144);
and performing, by the kernel data plane, the decapsulation for the packet (Fig. 8, 18 & ¶0044 - In some of these embodiments, each of the host machines and the gateway machines is a VXLAN endpoint (referred to as VTEP) that transmits packets using overlay encapsulation. ¶0084 - In some of these embodiments, datapath daemon uses user-kernel data transport mechanism such as KNI (Kernel NIC Interface) or TUN/TAP virtual network kernel devices to transport packets between the user space datapath daemon and the external process (e.g., through the kernel network stack). ¶0088 - The user-kernel transport 860 receives a packet 883 dispatched from the stage 813 (i.e., when the datapath is performing the stage 813), and the dispatched packet 883 is delivered to the network stack 890. The network stack 890 is in the kernel space of the operating system. The kernel network stack 890 processes the dispatched packet 883 and makes it ready for consumption by other processes in the machine… ¶0144 - The VTEP at the destination host decapsulates the packet and forwards only the original inner data packet to the destination VM).
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.
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 factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Zhang, and further in view of Lin et al. (US 2023/0239268), Lin hereinafter.
Re. Claim 5, Zhang teaches Claim 1.
Yet, Zhang does not explicitly teach the physical interface is included in a plurality of physical interfaces of the system, and wherein each of the plurality of physical interfaces is assigned to the DPDK data plane.
However, in the analogous art, Lin explicitly teaches the physical interface is included in a plurality of physical interfaces of the system, and wherein each of the plurality of physical interfaces is assigned to the DPDK data plane (Fig. 5 & ¶0002 - The present disclosure involves computer-implemented method, medium, and system for managing the assignment of IP addresses for DPDK enabled network interfaces for cloud native pods of containers running containerized applications in a container orchestration system. One example computer-implemented method includes creating, in a container orchestration platform, a pod of one or more containers, where the pod is coupled to multiple networks through multiple network interfaces. A poll mode driver (PMD) is attached to a first network interface of the multiple network interfaces, where the PMD enables one or more data plane development kit (DPDK) applications inside the pod to manage the first network interface, and the one or more DPDK applications accelerate packet processing for a data plane in a first network corresponding to the first network interface).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Lin to the teaching of Zhang. The motivation would be because the invention describes technologies for managing IP for DPDK enabled network interfaces for cloud native pods (¶0014, Lin).
Claims 6 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang and Lin, and further in view of DPDK Release Guide 16.07.2 (https://doc.dpdk.org/guides-16.07/prog_guide/kernel_nic_interface.html), DPDK Release Guide 16.07.2 hereinafter.
Re. Claim 6, Zhang and Lin teach Claim 5.
Yet, Zhang and Lin do not explicitly teach the plurality of physical interfaces comprises one or more ports, and wherein for each port of the plurality of physical interfaces, a corresponding vhost interface is configured between the DPDK data plane and the kernel data plane.
However, in the analogous art, DPDK Release Guide 16.07.2 explicitly teaches the plurality of physical interfaces comprises one or more ports, (Fig. 20.1 & 20. Kernel NIC Interface - The DPDK Kernel NIC Interface (KNI) allows user space applications access to the Linux* control plane. Allows management of DPDK ports using standard Linux net tools such as ethtool, ifconfig and tcpdump. 20.8.3 Sample Usage - This command runs the kni sample application with two physical ports. Each port pins two forwarding cores (ingress/egress) in user space);
and wherein for each port of the plurality of physical interfaces, a corresponding vhost interface is configured between the DPDK data plane and the kernel data plane (Fig. 20.3, Fig. 20.4 & 20.8 KNI Working as a Kernel vHost Backend - vHost is a kernel module usually working as the backend of virtio (a para- virtualization driver framework) to accelerate the traffic from the guest to the host. The DPDK Kernel NIC interface provides the ability to hookup vHost traffic into userspace DPDK application. Together with the DPDK PMD virtio, it significantly improves the throughput between guest and host. In the scenario where DPDK is running as fast path in the host, kni-vhost is an efficient path for the traffic. 20.8.3 Sample Usage - Before starting to use KNI as the backend of vhost, the CONFIG_RTE_KNI_VHOST configuration option must be turned on. Of course, as a prerequisite, the vhost/vhost-net kernel CONFIG should be chosen before compiling the kernel).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of DPDK Release Guide 16.07.2 to the teachings of Zhang and Lin. The motivation would be because the document provides software architecture information, development environment information and optimization guidelines (Introduction, DPDK Release Guide 16.07.2).
Re. Claim 8, Zhang and Lin and DPDK Release Guide 16.07.2 teach Claim 6.
Yet, Zhang and Lin do not explicitly teach the DPDK data plane is configured to transfer, based on the packet being received via a port of the one or more ports, the packet to the kernel data plane via the vhost interface corresponding to the port.
However, in the analogous art, DPDK Release Guide 16.07.2 explicitly teaches the DPDK data plane is configured to transfer, based on the packet being received via a port of the one or more ports, the packet to the kernel data plane via the vhost interface corresponding to the port (Fig. 20.1 & 20. Kernel NIC Interface - The DPDK Kernel NIC Interface (KNI) allows user space applications access to the Linux* control plane. Allows management of DPDK ports using standard Linux net tools such as ethtool, ifconfig and tcpdump. 20.8.3 Sample Usage - This command runs the kni sample application with two physical ports. Each port pins two forwarding cores (ingress/egress) in user space. Fig. 20.3, Fig. 20.4 & 20.8 KNI Working as a Kernel vHost Backend - vHost is a kernel module usually working as the backend of virtio (a para- virtualization driver framework) to accelerate the traffic from the guest to the host. The DPDK Kernel NIC interface provides the ability to hookup vHost traffic into userspace DPDK application. Together with the DPDK PMD virtio, it significantly improves the throughput between guest and host. In the scenario where DPDK is running as fast path in the host, kni-vhost is an efficient path for the traffic. 20.8.3 Sample Usage - Before starting to use KNI as the backend of vhost, the CONFIG_RTE_KNI_VHOST configuration option must be turned on. Of course, as a prerequisite, the vhost/vhost-net kernel CONFIG should be chosen before compiling the kernel).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of DPDK Release Guide 16.07.2 to the teachings of Zhang and Lin. The motivation would be because the document provides software architecture information, development environment information and optimization guidelines (Introduction, DPDK Release Guide 16.07.2).
Claims 9-11 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang, and further in view of Daly et al. (US 2017/0180273), Daly hereinafter.
Re. Claim 9, Zhang teaches Claim 1.
Zhang further teaches the DPDK data plane is configured to determine whether to transfer the packet to the kernel data plane for decapsulation (Fig. 8, 18 & ¶0134 - As illustrated, the packet processing threads 1810 (i.e., the datapath daemon) is operating in the user space for handling L2 switching, L3 routing, and services such as Firewall, NAT. Other service tasks such as ARP … learning, BFD … are considered slower running and therefore handled by separate processes 1820 in the user space. These slower tasks are not handled by the datapath daemon. The packet processing threads 1810 relies on a set of DPDK libraries 1830 (Data Plane Development Kit® by Intel®) for receive packets from a NIC 1840. In some embodiments, the datapath daemon relies on a user space NIC driver that uses poll mode to receive packets from the NIC 1840. Please also see ¶0135 and ¶0144);
Yet, Zhang does not explicitly teach based on an encapsulation type of the packet or a label of the packet.
However, in the analogous art, Daly explicitly teaches based on an encapsulation type of the packet or a label of the packet (Fig. 2-5 & ¶0034 - The host controller 140 receives a frame, the vSwitch 114 programs rules that map outer VXLAN, VXLAN-Generic-Protocol-Extension (GPE)+NSH, Generic Network Virtualization Encapsulation (Geneve), or Network Virtualization using Generic Routing Extension (NVGRE) headers into the metadata. In an embodiment, The PF 141 processes these rules for: 1) matching the rules on outer header (L2, L3, VNI, and Service Header); 2) decapsulates the matched outer header, and 3) and adds some additional metadata for signaling the removed header. The pipeline processing detects the removed outer header and processes the inner header accordingly).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Daly to the teaching of Zhang. The motivation would be because the invention relates to processing of data packets sent or received through a network. Some embodiments relate to hardware acceleration of data packet processing (¶0001, Daly).
Re. Claim 10, Zhang teaches Claim 1.
Zhang further teaches the DPDK data plane is configured to determine whether to transfer the packet to the kernel data plane for decapsulation (Fig. 8, 18 & ¶0134 - As illustrated, the packet processing threads 1810 (i.e., the datapath daemon) is operating in the user space for handling L2 switching, L3 routing, and services such as Firewall, NAT. Other service tasks such as ARP … learning, BFD … are considered slower running and therefore handled by separate processes 1820 in the user space. These slower tasks are not handled by the datapath daemon. The packet processing threads 1810 relies on a set of DPDK libraries 1830 (Data Plane Development Kit® by Intel®) for receive packets from a NIC 1840. In some embodiments, the datapath daemon relies on a user space NIC driver that uses poll mode to receive packets from the NIC 1840. Please also see ¶0135 and ¶0144);
Yet, Zhang does not explicitly teach based on a determination that the DPDK data plane is unable to process the packet.
However, in the analogous art, Daly explicitly teaches based on a determination that the DPDK data plane is unable to process the packet (Fig. 2-5 & ¶0073 - 2) If application of a partial set of rules pertaining to this packet occurred, or if this packet misses in the hardware tables, forward the frame to the default rule VF for handling. These frames picked up by the PMD and processed in the DPDK user-space pipeline. ¶0074 - 3) Optionally, specific flows needing kernel processing trapped to the PF 141 for standard kernel processing. ¶0075 - When programming the hardware, rules that split traffic between virtio alias, default user space, and kernel data paths preserve conversational ordering).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Daly to the teaching of Zhang. The motivation would be because the invention relates to processing of data packets sent or received through a network. Some embodiments relate to hardware acceleration of data packet processing (¶0001, Daly).
Re. Claim 11, Zhang teaches Claim 1.
Zhang further teaches the DPDK data plane is configured to determine whether to transfer the packet to the kernel data plane for decapsulation (Fig. 8, 18 & ¶0134 - As illustrated, the packet processing threads 1810 (i.e., the datapath daemon) is operating in the user space for handling L2 switching, L3 routing, and services such as Firewall, NAT. Other service tasks such as ARP … learning, BFD … are considered slower running and therefore handled by separate processes 1820 in the user space. These slower tasks are not handled by the datapath daemon. The packet processing threads 1810 relies on a set of DPDK libraries 1830 (Data Plane Development Kit® by Intel®) for receive packets from a NIC 1840. In some embodiments, the datapath daemon relies on a user space NIC driver that uses poll mode to receive packets from the NIC 1840. Please also see ¶0135 and ¶0144);
Yet, Zhang does not explicitly teach based on forwarding information in a routing table of the DPDK data plane.
However, in the analogous art, Daly explicitly teaches based on forwarding information in a routing table of the DPDK data plane (Fig. 2-5 & ¶0015 - … data plane components include mechanisms that forward traffic to those destinations … Data plane components can include, by way of non-limiting example, Data Plane Development Kit (DPDK) components … ¶0072 - 1) If application of all of the rules pertaining to the packets coming TO this VF 130/VM occurred, then forwarding the frame to the VF 130 corresponding to this VM. The PMD picks up this frame and pushes the frame to the VM over the HOV path. ¶0073 - 2) If application of a partial set of rules pertaining to this packet occurred, or if this packet misses in the hardware tables, forward the frame to the default rule VF for handling. These frames picked up by the PMD and processed in the DPDK user-space pipeline. ¶0074 - 3) Optionally, specific flows needing kernel processing trapped to the PF 141 for standard kernel processing. ¶0075 - When programming the hardware, rules that split traffic between virtio alias, default user space, and kernel data paths preserve conversational ordering. That is one rule does not forward a particular 5-tuple (Destination IP, Source IP, L4-Destination, L4-Source, Protocol) via one path and then forward another frame with the same 5-tuple through another path).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Daly to the teaching of Zhang. The motivation would be because the invention relates to processing of data packets sent or received through a network. Some embodiments relate to hardware acceleration of data packet processing (¶0001, Daly).
Re. Claim 18, Zhang teaches Claim 13.
Zhang further teaches the instructions are further executable to cause the processing circuitry to: determine, by the DPDK data plane, whether to transfer the packet to the kernel data plane for decapsulation (Fig. 8, 18 & ¶0134 - As illustrated, the packet processing threads 1810 (i.e., the datapath daemon) is operating in the user space for handling L2 switching, L3 routing, and services such as Firewall, NAT. Other service tasks such as ARP … learning, BFD … are considered slower running and therefore handled by separate processes 1820 in the user space. These slower tasks are not handled by the datapath daemon. The packet processing threads 1810 relies on a set of DPDK libraries 1830 (Data Plane Development Kit® by Intel®) for receive packets from a NIC 1840. In some embodiments, the datapath daemon relies on a user space NIC driver that uses poll mode to receive packets from the NIC 1840. Please also see ¶0135 and ¶0144);
Yet, Zhang does not explicitly teach based on an encapsulation type of the packet or a label of the packet.
However, in the analogous art, Daly explicitly teaches based on an encapsulation type of the packet or a label of the packet (Fig. 2-5 & ¶0034 - The host controller 140 receives a frame, the vSwitch 114 programs rules that map outer VXLAN, VXLAN-Generic-Protocol-Extension (GPE)+NSH, Generic Network Virtualization Encapsulation (Geneve), or Network Virtualization using Generic Routing Extension (NVGRE) headers into the metadata. In an embodiment, The PF 141 processes these rules for: 1) matching the rules on outer header (L2, L3, VNI, and Service Header); 2) decapsulates the matched outer header, and 3) and adds some additional metadata for signaling the removed header. The pipeline processing detects the removed outer header and processes the inner header accordingly).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Daly to the teaching of Zhang. The motivation would be because the invention relates to processing of data packets sent or received through a network. Some embodiments relate to hardware acceleration of data packet processing (¶0001, Daly).
Re. Claim 19, Zhang teaches Claim 13.
Zhang further teaches the instructions are further executable to cause the processing circuitry to: determine, by the DPDK data plane, whether to transfer the packet to the kernel data plane for decapsulation (Fig. 8, 18 & ¶0134 - As illustrated, the packet processing threads 1810 (i.e., the datapath daemon) is operating in the user space for handling L2 switching, L3 routing, and services such as Firewall, NAT. Other service tasks such as ARP … learning, BFD … are considered slower running and therefore handled by separate processes 1820 in the user space. These slower tasks are not handled by the datapath daemon. The packet processing threads 1810 relies on a set of DPDK libraries 1830 (Data Plane Development Kit® by Intel®) for receive packets from a NIC 1840. In some embodiments, the datapath daemon relies on a user space NIC driver that uses poll mode to receive packets from the NIC 1840. Please also see ¶0135 and ¶0144);
Yet, Zhang does not explicitly teach based on forwarding information in a routing table of the DPDK data plane.
However, in the analogous art, Daly explicitly teaches based on forwarding information in a routing table of the DPDK data plane (Fig. 2-5 & ¶0015 - … data plane components include mechanisms that forward traffic to those destinations … Data plane components can include, by way of non-limiting example, Data Plane Development Kit (DPDK) components … ¶0072 - 1) If application of all of the rules pertaining to the packets coming TO this VF 130/VM occurred, then forwarding the frame to the VF 130 corresponding to this VM. The PMD picks up this frame and pushes the frame to the VM over the HOV path. ¶0073 - 2) If application of a partial set of rules pertaining to this packet occurred, or if this packet misses in the hardware tables, forward the frame to the default rule VF for handling. These frames picked up by the PMD and processed in the DPDK user-space pipeline. ¶0074 - 3) Optionally, specific flows needing kernel processing trapped to the PF 141 for standard kernel processing. ¶0075 - When programming the hardware, rules that split traffic between virtio alias, default user space, and kernel data paths preserve conversational ordering. That is one rule does not forward a particular 5-tuple (Destination IP, Source IP, L4-Destination, L4-Source, Protocol) via one path and then forward another frame with the same 5-tuple through another path).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Daly to the teaching of Zhang. The motivation would be because the invention relates to processing of data packets sent or received through a network. Some embodiments relate to hardware acceleration of data packet processing (¶0001, Daly).
Allowable Subject Matter
Claim 17 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: The Examiner has conducted a search of Patent and Non-Patent Literature and was unable to find any prior art which solely or in combination with another reference teaches the limitation of:
Claim 17 - store data indicating a correspondence between the physical interface and a vhost interface; and transfer, by the DPDK data plane, based on the packet being received via the physical interface and based on the data indicating the correspondence, the packet to the kernel data plane via the vhost interface.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Yu et al. (US 2022/0103460) – Please see Abstract and Fig. 1-5.
Singh et al. (US 2019/028091) – Please see Abstract and Fig. 1-9.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALYSSA WILLIAMS whose telephone number is (571)270-7673. The examiner can normally be reached Mon-Fri 8-5pm. 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, Ayman Abaza can be reached on (571) 270-0422. 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.
/ALYSSA WILLIAMS/Examiner, Art Unit 2465B
/AYMAN A ABAZA/Primary Examiner, Art Unit 2465
Prosecution Insights