DETAILED ACTION
Claims 1 and 11 have been amended.
Claims 1 – 20 have been examined and are pending.
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/11/2026 has been entered.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication No. 2022/0278926 to Sharma et al. (hereinafter Sharma) and in view of US Patent Application Publication No. 2023/0281059 to Ruan.
Claim 1, Sharma discloses (¶2) virtualized computing infrastructure, which further includes:
apparatus (Sharma discloses ¶abstract, a computing device including a virtual router, a pod comprising a container, and a network plugin) comprising:
a computing device including one or more processing devices and one or more memory devices operably coupled to the one or more processing devices, the one or more memory devices storing executable code that, when executed by the one or more processing devices, causes the one or more processing devices to (Sharma discloses ¶157 (Sharma discloses (¶103, ¶157, ¶Abstract) computing device with microprocessor 310, instructions and memory 344)
receive a pod specification including a network annotation and including a container specification for one or more containers (Sharma discloses (¶58, ¶99, ¶131) orchestrator 23 may obtain a pod manifest configuration file that includes an annotation indicating an interface type for a virtual network for pod 22A and deploy pod 22A. Sharma discloses (¶98) orchestrator 23 of Fig. 1, receives container specification data for containers. Container specification data may be a pod specification. Sharma discloses (¶94) Pods 202A-202B includes one or more containers 229A or 229B.)
instantiate a pod according to the pod specification (Sharma discloses ¶98, ¶99, ¶133 based on container specification data, orchestration agent directs container engine to obtain and instantiate the container images for containers, for execution of containers by the computing device)
following instantiation of the pod and prior to instantiating the one or more containers according to the pod specification, configure a device plugin of the pod to implement one or more network interfaces for the pod according to the network annotation (Sharma discloses (¶57, ¶58, ¶59, ¶63, ¶64, ¶131, ¶132) — Sharma describes the pod creation lifecycle in which the orchestration agent both deploys the pod and invokes the network module/network controller to configure virtual network interfaces as part of the pod setup. In ¶58 the description of obtaining a pod manifest with an annotation and invoking a network module to configure virtual network interfaces is described in the same pod creation flow. Sharma discloses (¶55) containers within a pod have a common IP address and port space and are able to detect one another via the localhost and can communicate with one another using inter-process communications (IPC) or via pod IP addresses. Sharma further explains (¶9-¶13 and ¶63-¶64) how a network module CNI plugin is invoked by a container platform, and the CNI plugin is a networking solution for application containers and is a runtime executable that assists with configuring virtual network interfaces (also referred to herein as simply “virtual interfaces” or “interfaces”) for network communications between pods that include the container and other components of the computing device hosting the pod. Sharma discloses (¶98–¶99) describe the orchestration agent directing the container engine to create the pod and containers; reading these passages together, a person of ordinary skill would understand that network interface configuration derived from the pod manifest/annotation is performed during pod setup (after the pod object is created/deployed) and before, or as part of the initialization sequence that precedes, starting container processes in the pod. Further, Sharma specifically describes (¶131-¶132) network controller manager 325 directing creation of virtual networks and annotating pods with vni_uuids and allocated virtual network addresses. That disclosure supports that information from pod configuration/annotations (e.g., interface type identifiers, vni_uuids) is associated with the pod and used to configure network interfaces and addressing for containers in the pod)
after (c) call a container runtime interface (CRI) to instantiate the one or more containers in the pod according to the pod specification and perform, by the CRI (Sharma discloses (¶63, ¶64, ¶98, ¶99) a conventional CNI plugin is invoked by a container platform/runtime, receives an add command from the container platform to add a container to a single virtual network. A single network module 17A invoked by container platform 19A extends the functionality of a conventional CNI plugin by obtaining interface configuration data 25 and adding multiple different virtual network interfaces 26. The term "invoke" may refer to the instantiation, as executable code, of a software component or module in memory (e.g., user space 245) for execution by microprocessor 210)
instantiate, by the container runtime interface, the one or more containers (Sharma discloses (¶63, ¶64, ¶98, ¶99) a conventional CNI plugin is invoked by a container platform/runtime, receives an ADD command from the container platform to add a container to a single virtual network, and such a plugin is then maintained in the runtime memory of the server to subsequently receive a Del(ete) command from the container/runtime and remove the container from the virtual network; A single network module 17A invoked by container platform 19A extends the functionality of a conventional CNI plugin by obtaining interface configuration data 25 and adding multiple different virtual network interfaces 26. The term "invoke" may refer to the instantiation, as executable code, of a software component or module in memory (e.g., user space 245) for execution by microprocessor 210)
Sharma explicitly discloses the container runtime interface (¶9-¶11 and ¶63-¶69), but it does not explicitly discloses configuring, . However, in an analogous art, Ruan teaches:
configure, by the container runtime interface, the one or more containers with one or more environmental variables from the network annotation for controlling communication over the one or more network interfaces (Ruan teaches (¶89, ¶123, ¶129) parsing an annotation field corresponding to the new YarnPod 521; obtaining an environment variable i.e. IP information (the position of the first data resource) of the one or more DataNodePods (i.e., the first data resource) in the current environment according to the first prefix field and inject the IP information into the ProcessPod 531 through an environment variable DN_LIST (representing a corresponding relationship between the IP information of the one or more DataNodePods in the current environment and one or more Nodes); inject an environment variable NODE (indicating which Node the ProcessPod belongs to) into the ProcessPod 531 to obtain a complete ProcessPod 531.)
It would have been obvious as of the effective filing date to one of ordinary skill in the art to combine an apparatus comprising: a computing device including one or more processing devices and one or more memory devices operably coupled to the one or more processing devices, the one or more memory devices storing executable code that, when executed by the one or more processing devices, causes the one or more processing devices to receive a pod specification including a network annotation and including a container specification for one or more containers, instantiate a pod according to the pod specification, following instantiation of the pod and prior to instantiating the one or more containers according to the pod specification, configure a device plugin of the pod to implement one or more network interfaces for the pod according to the network annotation, after (c) call a container runtime interface (CRI) to instantiate the one or more containers in the pod according to the pod specification and perform, by the CRI, instantiate, by the container runtime interface, the one or more containers, as disclosed by Sharma, configure, , as taught by Ruan, for the purpose of implementing (¶2) methods, systems, devices, and storage mediums in a distributed framework.
Claim 2, Sharma in view of Ruan discloses all the elements of claim 1. Further, they disclose:
wherein the one or more network interfaces include one or more virtual local area networks (VLANs) implemented on a physical link of the computing device (¶36, each virtual network could be implemented as a Virtual Local Area Network (VLAN), Virtual Private Networks (VPN), etc. A virtual network can also be implemented using two networks - the physical underlay network made up of IP fabric 20 and switching fabric 14 and a virtual overlay network. The role of the physical underlay network is to provide an "IP fabric," which provides unicast IP connectivity from any physical device (server, storage device, router, or switch) to any other physical device.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 3, Sharma in view of Ruan discloses all the elements of claim 2. Further, they disclose:
wherein the one or more environmental variables include identifiers of the VLANs (¶90, the tunnel encapsulation header may include a virtual network identifier, such as a VxLAN tag or MPLS label, that indicates a virtual network, e.g., a virtual network corresponding to VRF 222A.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 4, Sharma in view of Ruan discloses all the elements of claim 2. Further, they disclose:
wherein the one or more environmental variables include virtual function identifiers of the VLANs (¶36, each virtual network could be implemented as a Virtual Local Area Network (VLAN), Virtual Private Networks (VPN), etc. Further, in ¶43, a virtual network endpoint may use one virtual hardware component (e.g., an SR-IOV virtual function) enabled by NIC 13A to perform packet I/O and receive/send packets on one or more communication links with TOR switch 16A. Moreover, in ¶127, API server 320 may further include an interface type identifier ("ID") 301 indicating a type of a virtual interface. Types of virtual interfaces may include ... a single root I/O virtualization (SR-IOV) VF [virtual function identifier], a Virtio VF, or another type of virtual interface.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 5, Sharma in view of Ruan discloses all the elements of claim 1. Further, they disclose:
wherein the one or more environmental variables include a gateway address for an external network (¶37, the forwarding tables of the underlay physical routers and switches may, for example, only contain the IP prefixes or MAC addresses of the physical servers 12. Gateway routers or switches that connect a virtual network to a physical network are an exception and may contain tenant MAC or IP addresses.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 6, Sharma in view of Ruan discloses all the elements of claim 1. Further, they disclose:
wherein the one or more environmental variables include an address in an internal network of the pod (¶126, when the network controller manager 325 is notified of these pods, network controller manager 325 may create virtual networks as listed in the annotations ("red-network", "blue-network", and "default/extns-network" in the above example) and create, for each of the virtual networks, a virtual network interface per-pod replica (e.g., pod 202A) with a unique private virtual network address [internal network) from a cluster - wide address block (e.g. 10.0/16) for the virtual network.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 7, Sharma in view of Ruan discloses all the elements of claim 1. Further, they disclose:
wherein the one or more environmental variables include an address of a networking component of the computing device (¶44, in Single Root I/O Virtualization (SR-IOV), which is described in the Peripheral Component Interface Special Interest Group SR - IOV specification, the PCle [networking component] Physical Function of the network interface card (or "network adapter'') is virtualized to present one or more virtual network interfaces as "virtual functions" for use by respective endpoints executing on the server 12. Further, in ¶144, the example of Fig. 6, all different interfaces may be assigned IP addresses from a same IPAM using the same network attachment definition.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 8, Sharma in view of Ruan discloses all the elements of claim 7. Further, they disclose:
wherein the address of the networking component is a peripheral component interconnect (PCI) address (¶44, in Single Root I/O Virtualization (SR-IOV), which is described in the Peripheral Component Interface Special Interest Group SR - IOV specification, the PCle Physical Function of the network interface card (or "network adapter'') is virtualized to present one or more virtual network interfaces as "virtual functions" for use by respective endpoints executing on the server 12. Further, in ¶144, in the example of Fig. 6, all different interfaces may be assigned IP addresses from a same IPAM using the same network attachment definition.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 9, Sharma in view of Ruan discloses all the elements of claim 1. Further, they disclose:
wherein the pod is a KUBERNETES pod (¶55, pod 22A is a Kubernetes pod.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 10, Sharma in view of Ruan discloses all the elements of claim 1. Further, they disclose:
wherein the computing device is part of a cloud computing platform (¶117, network controller 324 may provide cloud networking for a computing architecture operating over a network infrastructure.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 11, do not teach or further define over the limitations in Claim 1. Therefore, claim 11 is rejected for the same rationale of rejection as set forth in Claim 1.
Claim 12, do not teach or further define over the limitations in Claim 2. Therefore, claim 12 is rejected for the same rationale of rejection as set forth in Claim 2.
Claim 13, do not teach or further define over the limitations in Claim 3. Therefore, claim 13 is rejected for the same rationale of rejection as set forth in Claim 3.
Claim 14, do not teach or further define over the limitations in Claim 4. Therefore, claim 14 is rejected for the same rationale of rejection as set forth in Claim 4.
Claim 15, do not teach or further define over the limitations in Claim 5. Therefore, claim 15 is rejected for the same rationale of rejection as set forth in Claim 5.
Claim 16, do not teach or further define over the limitations in Claim 6. Therefore, claim 16 is rejected for the same rationale of rejection as set forth in Claim 6.
Claim 17, do not teach or further define over the limitations in Claim 7. Therefore, claim 17 is rejected for the same rationale of rejection as set forth in Claim 7.
Claim 18, do not teach or further define over the limitations in Claim 8. Therefore, claim 18 is rejected for the same rationale of rejection as set forth in Claim 8.
Claim 19, do not teach or further define over the limitations in Claim 9. Therefore, claim 19 is rejected for the same rationale of rejection as set forth in Claim 9.
Claim 20, do not teach or further define over the limitations in Claim 10. Therefore, claim 20 is rejected for the same rationale of rejection as set forth in Claim 10.
Response to Arguments
Applicant’s arguments and amendments, filed on 02/11/2026 with respect to the Claims 1 – 20 have been fully considered and they are persuasive. Hence, the 35 USC § 102 rejection is withdrawn. However, based on the claim amendments and the newly introduced limitations, the search is updated and a new reference (US Patent Application Publication No. 2023/0281059 to Ruan) is being introduced for the 35 USC § 103 rejection.
In response to the applicant’s argument, Pg. 6-8, “in paragraphs 58 and 59, the pod manifest is not disclosed as including a container specification for one or more container,” the Examiner notes Sharma discloses (¶94) Pods 202A-202B includes one or more containers 229A or 229B. Sharma discloses (¶58, ¶99, ¶131) orchestrator obtaining a pod manifest configuration file that includes an annotation indicating an interface type for a virtual network for pod and deploy pod 22A. Sharma further discloses (¶98) orchestrator of Fig. 1, also receiving container specification data for containers. Container specification data may be a pod specification.)
In response to the applicant’s argument, Pg. 8, “the virtual interfaces in the pod of Sharma are not created following instantiation of the pod and prior to instantiating the one or more containers according to the pod specification,” the Examiner notes Sharma discloses (¶Fig. 4) the instantiation of the POD in Step 402, the Virtual IFS with Interface Type ID being created in Step 414-422, and the last step is that the Pod 202A is being configured (Step 423) i.e. setup of the Pod 202A (¶138) which includes obtaining container specification data and ensures the network plugin 206 is invoked to complete the configuration of the Pod 202A.)
In response to the applicant’s argument, Pg. 9, “paragraphs 63, 64, and 131 do not disclose adding environmental variable,” the Examiner notes that newly introduced prior art, Ruan teaches (¶89, ¶123, ¶129) parsing an annotation field, obtaining an environment variable i.e. IP information (the position of the first data resource) and injecting the IP information into the Pod through an environment variable DN_LIST.)
Conclusion
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
U.S. Patent Application Publication No. 2022/0279420 to Akkipeddi et al. (Containerized Router with Virtual Networking)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HASSAN KHAN whose telephone number is (313) 446-6574 and fax number is (571) 483-7559. The examiner can normally be reached on MONDAY - THURSDAY.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Christopher L. Parry can be reached on (571) 272-8328. 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:/Awww.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.
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:/Awww.uspto.gov/interviewpractice.
/H. A. K./
Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451