DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed on 03/16/2026.
Claims 1-4, 6, and 8-22 are pending.
Claim Objections
Claims 1-4, 6, 8-11 and 20-22 are objected to because of the following informalities: In claims 1 and 20, “determining, by the driver multiplexor, that a virtual function of a network virtualization client is configured to transmit the data packet is available” should read “determining, by the driver multiplexor, that a virtual function of a network virtualization client [[is]] configured to transmit the data packet is available”. Appropriate correction is required.
Further, in claims 1, 12, and 20, “cause the reconfiguration of the network virtual component” should read “cause [[the]] reconfiguration of the network virtual component”. Appropriate correction is required.
Claims 2-4, 6, 8-11, 13-19, and 21-22 depend, directly or indirectly, from objected claims and do not resolve the deficiencies thereof and are therefore objected to for at least the same reasons.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 12-19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 12 recites the limitation "the network virtual component" in lines 13-14. There is insufficient antecedent basis for this limitation in the claim. There is no prior mention of a network virtual component within the claim. For the sake of compact prosecution, Examiner will interpret this to mean “the network virtualization component”.
Claim 12 further recites “a network virtualization component” in line 17. It is unclear if this is meant to refer to the network virtualization component recited earlier in the claim or a different network virtualization component.
Claims 13-19 depend, directly or indirectly, from rejected claims and do not resolve the deficiencies thereof and are therefore rejected for at least the same reasons.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 12-19 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 12-19 are directed to a system and fall within the statutory category of machines. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claim 12: The limitation of “wherein the driver multiplexor aggregates available data paths for transmitting data packets to and from the application such that a single data path is visible to the software library;”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe and evaluate available data paths and based on these evaluations can mentally aggregate the data paths. This may also be done with pencil and paper. Further, the limitation of “determining, by the driver multiplexor, that a virtual function configured to transmit the data packet is unavailable”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe, judge, and evaluate the availability of a virtual function.
Therefore, Yes, claim 12 recites a judicial exception.
The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception.
Step 2A Prong 2:
Claim 12: The judicial exception is not integrated into a practical application. In particular, the claim recites the following additional element – “A system comprising: a processing system; and memory coupled to the processing system, the memory comprising computer executable instructions that, when executed by the processing system, perform operations comprising:” which is merely a recitation of generic computing components used as a tool (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Further, the claim recites the following additional elements – “providing, by an application via a software library, a data packet to a driver multiplexor” and “by querying a network virtualization component comprising the virtual function and configured to expose the virtual function,” which are merely recitations of data transmission and data gathering which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the claim recites the following additional elements – “a driver multiplexor implemented in user space of a computing environment”, “wherein the driver multiplexer abstracts management of the virtual function away from the application and does not reconfigure or cause the reconfiguration of the network virtual component,”, and “and wherein the virtual function provides increased network performance for transmitting the data packet compared to transmitting the data packet without using the virtual function;”, which are merely recitations of field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, the claim recites the following additional element – “transmitting the data packet to a network virtualization component via a raw socket,” which is merely a recitation data transmission which is insignificant extra solution activity (see MPEP § 2106.05(g)) which does not integrate a judicial exception into practical application. Further, the claim recites the following additional elements – “wherein the network virtualization component is internal to the computing environment and external to the user space of the computing environment” which are merely recitations of the field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, the claim recites the following additional element – “transmitting the data packet to a virtual switch” which is merely a recitation of data transmission which is insignificant extra solution activity (see MPEP § 2106.05(g)) which does not integrate a judicial exception into practical application. Further, the claim recites the following additional element – “a virtual switch that is external to the computing environment;” which is merely a recitation of field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, the claim recites the following additional element – “and transmitting the data packet to the network interface component” which is merely a recitation of data transmission which is insignificant extra solution activity (see MPEP § 2106.05(g)) which does not integrate a judicial exception into practical application.
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
After having evaluated the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claim 12 not only recites a judicial exception but that the claim is directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
Claim 12: The claim does not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components, field of use/technological environment, and insignificant extra solution activity which do not amount to significantly more than the abstract idea. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)].
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claim 12 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 13, it recites additional element recitations of “wherein transmitting the data packet to the network virtualization component via the raw socket comprises: using a raw socket driver to provide the driver multiplexor access to the raw socket, wherein the raw socket driver is implemented in the user space of the computing environment and the raw socket is implemented in kernel space of the computing environment” which is merely a recitation of the field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception onto practical application. Further, claim 13 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 13 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 13 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 14, it recites additional element recitations of “wherein the network virtualization component is implemented in kernel space of the computing environment” which is merely a recitation of the field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception onto practical application. Further, claim 14 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 14 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 14 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 15, it recites an additional element recitation of “wherein the network virtualization component encapsulates the data packet” which is merely data transmission which is insignificant extra solution activity (see MPEP § 2106.05(g)) which does not integrate a judicial exception onto practical application. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Further, claim 15 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 15 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 15 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 16, it recites additional element recitations of “wherein the data packet is a raw Ethernet frame” which is merely a recitation of the field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception onto practical application. Further, claim 16 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 16 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 16 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 17, it recites additional element recitations of “wherein the raw socket is associated with a filter mechanism, the filter mechanism enabling monitoring and filtering of the data packet as the data packet is being transmitted via the raw socket” which is merely a recitation of the field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception onto practical application. Further, claim 17 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 17 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 17 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 18, it recites additional element recitations of “wherein transmitting the data packet to the network interface component comprises: transmitting, by the network virtualization component, the data packet to a virtual network interface card; and transmitting, by the network interface component the data packet to a virtual switch” which is merely a recitation of generic computing components and data transmission which is insignificant extra solution activity (see MPEP § 2106.05(f) and § 2106.05(g)) which does not integrate a judicial exception onto practical application. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Further, claim 18 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 18 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 18 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 19, it recites additional element recitations of “wherein the virtual network interface card and the virtual switch are implemented external to the computing environment and internal to a virtual environment comprising the computing environment” which is merely a recitation of the field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate a judicial exception onto practical application. Further, claim 19 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 19 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 19 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Therefore, Claims 12-19 do not recite patent eligible subject matter under U.S.C. §101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4, 6, and 8-11 are rejected under 35 U.S.C. 103 as being unpatentable over Sivakumar (US 2022/0279421 A1) in view of Goel (US 2012/0033673 A1) in view of Rajat Goel (US 8,108,551 B1).
With regard to claim 1, Sivakumar teaches:
A system comprising: a processing system; “In an example, a computing device comprises a containerized routing protocol process executing on processing circuitry of the computing device and configured to receive routing information…” [Sivakumar ¶ 22].
and memory coupled to the processing system, the memory comprising computer executable instructions that, when executed by the processing system, perform operations comprising: “A non-transitory computer readable medium comprising instructions that, when executed, cause processing circuitry to perform operations comprising:…” [Sivakumar Claim 20].
providing, by an application “Network interface card 230 may also implement SR-IOV to enable sharing the physical network function (I/O) among one or more virtual execution elements, such as containers 229A-229B or one or more virtual machines (applications) (not shown in FIG. 2)” [Sivakumar ¶ 170].
via a software library, “In a DPDK-based deployment of virtual router 206A (shown in FIG. 2), virtual router 206A is installed as a user space 245 application that is linked to the DPDK library” [Sivakumar ¶ 179].
a data packet to “In one example, network packets, e.g., layer three (L3) IP packets or layer two (L2) Ethernet packets generated or consumed by the containers 229A-229B within the virtual network domain may be encapsulated in another packet (e.g., another IP or Ethernet packet) that is transported by the physical network … Virtual router 206A performs tunnel encapsulation/decapsulation for packets sourced by/destined to any containers of pods 202, and virtual router 206A exchanges packets with pods 202 via bus 242 and/or a bridge of NIC 230” [Sivakumar 182].
a to a driver multiplexor implemented in user space of a computing environment, “cRPD 324 operates as the control plane for a router implemented by server 600 and DPDK-based vRouter 206A operates as the fast path forwarding plane for the router… As such, in server 600, cRPD 324 interfaces with two disjoint data planes: kernel 380 and the DPDK-based vRouter 206A. cRPD 324 leverages the kernel 380 networking stack to setup routing exclusively for the DPDK fast path” [Sivakumar ¶ 98, 105]. “In combination, the containerized cRPD and containerized DPDK-based virtual router may thus be a fully functional containerized router” [Sivakumar ¶ 12 Examiner notes the combination of cRPD and virtual router 206A is considered the driver multiplexor]. “cRPD may be executed in the user space of the host as a containerized process” [Sivakumar ¶ 11, fig. 8].
wherein the driver multiplexor aggregates (selects) available data paths for transmitting data packets to and from the application “In general, SDN controller 70 controls the network configuration of radio access network 9 to facilitate packetized communications among DUs 22, CUs 13, and mobile core network 7. SDN controller 70 may distribute routing and configuration information to the control plane elements of radio access networks 9, in particular, to cRPDs 24” [Sivakumar ¶ 72]. “The cRPD also programs the data plane on each compute node. For better network packet I/O performance, the DU application may run in the application Pod to bypass the kernel networking stack and abstractions, and thereby use, e.g., zero-copy mechanisms to directly send/receive packets from the physical NIC” [Sivakumar ¶ 19 Examiner notes the programming of the data plane is considered aggregating the data paths]. “For example, the active data plane may be a DPDK-based virtual router, while the backup data plane may be a kernel-based virtual router” [Sivakumar ¶ 17]. “The cRPD may leverage the kernel's networking stack to set up routing exclusively for the DPDK fast path” [Sivakumar 16].
such that a single data path is visible to the software library; “The corresponding MPLS routes may be programmed by cRPD 324 only to vRouter 206A, via interface 340 with vRouter agent 314, and not to kernel 380. That is so because the next-hop of these MPLS labels is a pop-and-forward to a pod interface for one of pods 422A, 422L; these interfaces are only visible in vRouter 206A and not kernel 380. Similarly, reachability information received over BGP L3VPN may be selectively programmed by cRPD 324 to vRouter 206A, for such routes are only needed for forwarding traffic generated by pods 422A, 422” [Sivakumar ¶ 106].
determining, by the driver multiplexor, that a virtual function of a network virtualization client “As explained with respect to FIGS. 3A-3B, DUs 22 containers may receive 5G radio traffic from Port0, which is using single root I/0 virtualization (SR-IOV) to create multiple virtual functions (VFs) or instances for the physical function (port), with each VF terminating in its own Pod (one of DUs 22). These VFs are visible to the Linux kernel 380, however, they are no routing protocols run over them. Their sole purpose is to haul the radio traffic into DUs 22 … To provide reachability over tunnels, cRPD 324 may be configured with the requisite protocols (IGPs, BGP etc.). DPDK vRouter 206A would manage the physical Port1-over which routing traffic would be sent and received” [Sivakumar ¶ 252-253]. “The data plane may be implemented using a DPDK-based virtual router and expose a gRPC interface 340 for exchanging control data. For instance, a virtual router agent (network virtualization client) 314 for the virtual router data plane may operate as a gRPC server 520 that exposes gRPC APIs for programming the virtual router data plane 206A. 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” [Sivakumar ¶ 112].
is configured to transmit the data packet is available “After a DPDK Pod comes up (interface added by CNI), there may be a situation where DPDK data path may not be available for some reason (Datapath has crashed, being restarted or undergoing upgrade/maintenance). Applications that require high network availability, it is desirable for the application PODs to have a fall back or alternate method of traffic forwarding…During the window, the application (or an enhanced DPDK library running as a part of the application process) will detect the primary (DPDK) interface is down and switches to using the kernel (backup) interface” [Sivakumar ¶ 294, 296]. “Similarly, when the DPDK vRouter 206A is restored, routing stack could detect the availability and restore the routes and interface state such that application POD traffic starts going via the DPDK vRouter 206A” [Sivakumar ¶ 299].
by evaluating a component registry comprising entries for active components of the computing environment, “This may include setting up a vhost control channel and assigning IP (e.g., both IPv4 and IPv6) and MAC addresses, advertising the Pod IP addresses, and detecting and withdrawing the routes when the Pod is considered down or removed” [Sivakumar ¶ 20]. “Routing stack could detect DPDK vRouter 206A (active component) being out of service (a TCP connection is used between routing stack and DPDK vRouter 206A) and update the next-hop information and bring up the core facing (physical) interface state accordingly. Similarly, when the DPDK vRouter 206A is restored, routing stack could detect the availability and restore the routes and interface state such that application POD traffic starts going via the DPDK vRouter 206A” [Sivakumar ¶ 298].
wherein the driver multiplexer abstracts management of the virtual function away from the application “Virtual router 206A implements one or more virtual routing and forwarding instances (VRFs) 222A-222B for respective virtual networks for which virtual router 206A operates as respective tunnel endpoints. In general, each VRF 222 stores forwarding information for the corresponding virtual network and identifies where data packets are to be forwarded and whether the packets are to be encapsulated in a tunneling protocol, such as with a tunnel header that may include one or more headers for different layers of the virtual network protocol stack” [Sivakumar 183].“In an aspect of the disclosure, a generic data plane model is decoupled from a network controller for virtualized computing infrastructure … The techniques include workflows for configuring virtual network interfaces for pods, where the virtual router agent obtains the information from a containerized routing protocol daemon (cRPD) in response to a request for a port issued by the CNI” [Sivakumar ¶ 15, fig. 8 Examiner notes the locations of cRPD and virtual router 206A away from the pod 202A].
and the driver multiplexer does not reconfigure or cause the reconfiguration of the network virtualization client; “vRouter agent 314 creates a virtual network interface (referred to here as a virtual machine interface or VMI, which is an example of a virtual network interface) in interfaces 540 (704). vRouter agent 314 configures the virtual network interface in vRouter 206A with a default VRF identifier, with a VMI Add message (706)” [Sivakumar ¶ 162 Examiner notes, nowhere in Sivakumar is a teaching that the driver multiplexor, either the cRPD or the vRouter, cause reconfiguration of the network virtualization client, vRouter agent 314].
in response to determining the virtual function is available, providing the data packet to the virtual function using a virtual function driver “Similarly, when the DPDK vRouter 206A is restored, routing stack could detect the availability and restore the routes and interface state such that application POD traffic starts going via the DPDK vRouter 206A” [Sivakumar ¶ 299]. “In a DPDK-based deployment of virtual router 206A (shown in FIG. 2), virtual router 206A is installed as a user space 245 application that is linked to the DPDK library. This may lead to faster performance than a kernel-based deployment, particularly in the presence of high packet rates. The physical interfaces 232 are used by the poll mode drivers (PMDs) of DPDK rather the kernel's interrupt-based drivers.” [Sivakumar ¶ 179].
wherein an interface provided by the virtual function driver enables the data packet to bypass a kernel network stack of the kernel space, “For better network packet I/O performance, the DU application may run in the application Pod to bypass the kernel networking stack and abstractions, and thereby use, e.g., zero-copy mechanisms to directly send/receive packets from the physical NIC” [Sivakumar ¶ 19].
thereby achieving increased network performance for transmitting the data packet compared to transmitting the data packet without using the virtual function; “DPDK enables building applications that can bypass the kernel for packet I/O. Application can directly send/receive the packets from the NIC and can achieve high performance by using polling. Bypassing kernel for packet i/o results in better performance (as result of reducing the number of context switches, packet contents being copied and polling mode is not feasible/desirable in the kernel)” [Sivakumar ¶ 291].
and transmitting the data packet to a network interface component via the virtual function, wherein the network interface component is external to the computing environment. “For better network packet I/O performance, the DU application may run in the application Pod to bypass the kernel networking stack and abstractions, and thereby use, e.g., zero-copy mechanisms to directly send/receive packets from the physical NIC” [Sivakumar ¶ 19, Fig. 8 Examiner notes the separation between NIC 230 and the virtual environment].
Sivakumar fails to explicitly teach wherein the driver multiplexor aggregates available data paths for transmitting data packets to and from the application such that a single data path is visible to the software library; providing the data packet to the virtual function using a virtual function driver shared across the user space and a kernel space of the computing environment.
However, Goel teaches:
wherein the driver multiplexor aggregates available data paths for transmitting data packets to and from the application such that a single data path is visible to the software library; “In other embodiments, one of a plurality of drivers may operate in a virtualization domain executing on a core while another driver operates in another virtualization domain executing on another core. The drivers or portions of the drivers may interoperate directly or indirectly to facilitate reception and/or transmission of packets” [Goel ¶ 319]. “A para-virtualized driver may be selected for operation in place of an original or real device driver corresponding to a hardware. In some embodiments, the para-virtualized driver 377 is a modified version of the device driver. With paravirtualization, the para-virtualized driver may interact directly with a domain 0 (e.g., Dom0) entity, for example, at a higher abstraction level than the normal hardware/software interface. The domain 0 entity may expose an I/O type-specific API, for example, to send and receive packets. The Para-virtualized driver executing on a guest OS may then use this I/O interface instead of interacting directly with a hardware device interface. Dom0 and DomU may employ or support a split device driver model. One portion of the driver (e.g., para-virtualized driver), such as a front end and another portion of the driver, such as a back end of the driver may be isolated from each other in separate domains, and may communicate by mechanisms provided by the hypervisor. Dom0 may operate one portion of the split driver while DomU operates the other portion of the driver.” [Goel ¶ 322-323].
providing the data packet to the virtual function using a virtual function driver shared across the user space and a kernel space of the computing environment, “Dom0 and DomU may employ or support a split device driver model. One portion of the driver (e.g., para-virtualized driver), such as a front end and another portion of the driver, such as a back end of the driver may be isolated from each other in separate domains, and may communicate by mechanisms provided by the hypervisor. Dom0 may operate one portion of the split driver while DomU operates the other portion of the driver.” [Goel ¶ 323]. “The virtualization domain may support or employ a split driver model for communicating and/or processing packets. In these embodiments, the virtualization domain may execute a split driver that interacts with the network interface hardware (e.g., via the TCP/IP stack)” [Goel ¶ 331].
Goel is considered to be analogous to the claimed invention because it is in the same field of I/O management. Sivakumar includes a driver multiplexor (cRPD) which selects the available data paths, this can be made to include the function of Goel where multiple drivers are combined and modified to create a singular data path. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sivakumar to incorporate the teachings of Goel and include that the driver multiplexor aggregates available data paths for transmitting data packets to and from the application such that a single data path is visible to the software library; providing the data packet to the virtual function using a virtual function driver shared across the user space and a kernel space of the computing environment. Doing so would allow for a data path from a virtual environment to have privileged access to the network interface. “The virtualization domain may have privileged access to the network interface hardware in part because of the split driver. In certain embodiments, the split driver in the virtualization domain is configured to have access to the network interface hardware and/or the TCP/IP stack for conveying a received packet” [Goel ¶ 331].
Sivakumar in view of Goel fails to explicitly teach determining, by the driver multiplexor, that a virtual function configured to transmit the data packet is available by evaluating a component registry comprising entries for active components of the computing environment, the entries including an entry indicating the virtual function is active.
However, Rajat Goel teaches:
determining, by the driver multiplexor, that a virtual function configured to transmit the data packet is available by evaluating a component registry comprising entries for active components of the computing environment, “In some embodiments, the host may create an active-port list (component registry) that identifies which communication ports are active. For example, upon successfully accessing a network device through the physical path, the host may add each communication port in the physical path to an active-port list. The active-port list may allow the host to determine whether a second logical path is active without probing the physical path again” [Rajat Goel Col. 2 Lines 1-5].
the entries including an entry indicating the virtual function is active, “At step 412, the systems described herein may use the results of the probe of the physical path to determine whether the second logical path is active without probing the physical path a second time. For example, path-monitoring module 106 may compare each communication port in the physical path with active-port list 124. If active-port list 124 includes each communication port in the physical path, path-monitoring module 106 may determine that the second logical path is active” [Rajat Goel Col. 9 Lines 45-53].
Rajat Goel is considered to be analogous to the claimed invention because it is in the same field of I/O management. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sivakumar in view of Goel to incorporate the teachings of Rajat Goel and include determining, by the driver multiplexor, that a virtual function configured to transmit the data packet is available by evaluating a component registry comprising entries for active components of the computing environment, the entries including an entry indicating the virtual function is active. Doing so would allow for the detection of path availability without repeatedly probing the same components. “As such, the instant disclosure identifies a need for a multipathing technique that eliminates redundancy by monitoring physical paths within a computer network” [Rajat Goel Col. 1 Lines 24-26].
With regard to claim 2, Sivakumar in view of Goel in view of Rajat Goel teaches The system of claim 1, as referenced above. Sivakumar further teaches wherein the computing environment is a guest environment implemented by a host device. “In general, this disclosure describes techniques for a containerized router operating within a cloud native orchestration framework…A container networking interface plugin (CNI) is a networking solution for application containers and is a runtime executable that assists with configuring interfaces between containers and other components of the computing device ("host") hosting the container, which may be a member of a pod” [Sivakumar ¶ 9]. “In the example computing device 800 of FIG. 2, virtual router 206A executes within user space as a DPDK-based virtual router, but virtual router 206A may execute within a hypervisor, a host operating system, a host application, or a virtual machine in various implementations.” [Sivakumar ¶ 171].
With regard to claim 4, Sivakumar in view of Goel in view of Rajat Goel teaches The system of claim 1, as referenced above. Sivakumar further teaches:
wherein the data packet is provided to the driver multiplexor by an application in the user space of the computing environment via a software library, “In a DPDK-based deployment of virtual router 206A (shown in FIG. 2), virtual router 206A is installed as a user space 245 application that is linked to the DPDK library” [Sivakumar ¶ 179].
the software library enabling offloading of data packets processing from kernel space of the computing environment to the user space of the computing environment. “In this way, cRPD 324 may operate as the control plane for executing routing protocols for virtualized cell site router 20A in a way that incorporates the network stack, routing protocol infrastructure, and other networking features of kernel 380; while vRouter 206A may operate as the data plane for forwarding data traffic between DUs 22A-l-22A-N and physical interfaces 322 in a way that excludes the kernel 380. As a result, because DPDK-based vRouter 206A runs in user space and in general provides better performance capabilities as compared to kernel-based forwarding” [Sivakumar ¶ 97]. “During the window, the application (or an enhanced DPDK library running as a part of the application process) will detect the primary (DPDK) interface is down and switches to using the kernel (backup) interface” [Sivakumar ¶ 296 Examiner notes that the DPDK library is considered to enable the offloading to user space when it detects that the primary interface is available].
With regard to claim 6, Sivakumar in view of Goel in view of Rajat Goel teaches The system of claim 1, as referenced above. Sivakumar further teaches:
wherein transmitting the data packet to the network interface component via the virtual function comprises: using a virtual function driver to provide the driver multiplexor access to the virtual function, “In a DPDK-based deployment of virtual router 206A (shown in FIG. 2), virtual router 206A is installed as a user space 245 application that is linked to the DPDK library. This may lead to faster performance than a kernel-based deployment, particularly in the presence of high packet rates. The physical interfaces 232 are used by the poll mode drivers (PMDs) of DPDK rather the kernel's interrupt-based drivers.” [Sivakumar ¶ 179]. “As such, in server 600, cRPD 324 interfaces with two disjoint data planes: kernel 380 and the DPDK-based vRouter 206A” [Sivakumar ¶ 98].
Sivakumar fails to explicitly teach wherein the virtual function driver is shared across the user space of the computing environment and the kernel space of the computing environment.
However, Goel teaches wherein the virtual function driver is shared across the user space of the computing environment and the kernel space of the computing environment. “Dom0 and DomU may employ or support a split device driver model. One portion of the driver (e.g., para-virtualized driver), such as a front end and another portion of the driver, such as a back end of the driver may be isolated from each other in separate domains, and may communicate by mechanisms provided by the hypervisor. Dom0 may operate one portion of the split driver while DomU operates the other portion of the driver.” [Goel ¶ 323]. “The virtualization domain may support or employ a split driver model for communicating and/or processing packets. In these embodiments, the virtualization domain may execute a split driver that interacts with the network interface hardware (e.g., via the TCP/IP stack)” [Goel ¶ 331].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sivakumar to incorporate the teachings of Goel and include that the virtual function driver is shared across the user space of the computing environment and the kernel space of the computing environment. Doing so would allow for a data path from a virtual environment to have privileged access to the network interface. “The virtualization domain may have privileged access to the network interface hardware in part because of the split driver. In certain embodiments, the split driver in the virtualization domain is configured to have access to the network interface hardware and/or the TCP/IP stack for conveying a received packet” [Goel ¶ 331].
With regard to claim 8, Sivakumar in view of Goel in view of Rajat Goel teaches The system of claim 1, as referenced above. Sivakumar further teaches wherein the virtual function enables the data packet to be transmitted from the kernel space of the computing environment to the user space of the computing environment such that the data packet bypasses the kernel network stack. “For better network packet I/O performance, the DU application may run in the application Pod to bypass the kernel networking stack and abstractions, and thereby use, e.g., zero-copy mechanisms to directly send/receive packets from the physical NIC” [Sivakumar ¶ 19]. “vRouter 206A exposes respective interfaces 382 to kernel 380 for physical interfaces 322. That is, for each of physical interfaces, vRouter 206A exposes an interface to kernel 380. Each of interfaces 382 may be a vHost interface. Kernel 380 may therefore send and receive network packets with vRouter 206A via interfaces 382” [Sivakumar ¶ 95]. [Sivakumar Fig. 6 and 8, Examiner notes that element 382A, vhost0, may be used to transmit the data packet from kernel space to user space].
With regard to claim 9, Sivakumar in view of Goel in view of Rajat Goel teaches The system of claim 1, as referenced above. Sivakumar further teaches wherein the virtual function enables the data packet to be transmitted from the kernel space of the computing environment to the network interface component such that the data packet bypasses the kernel network stack. “For better network packet I/O performance, the DU application may run in the application Pod to bypass the kernel networking stack and abstractions, and thereby use, e.g., zero-copy mechanisms to directly send/receive packets from the physical NIC” [Sivakumar ¶ 19]. “vRouter 206A exposes respective interfaces 382 to kernel 380 for physical interfaces 322. That is, for each of physical interfaces, vRouter 206A exposes an interface to kernel 380. Each of interfaces 382 may be a vHost interface. Kernel 380 may therefore send and receive network packets with vRouter 206A via interfaces 382” [Sivakumar ¶ 95]. [Sivakumar Fig. 6 and 8, Examiner notes that element 382A, vhost0, may be used to transmit the data packet from kernel space to user space].
With regard to claim 10, Sivakumar in view of Goel in view of Rajat Goel teaches The system of claim 1, as referenced above. Sivakumar further teaches wherein a data path for transmitting the data packet to a network interface component via the virtual function is a hardware data path. “PODs 422A-422L are endpoints from the perspective of vRouter 206A, and in particular may represents overlay endpoints for one or more virtual networks that have been programmed into vRouter 206A. A single vhost interface, vhost0 interface 382A, may be an example of any of interfaces 328 of FIG. 3B, and is exposed by vRouter 206A to kernel 380 and in some cases by kernel 380 to vRouter 206A…Underlay networking refers to the physical infrastructure that provides connectivity between nodes (typically servers) in the network. The underlay network is responsible for delivering packets across the infrastructure.” [Sivakumar ¶ 98 and 99].
With regard to claim 11, Sivakumar in view of Goel in view of Rajat Goel teaches The system of claim 1, as referenced above. Sivakumar further teaches wherein the virtual function is determined to be unavailable due to an operational failure of at least one of: the virtual function; the network virtualization client; or the network interface component. “After a DPDK Pod comes up (interface added by CNI), there may be a situation where DPDK data path may not be available for some reason (Datapath has crashed, being restarted or undergoing upgrade/maintenance). Applications that require high network availability, it is desirable for the application PODs to have a fall back or alternate method of traffic forwarding.” [Sivakumar ¶ 296].
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Sivakumar (US 2022/0279421 A1) in view of Goel (US 2012/0033673 A1) in view of Rajat Goel (US 8,108,551 B1) in view of Shilimkar (US 2022/0182318 A1).
With regard to claim 3, Sivakumar in view of Goel in view of Rajat Goel teaches The system of claim 2, as referenced above. Sivakumar further teaches wherein the guest environment represents a virtual machine that is managed by a hypervisor of the host device; “In some instances, the operating system may execute a hypervisor and one or more virtual machines managed by hypervisor” [Sivakumar ¶ 169].
Sivakumar in view of Goel fails to teach and wherein the component registry is a registry file maintained by the hypervisor.
However, Rajat Goel teaches and wherein the component registry is a registry file maintained by the (host) hypervisor. “In some embodiments, the host may create an active-port list (component registry) that identifies which communication ports are active” [Rajat Goel Col. 2 Lines 1-2].
Sivakumar in view of Goel in view of Rajat Goel fails to teach and wherein the component registry is a registry file maintained by the hypervisor.
However, Shilimkar teaches and wherein the component registry is a registry file maintained by the hypervisor. “In some embodiments, this MAC address can be learned from the communications with the compute instance, and in some embodiments, this MAC address can be learned and/or received from a configuration file that can be, for example, stored and/or maintained by the hypervisor 608 and/or by the bond 610” [Shilimkar ¶ 166].
Rajat Goel teaches a component registry maintained by the host; this differs from the claimed invention in that the component registry is not specifically maintained by a hypervisor. However, a component registry maintained by a hypervisor is known in the art as taught by Shilimkar. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sivakumar in view of Goel in view of Rajat Goel to incorporate the teachings of Shilimkar and include that the component registry is a registry file maintained by the hypervisor. The results of doing so would have been predictable because Shilimkar teaches registry file management by a hypervisor.
Claims 12-16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Sivakumar (US 2022/0279421 A1) in view of Goel (US 2012/0033673 A1) in view of Kaplan (US 2018/0052701 A1).
With regard to claim 12, Sivakumar teaches:
A system comprising: a processing system; “In an example, a computing device comprises a containerized routing protocol process executing on processing circuitry of the computing device and configured to receive routing information…” [Sivakumar ¶ 22].
and memory coupled to the processing system the memory comprising computer executable instructions that, when executed by the processing system, perform operations comprising: “A non-transitory computer readable medium comprising instructions that, when executed, cause processing circuitry to perform operations comprising:” [Claim 20].
providing, by an application “Network interface card 230 may also implement SR-IOV to enable sharing the physical network function (I/O) among one or more virtual execution elements, such as containers 229A-229B or one or more virtual machines (applications) (not shown in FIG. 2)” [Sivakumar ¶ 170].
via a software library, “In a DPDK-based deployment of virtual router 206A (shown in FIG. 2), virtual router 206A is installed as a user space 245 application that is linked to the DPDK library” [Sivakumar ¶ 179].
a data packet to “In one example, network packets, e.g., layer three (L3) IP packets or layer two (L2) Ethernet packets generated or consumed by the containers 229A-229B within the virtual network domain may be encapsulated in another packet (e.g., another IP or Ethernet packet) that is transported by the physical network … Virtual router 206A performs tunnel encapsulation/decapsulation for packets sourced by/destined to any containers of pods 202, and virtual router 206A exchanges packets with pods 202 via bus 242 and/or a bridge of NIC 230” [Sivakumar 182].
a driver multiplexor implemented in user space of a computing environment, “cRPD 324 operates as the control plane for a router implemented by server 600 and DPDK-based vRouter 206A operates as the fast path forwarding plane for the router… As such, in server 600, cRPD 324 interfaces with two disjoint data planes: kernel 380 and the DPDK-based vRouter 206A. cRPD 324 leverages the kernel 380 networking stack to setup routing exclusively for the DPDK fast path” [Sivakumar ¶ 98, 105]. “In combination, the containerized cRPD and containerized DPDK-based virtual router may thus be a fully functional containerized router” [Sivakumar ¶ 12 Examiner notes the combination of cRPD and virtual router 206A is considered the driver multiplexor]. “cRPD may be executed in the user space of the host as a containerized process” [Sivakumar ¶ 11, fig. 8].
wherein the driver multiplexor aggregates (selects) available data paths for transmitting data packets to and from the application “In general, SDN controller 70 controls the network configuration of radio access network 9 to facilitate packetized communications among DUs 22, CUs 13, and mobile core network 7. SDN controller 70 may distribute routing and configuration information to the control plane elements of radio access networks 9, in particular, to cRPDs 24” [Sivakumar ¶ 72]. “The cRPD also programs the data plane on each compute node. For better network packet I/O performance, the DU application may run in the application Pod to bypass the kernel networking stack and abstractions, and thereby use, e.g., zero-copy mechanisms to directly send/receive packets from the physical NIC” [Sivakumar ¶ 19 Examiner notes the programming of the data plane is considered aggregating the data paths]. “For example, the active data plane may be a DPDK-based virtual router, while the backup data plane may be a kernel-based virtual router” [Sivakumar ¶ 17]. “The cRPD may leverage the kernel's networking stack to set up routing exclusively for the DPDK fast path” [Sivakumar 16].
such that a single data path is visible to the software library; “The corresponding MPLS routes may be programmed by cRPD 324 only to vRouter 206A, via interface 340 with vRouter agent 314, and not to kernel 380. That is so because the next-hop of these MPLS labels is a pop-and-forward to a pod interface for one of pods 422A, 422L; these interfaces are only visible in vRouter 206A and not kernel 380. Similarly, reachability information received over BGP L3VPN may be selectively programmed by cRPD 324 to vRouter 206A, for such routes are only needed for forwarding traffic generated by pods 422A, 422” [Sivakumar ¶ 106].
determining, by the driver multiplexor, that a virtual function configured to transmit the data packet is unavailable “After a DPDK Pod comes up (interface added by CNI), there may be a situation where DPDK data path may not be available for some reason (Datapath has crashed, being restarted or undergoing upgrade/maintenance). Applications that require high network availability, it is desirable for the application PODs to have a fall back or alternate method of traffic forwarding…During the window, the application (or an enhanced DPDK library running as a part of the application process) will detect the primary (DPDK) interface is down and switches to using the kernel (backup) interface” [Sivakumar ¶ 294, 296].
a network virtualization component comprising the virtual function and configured to expose the virtual function “As explained with respect to FIGS. 3A-3B, DUs 22 containers may receive 5G radio traffic from Port0, which is using single root I/0 virtualization (SR-IOV) to create multiple virtual functions (VFs) or instances for the physical function (port), with each VF terminating in its own Pod (one of DUs 22). These VFs are visible to the Linux kernel 380, however, they are no routing protocols run over them. Their sole purpose is to haul the radio traffic into DUs 22 … To provide reachability over tunnels, cRPD 324 may be configured with the requisite protocols (IGPs, BGP etc.). DPDK vRouter 206A would manage the physical Port1-over which routing traffic would be sent and received” [Sivakumar ¶ 252-253]. “The data plane may be implemented using a DPDK-based virtual router and expose a gRPC interface 340 for exchanging control data. For instance, a virtual router agent (network virtualization component) 314 for the virtual router data plane may operate as a gRPC server 520 that exposes gRPC APIs for programming the virtual router data plane 206A. 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” [Sivakumar ¶ 112]. “FIG. 5 is a block diagram illustrating an example vRouter agent, according to techniques of this disclosure … Interfaces 540 may represent a data structure that stores data describing virtual network interfaces for application pods executing on the server that executes vRouter agent 314” [Sivakumar ¶ 108-109].
wherein the driver multiplexer abstracts management of the virtual function away from the application “Virtual router 206A implements one or more virtual routing and forwarding instances (VRFs) 222A-222B for respective virtual networks for which virtual router 206A operates as respective tunnel endpoints. In general, each VRF 222 stores forwarding information for the corresponding virtual network and identifies where data packets are to be forwarded and whether the packets are to be encapsulated in a tunneling protocol, such as with a tunnel header that may include one or more headers for different layers of the virtual network protocol stack” [Sivakumar 183].“In an aspect of the disclosure, a generic data plane model is decoupled from a network controller for virtualized computing infrastructure … The techniques include workflows for configuring virtual network interfaces for pods, where the virtual router agent obtains the information from a containerized routing protocol daemon (cRPD) in response to a request for a port issued by the CNI” [Sivakumar ¶ 15, fig. 8 Examiner notes the locations of cRPD and virtual router 206A away from the pod 202A].
and does not reconfigure or cause the reconfiguration of the network virtual component, “vRouter agent 314 creates a virtual network interface (referred to here as a virtual machine interface or VMI, which is an example of a virtual network interface) in interfaces 540 (704). vRouter agent 314 configures the virtual network interface in vRouter 206A with a default VRF identifier, with a VMI Add message (706)” [Sivakumar ¶ 162 Examiner notes, nowhere in Sivakumar is a teaching that the driver multiplexor, either the cRPD or the vRouter, cause reconfiguration of the network virtual component, vRouter agent 314].
and wherein the virtual function provides increased network performance for transmitting the data packet compared to transmitting the data packet without using the virtual function; “DPDK enables building applications that can bypass the kernel for packet I/O. Application can directly send/receive the packets from the NIC and can achieve high performance by using polling. Bypassing kernel for packet i/o results in better performance (as result of reducing the number of context switches, packet contents being copied and polling mode is not feasible/desirable in the kernel)” [Sivakumar ¶ 291].
transmitting the data packet to a network virtualization component via a raw socket, wherein the network virtualization component is internal to the computing environment and external to the user space of the computing environment; “In a kernel-based deployment of virtual router 206A (not shown), virtual router 206A is installed as a kernel module inside the operating system. Virtual router 206A registers itself with the TCP/IP stack to receive packets from any of the desired operating system interfaces that it wants to” [Sivakumar ¶ 178]. “vrouter-dpdk: For better packet I/O performance, support vrouter-dpdk as the data-plane. This includes allocation of IP and mac addresses, generating suitable DPDK configuration for the application, programming of vrouter and advertising the routes … Typically, YAML file has to be customized to suite K8s deployment. A sample YAML configuration (platter.yml) for platter CNI is provided below:” [Sivakumar ¶ 331-332 Examiner notes “capabilities: add: … -NET_RAW” within the sample following ¶ 332].
transmitting the data packet to a virtual switch that is external to the computing environment; “The term "virtual router" as used herein may encompass an Open vSwitch (OVS), an OVS bridge, a Linux bridge, Docker bridge, or other device and/or software that is located 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 12” [Sivakumar ¶ 171]. “In a kernel-based deployment of virtual router 206A (not shown), virtual router 206A is installed as a kernel module inside the operating system. Virtual router 206A registers itself with the TCP/IP stack to receive packets from any of the desired operating system interfaces that it wants to” [Sivakumar ¶ 171].
and transmitting the data packet to a network interface component. “Control traffic 700 may represent routing protocol traffic for one or more routing protocols executed by cRPD 324. In server 600, control traffic 700 may be received over a physical interface 322 owned by vRouter 206A” [Sivakumar ¶ 100, Fig. 6 Examiner notes the control traffic 700 flowing between kernel 380 and NIC 321B].
Sivakumar fails to explicitly teach wherein the driver multiplexor aggregates available data paths for transmitting data packets to and from the application such that a single data path is visible to the software library.
However, Goel teaches:
wherein the driver multiplexor aggregates available data paths for transmitting data packets to and from the application such that a single data path is visible to the software library; “In other embodiments, one of a plurality of drivers may operate in a virtualization domain executing on a core while another driver operates in another virtualization domain executing on another core. The drivers or portions of the drivers may interoperate directly or indirectly to facilitate reception and/or transmission of packets” [Goel ¶ 319]. “A para-virtualized driver may be selected for operation in place of an original or real device driver corresponding to a hardware. In some embodiments, the para-virtualized driver 377 is a modified version of the device driver. With paravirtualization, the para-virtualized driver may interact directly with a domain 0 (e.g., Dom0) entity, for example, at a higher abstraction level than the normal hardware/software interface. The domain 0 entity may expose an I/O type-specific API, for example, to send and receive packets. The Para-virtualized driver executing on a guest OS may then use this I/O interface instead of interacting directly with a hardware device interface. Dom0 and DomU may employ or support a split device driver model. One portion of the driver (e.g., para-virtualized driver), such as a front end and another portion of the driver, such as a back end of the driver may be isolated from each other in separate domains, and may communicate by mechanisms provided by the hypervisor. Dom0 may operate one portion of the split driver while DomU operates the other portion of the driver.” [Goel ¶ 322-323].
Sivakumar includes a driver multiplexor (cRPD) which selects the available data paths, this can be made to include the function of Goel where multiple drivers are combined and modified to create a singular data path. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sivakumar to incorporate the teachings of Goel and include that the driver multiplexor aggregates available data paths for transmitting data packets to and from the application such that a single data path is visible to the software library. Doing so would allow for a data path from a virtual environment to have privileged access to the network interface. “The virtualization domain may have privileged access to the network interface hardware in part because of the split driver. In certain embodiments, the split driver in the virtualization domain is configured to have access to the network interface hardware and/or the TCP/IP stack for conveying a received packet” [Goel ¶ 331].
Sivakumar in view of Goel fails to explicitly teach by querying a network virtualization component comprising the virtual function and configured to expose the virtual function.
However, Kaplan teaches by querying a network virtualization component comprising the virtual function and configured to expose the virtual function, “In some implementations, the virtualization manager 115 may receive a client request to configure a VM with SR-IOV virtual function capabilities (e.g., assign a virtual function to a vNIC 235 of VM 230) for connecting to a network for use with some client applications. In response to the request, the virtualization manager 115 may execute the VF identifier module 202 to determine whether there is a virtual function available to support connective to the network specified in the request” [Kaplan ¶ 34]. “For example, module 202 may send a request to an agent, such as agent 145, executing on the hypervisors for the availability status of the virtual functions of logical network device associated with the hypervisor. The availability status may indicate whether the virtual function is available for assignment according to whether it has already been assigned to a virtual machine, whether it has been attached to some other type of device, or whether it is unavailable to be assigned for other reasons” [Kaplan ¶ 36].
Kaplan is considered to be analogous to the claimed invention because it is in the same field of I/O management. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sivakumar in view of Goel to incorporate the teachings of Kaplan and include by querying a network virtualization component comprising the virtual function and configured to expose the virtual function. Doing so would allow for the detection of virtual function availability upon request. “In response to the request, the virtualization manager 115 may execute the VF identifier module 202 to determine whether there is a virtual function available to support connective to the network specified in the request” [Kaplan ¶ 34].
With regard to claim 13, Sivakumar in view of Goel in view of Kaplan teaches The system of claim 12, as referenced above. Sivakumar further teaches:
wherein transmitting the data packet to the network virtualization component via the raw socket comprises: using a raw socket driver to provide the driver multiplexor access to the raw socket, “Kernel 380 outputs the network packets to cRPD 324 via interface 384. Interface 384 may represent system call interfaces/APIs exposed by kernel 380, a file system, pthread, socket, or other mechanism by which processes such as cRPD 324 can receive packets from and inject packets into kernel 380. In this way, cRPD 324 may operate as the control plane for executing routing protocols for virtualized cell site router 20A…” [Sivakumar ¶ 97]. “Virtual router 206A in this mode relies on the operating system to send and receive packets from different interfaces. For example, the operating system may expose a tap interface backed by a vhost-net driver to communicate with VMs.” [Sivakumar ¶ 178].
wherein the raw socket driver is implemented in the user space of the computing environment [Fig.8 Examiner notes the location of vhost0 382A in user space].
and the raw socket is implemented in kernel space of the computing environment. “Virtual router 206A registers itself with the TCP/IP stack to receive packets from any of the desired operating system interfaces that it wants to. The interfaces can be bond, physical, tap (for VMs), veth (for containers) etc” [Sivakumar ¶ 178]. “This will not be an interface over which cRPD 324 could run routing protocols (as that requires using kernel facilities as sockets, TCP/IP stack etc.)” [Sivakumar ¶ 260].
With regard to claim 14, Sivakumar in view of Goel in view of Kaplan teaches The system of claim 12, as referenced above. Sivakumar further teaches wherein the network virtualization component is implemented in kernel space of the computing environment. “In a kernel-based deployment of virtual router 206A (not shown), virtual router 206A is installed as a kernel module inside the operating system” [Sivakumar ¶ 178].
With regard to claim 15, Sivakumar in view of Goel in view of Kaplan teaches The system of claim 12, as referenced above. Sivakumar further teaches wherein the network virtualization component encapsulates the data packet. “Encapsulation and/or de-capsulation of virtual network packets within physical network packets may be performed by virtual router 206A” [Sivakumar ¶ 182].
With regard to claim 16, Sivakumar in view of Goel in view of Kaplan teaches The system of claim 12, as referenced above. Sivakumar further teaches wherein the data packet is a raw Ethernet frame. “In one example, network packets, e.g., layer three (L3) IP packets or layer two (L2) Ethernet packets generated or consumed by the containers 229A-229B within the virtual network domain may be encapsulated in another packet (e.g., another IP or Ethernet packet) that is transported by the physical network.” [Sivakumar ¶ 182 Examiner notes that the layer two ethernet packets are considered ethernet frames].
With regard to claim 18, Sivakumar in view of Goel in view of Kaplan teaches The system of claim 12, as referenced above. Sivakumar further teaches:
wherein transmitting the data packet to the network interface component comprises: transmitting, by the network virtualization component, the data packet to a virtual network interface card; “Control traffic 700 sent by cRPD 324 to vRouter 206A over vhost0 interface 382A may be sent by vRouter 206A out the corresponding physical interface 322 for vhost0 interface 382A” [Sivakumar ¶ 102].
and transmitting, by the network interface component the data packet to a virtual switch. “vRouter agent 314 will receive a forwarding information base (FIB) update corresponding to some routes received by cRPD 324. These routes will point to vHost0 interface 382A and vRouter 206A may automatically translate or map vHost0 interface 382A to a physical interface 322” [Sivakumar ¶ 100]. “The term "virtual router" as used herein may encompass an Open vSwitch (OVS), an OVS bridge, a Linux bridge, Docker bridge, or other device and/or software that is located 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 12” [Sivakumar ¶ 171].
With regard to claim 19, Sivakumar in view of Goel in view of Kaplan teaches The system of claim 18, as referenced above. Sivakumar further teaches wherein the virtual network interface card and the virtual switch are implemented external to the computing environment and internal to a virtual environment comprising the computing environment. [Fig. 8 Examiner notes the location of virtual router 206A and vhost0 382A within user space, but outside of container platform 804].
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Sivakumar (US 2022/0279421 A1) in view of Goel (US 2012/0033673 A1) in view of Kaplan (US 2018/0052701 A1) in view of Ganguli (2022/0014459 A1).
Regarding Claim 17, Sivakumar in view of Goel in view of Kaplan teaches The system of claim 12, as referenced above. Sivakumar further teaches:
wherein the raw socket is associated with a filter mechanism, “For example, the cRPD can… program a forwarding plane of the vCSR of the server with learned and/or configured routing information to provide layer 3 packet forwarding, encapsulation, packet filtering, and/or QoS between one or more of DUs 22 and one of CUs 13.” [Sivakumar ¶ 66].
Sivakumar in view of Goel in view of Kaplan fails to teach the filter mechanism enabling monitoring and filtering of the data packet as the data packet is being transmitted via the raw socket.
However, Ganguli teaches the filter mechanism enabling monitoring and filtering of the data packet as the data packet is being transmitted via the raw socket. “In one embodiment, the IPU core 220 may cause a raw socket (e.g., AF XDP) of the IPU 202 to be bound to a hardware port of a queue pair (QP) through side band filters. The packet processor 222 may then provide inline filters to be added in hardware as part of transmitting the packet” [Ganguli ¶ 37].
Ganguli is considered to be analogous to the claimed invention because it is in the same field of network packet transmission. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sivakumar in view of Goel in view of Kaplan to incorporate the teachings of Ganguli and include the filter mechanism enabling monitoring and filtering of the data packet as the data packet is being transmitted via the raw socket. Doing so would allow for faster and more efficient packet processing. “Embodiments herein further provide for accelerated gRPC/HTTP packet processing to strip out data from packets destined for the microservices 207 using programmable language routing rules between IPs of the IPU 202” [Ganguli ¶ 35].
Claims 20 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Sivakumar (US 2022/0279421 A1) in view of Goel (US 2012/0033673 A1) in view of Zhou (US 2022/0217093 A1).
With regard to claim 20, Sivakumar teaches:
A device comprising: a processor; “In an example, a computing device comprises a containerized routing protocol process executing on processing circuitry of the computing device and configured to receive routing information…” [Sivakumar ¶ 22].
and memory coupled to the processor, the memory comprising computer executable instructions that, when executed by the processor, perform operations comprising: A non-transitory computer readable medium comprising instructions that, when executed, cause processing circuitry to perform operations comprising:” [Claim 20].
providing, by an application via a software library, “In a DPDK-based deployment of virtual router 206A (shown in FIG. 2), virtual router 206A is installed as a user space 245 application that is linked to the DPDK library” [Sivakumar ¶ 179].
a data packet to a to a driver multiplexor implemented in user space of a computing environment, “…configuring, by the virtual router agent, based on the routing information, the virtual router with forwarding information to cause the virtual router to forward traffic to and from the workloads” [Sivakumar Claim 20]. “cRPD 324 operates as the control plane for a router implemented by server 600 and DPDK-based vRouter 206A operates as the fast path forwarding plane for the router… As such, in server 600, cRPD 324 interfaces with two disjoint data planes: kernel 380 and the DPDK-based vRouter 206A. cRPD 324 leverages the kernel 380 networking stack to setup routing exclusively for the DPDK fast path” [Sivakumar ¶ 98, 105 Examiner notes the cRPD operates as the driver multiplexor in this case]. cRPD may be executed in the user space of the host as a containerized process [Sivakumar ¶ 11].
wherein the driver multiplexor aggregates (selects) available data paths for transmitting data packets to and from the application “In general, SDN controller 70 controls the network configuration of radio access network 9 to facilitate packetized communications among DUs 22, CUs 13, and mobile core network 7. SDN controller 70 may distribute routing and configuration information to the control plane elements of radio access networks 9, in particular, to cRPDs 24” [Sivakumar ¶ 72]. “The cRPD also programs the data plane on each compute node. For better network packet I/O performance, the DU application may run in the application Pod to bypass the kernel networking stack and abstractions, and thereby use, e.g., zero-copy mechanisms to directly send/receive packets from the physical NIC” [Sivakumar ¶ 19 Examiner notes the programming of the data plane is considered aggregating the data paths]. “For example, the active data plane may be a DPDK-based virtual router, while the backup data plane may be a kernel-based virtual router” [Sivakumar ¶ 17]. “The cRPD may leverage the kernel's networking stack to set up routing exclusively for the DPDK fast path” [Sivakumar 16].
such that a single data path is visible to the software library; “The corresponding MPLS routes may be programmed by cRPD 324 only to vRouter 206A, via interface 340 with vRouter agent 314, and not to kernel 380. That is so because the next-hop of these MPLS labels is a pop-and-forward to a pod interface for one of pods 422A, 422L; these interfaces are only visible in vRouter 206A and not kernel 380. Similarly, reachability information received over BGP L3VPN may be selectively programmed by cRPD 324 to vRouter 206A, for such routes are only needed for forwarding traffic generated by pods 422A, 422” [Sivakumar ¶ 106].
determining, by the driver multiplexor, that a virtual function of a network virtual component “As explained with respect to FIGS. 3A-3B, DUs 22 containers may receive 5G radio traffic from Port0, which is using single root I/0 virtualization (SR-IOV) to create multiple virtual functions (VFs) or instances for the physical function (port), with each VF terminating in its own Pod (one of DUs 22). These VFs are visible to the Linux kernel 380, however, they are no routing protocols run over them. Their sole purpose is to haul the radio traffic into DUs 22 … To provide reachability over tunnels, cRPD 324 may be configured with the requisite protocols (IGPs, BGP etc.). DPDK vRouter 206A would manage the physical Port1-over which routing traffic would be sent and received” [Sivakumar ¶ 252-253]. “The data plane may be implemented using a DPDK-based virtual router and expose a gRPC interface 340 for exchanging control data. For instance, a virtual router agent (network virtual component) 314 for the virtual router data plane may operate as a gRPC server 520 that exposes gRPC APIs for programming the virtual router data plane 206A. 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” [Sivakumar ¶ 112].
is configured to transmit the data packet is available “After a DPDK Pod comes up (interface added by CNI), there may be a situation where DPDK data path may not be available for some reason (Datapath has crashed, being restarted or undergoing upgrade/maintenance). Applications that require high network availability, it is desirable for the application PODs to have a fall back or alternate method of traffic forwarding…During the window, the application (or an enhanced DPDK library running as a part of the application process) will detect the primary (DPDK) interface is down and switches to using the kernel (backup) interface” [Sivakumar ¶ 294, 296]. “Similarly, when the DPDK vRouter 206A is restored, routing stack could detect the availability and restore the routes and interface state such that application POD traffic starts going via the DPDK vRouter 206A” [Sivakumar ¶ 299].
wherein the driver multiplexer abstracts management of the virtual function away from the application “Virtual router 206A implements one or more virtual routing and forwarding instances (VRFs) 222A-222B for respective virtual networks for which virtual router 206A operates as respective tunnel endpoints. In general, each VRF 222 stores forwarding information for the corresponding virtual network and identifies where data packets are to be forwarded and whether the packets are to be encapsulated in a tunneling protocol, such as with a tunnel header that may include one or more headers for different layers of the virtual network protocol stack” [Sivakumar 183].“In an aspect of the disclosure, a generic data plane model is decoupled from a network controller for virtualized computing infrastructure … The techniques include workflows for configuring virtual network interfaces for pods, where the virtual router agent obtains the information from a containerized routing protocol daemon (cRPD) in response to a request for a port issued by the CNI” [Sivakumar ¶ 15, fig. 8 Examiner notes the locations of cRPD and virtual router 206A away from the pod 202A].
and the driver multiplexer does not reconfigure or cause the reconfiguration of the network virtual component; “vRouter agent 314 creates a virtual network interface (referred to here as a virtual machine interface or VMI, which is an example of a virtual network interface) in interfaces 540 (704). vRouter agent 314 configures the virtual network interface in vRouter 206A with a default VRF identifier, with a VMI Add message (706)” [Sivakumar ¶ 162 Examiner notes, nowhere in Sivakumar is a teaching that the driver multiplexor, either the cRPD or the vRouter, cause reconfiguration of the network virtual component, vRouter agent 314].
in response to determining the virtual function is available, providing the data packet to the virtual function using a virtual function driver “Similarly, when the DPDK vRouter 206A is restored, routing stack could detect the availability and restore the routes and interface state such that application POD traffic starts going via the DPDK vRouter 206A” [Sivakumar ¶ 299]. “In a DPDK-based deployment of virtual router 206A (shown in FIG. 2), virtual router 206A is installed as a user space 245 application that is linked to the DPDK library. This may lead to faster performance than a kernel-based deployment, particularly in the presence of high packet rates. The physical interfaces 232 are used by the poll mode drivers (PMDs) of DPDK rather the kernel's interrupt-based drivers.” [Sivakumar ¶ 179].
wherein an interface provided by the virtual function driver enables the data packet to bypass a kernel network stack of the kernel space “For better network packet I/O performance, the DU application may run in the application Pod to bypass the kernel networking stack and abstractions, and thereby use, e.g., zero-copy mechanisms to directly send/receive packets from the physical NIC” [Sivakumar ¶ 19].
thereby achieving increased network performance for transmitting the data packet compared to transmitting the data packet without using the virtual function; “DPDK enables building applications that can bypass the kernel for packet I/O. Application can directly send/receive the packets from the NIC and can achieve high performance by using polling. Bypassing kernel for packet i/o results in better performance (as result of reducing the number of context switches, packet contents being copied and polling mode is not feasible/desirable in the kernel)” [Sivakumar ¶ 291].
and transmitting the data packet to a network interface component via the virtual function, wherein the network interface component is external to the computing environment. “For better network packet I/O performance, the DU application may run in the application Pod to bypass the kernel networking stack and abstractions, and thereby use, e.g., zero-copy mechanisms to directly send/receive packets from the physical NIC” [Sivakumar ¶ 19, Fig. 8 Examiner notes the separation between NIC 230 and the virtual environment].
Sivakumar fails to explicitly teach wherein the driver multiplexor aggregates available data paths for transmitting data packets to and from the application such that a single data path is visible to the software library; providing the data packet to the virtual function using a virtual function driver shared across the user space and a kernel space of the computing environment.
However, Goel teaches:
wherein the driver multiplexor aggregates available data paths for transmitting data packets to and from the application such that a single data path is visible to the software library; “In other embodiments, one of a plurality of drivers may operate in a virtualization domain executing on a core while another driver operates in another virtualization domain executing on another core. The drivers or portions of the drivers may interoperate directly or indirectly to facilitate reception and/or transmission of packets” [Goel ¶ 319]. “A para-virtualized driver may be selected for operation in place of an original or real device driver corresponding to a hardware. In some embodiments, the para-virtualized driver 377 is a modified version of the device driver. With paravirtualization, the para-virtualized driver may interact directly with a domain 0 (e.g., Dom0) entity, for example, at a higher abstraction level than the normal hardware/software interface. The domain 0 entity may expose an I/O type-specific API, for example, to send and receive packets. The Para-virtualized driver executing on a guest OS may then use this I/O interface instead of interacting directly with a hardware device interface. Dom0 and DomU may employ or support a split device driver model. One portion of the driver (e.g., para-virtualized driver), such as a front end and another portion of the driver, such as a back end of the driver may be isolated from each other in separate domains, and may communicate by mechanisms provided by the hypervisor. Dom0 may operate one portion of the split driver while DomU operates the other portion of the driver.” [Goel ¶ 322-323].
providing the data packet to the virtual function using a virtual function driver shared across the user space and a kernel space of the computing environment, “Dom0 and DomU may employ or support a split device driver model. One portion of the driver (e.g., para-virtualized driver), such as a front end and another portion of the driver, such as a back end of the driver may be isolated from each other in separate domains, and may communicate by mechanisms provided by the hypervisor. Dom0 may operate one portion of the split driver while DomU operates the other portion of the driver.” [Goel ¶ 323]. “The virtualization domain may support or employ a split driver model for communicating and/or processing packets. In these embodiments, the virtualization domain may execute a split driver that interacts with the network interface hardware (e.g., via the TCP/IP stack)” [Goel ¶ 331].
Sivakumar includes a driver multiplexor (cRPD) which selects the available data paths, this can be made to include the function of Goel where multiple drivers are combined and modified to create a singular data path. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sivakumar to incorporate the teachings of Goel and include that the driver multiplexor aggregates available data paths for transmitting data packets to and from the application such that a single data path is visible to the software library; providing the data packet to the virtual function using a virtual function driver shared across the user space and a kernel space of the computing environment. Doing so would allow for a data path from a virtual environment to have privileged access to the network interface. “The virtualization domain may have privileged access to the network interface hardware in part because of the split driver. In certain embodiments, the split driver in the virtualization domain is configured to have access to the network interface hardware and/or the TCP/IP stack for conveying a received packet” [Goel ¶ 331].
Sivakumar in view of Goel fails to teach by evaluating a response message received in response to transmitting the data packet to the virtual function.
However, Zhou teaches by evaluating a response message received in response to transmitting the data packet to the virtual function, “It should be noted that the response packet sent by the second network device to the first network device may be a simple response packet, for example, an acknowledgement (Acknowledgement, ACK) character or a negative acknowledgement (Negative Acknowledgement, NACK) character packet, used to indicate that the second network device receives the data packet sent by the first network device, or that the second network device receives no data packet sent by the first network device.” [Zhou ¶ 84].
Zhou is considered to be analogous to the claimed invention because it is in the same field of network packet transmission. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sivakumar in view of Goel to incorporate the teachings of Zhou and include by evaluating a response message received in response to transmitting the data packet to the virtual function. Doing so would allow the system to transmit packets as usual and detect when a packet is not received by a virtual function, preventing accidental data loss. “This is easy to implement, and effectively resolves problems of sequence number synchronization and data packet loss” [Zhou ¶ 119]
Regarding Claim 21, Sivakumar in view of Goel in view of Zhou teaches The device of claim 20, as referenced above. Sivakumar further teaches wherein the driver multiplexor functions as a dedicated virtual function manager. “As explained with respect to FIGS. 3A-3B, DUs 22 containers may receive 5G radio traffic from Porto, which is using single root I/O virtualization (SR-IOV) to create multiple virtual functions (VFs) or instances for the physical function (port), with each VF terminating in its own Pod (one of DUs 22). These VFs are visible to the Linux kernel 380, however, they are no routing protocols run over them. Their sole purpose is to haul the radio traffic into DUs 22 … To provide reachability over tunnels, cRPD 324 may be configured with the requisite protocols (IGPs, BGP etc.). DPDK vRouter 206A would manage the physical Port1—over which routing traffic would be sent and received” [Sivakumar ¶ 252-253]. “cRPD 324 now programs the overlay routes, service label and the underlay SR-MPLS nexthop information to the vRouter 206A via the vRouter Agent (not shown in FIG. 12). The mechanics of choosing (management) a SR path is taken care of by the cRPD 324 and optionally an SDN controller/path computation engine” [Sivakumar ¶ 235].
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Sivakumar (US 2022/0279421 A1) in view of Goel (US 2012/0033673 A1) in view of Zhou (US 2022/0217093 A1) in view of Rajat Goel (US 8,108,551 B1) in view of Shilimkar (US 2022/0182318 A1).
With regard to claim 22, Sivakumar in view of Goel in view of Zhou teaches The device of claim 20, as referenced above. Sivakumar further teaches wherein a hypervisor that manages the computing environment “In some instances, the operating system may execute a hypervisor and one or more virtual machines managed by hypervisor” [Sivakumar ¶ 169].
Sivakumar in view of Goel in view of Zhou fails to teach wherein a hypervisor that manages the computing environment maintains a component registry comprising entries for active components of the computing environment.
However, Rajat Goel teaches wherein a (host) hypervisor that manages the computing environment maintains a component registry comprising entries for active components of the computing environment. “In some embodiments, the host may create an active-port list (component registry) that identifies which communication ports are active” [Rajat Goel Col. 2 Lines 1-2].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sivakumar in view of Goel in view of Zhou to incorporate the teachings of Rajat Goel and include wherein a hypervisor that manages the computing environment maintains a component registry comprising entries for active components of the computing environment. Doing so would allow for the detection of path availability without repeatedly probing the same components. “As such, the instant disclosure identifies a need for a multipathing technique that eliminates redundancy by monitoring physical paths within a computer network” [Rajat Goel Col. 1 Lines 24-26].
Sivakumar in view of Goel in view of Zhou in view of Rajat Goel fails to explicitly teach wherein a hypervisor that manages the computing environment maintains a component registry.
However, Shilimkar teaches wherein a hypervisor that manages the computing environment maintains a component registry “In some embodiments, this MAC address can be learned from the communications with the compute instance, and in some embodiments, this MAC address can be learned and/or received from a configuration file that can be, for example, stored and/or maintained by the hypervisor 608 and/or by the bond 610” [Shilimkar ¶ 166].
Rajat Goel teaches a component registry maintained by the host; this differs from the claimed invention in that the component registry is not specifically maintained by a hypervisor. However, a component registry maintained by a hypervisor is known in the art as taught by Shilimkar. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sivakumar in view of Goel in view of Zhou in view of Rajat Goel to incorporate the teachings of Shilimkar and include that a hypervisor that manages the computing environment maintains a component registry. The results of doing so would have been predictable because Shilimkar teaches registry file management by a hypervisor.
Response to Arguments
Applicant's arguments filed 03/16/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
I. Claims 12-19 were rejected under 35 U.S.C. § 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception.
Claim 12, from which claims 13-19 depend, has been amended as indicated above. As such, Applicant respectfully requests withdrawal of these rejections.
a) As is detailed in the rejection above, the recited determining, and aggregation of claim 12 are mental processes which may be performed in the mind or with pencil and paper. Thus, claim 12 recites a judicial exception. The additional elements of the claim amount to merely generic computing components, technological environment/field of use, and insignificant extra solution activity which do not integrate the judicial exception into a practical application and do not amount to significantly more than the abstract idea. Thus, the claim is directed to the judicial exception. This same reasoning holds for the elements of the dependent claims 13-19, as detailed in the above rejection. Thus, claims 12-19 are directed to a judicial exception and by only reciting additional elements which do not amount to significantly more than the judicial exception, when considered both individually and in combination, the claims do not recite patent eligible subject matter under U.S.C. §101.
II. Claim 1 as amended recites, inter alia: determining, by the driver multiplexor, that a virtual function of a network virtualization client is configured to transmit the data packet is available by evaluating a component registry comprising entries for active components of the computing environment, the entries including an entry indicating the virtual function [[in]] is active, wherein the driver multiplexer abstracts management of the virtual function away from the application and the driver multiplexer does not reconfigure or cause the reconfiguration of the network virtualization client.
Applicant submits that the cited references do not disclose or suggest at least the above- emphasized features of claim 1 as amended. Therefore, claim 1 as amended is believed to be allowable over the cited references.
Independent claims 12 and 20 are amended to include one or more elements that are the same as or similar to those elements amended into claim 1. Accordingly, Applicant submits that claims 12 and 20 are allowable over the cited references for reasons similar to those discussed above with respect to claim 1.
The dependent claims are distinguished over the cited references for at least the same reasons as discussed with respect to their corresponding independent claims.
Claim 22 has been added herein. Claim 22 depends from claim 20. As previously discussed, claim 20 is believed to be allowable. As such, claim 22 is believed to be allowable based at least on its dependency upon claim 20.
a) Examiner respectfully disagrees. As is detailed in the above rejection, with regard to claim 1 Sivakumar teaches: a virtual function of a network virtualization client [Sivakumar ¶ 112, 252-253] the driver multiplexer does not reconfigure or cause the reconfiguration of the network virtualization client. The virtual router agent of Sivakumar functions as the network virtualization client, there are no recitations in Sivakumar of reconfiguring the virtual router agent caused by the driver multiplexor. The arguments have been considered but were not found to be persuasive.
Conclusion
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at (571) 272-3338. 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.
/A.F.R./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights